Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
approved by someone.
The tests don't (and should not) check that all the operations you performed are correct. The overall of tests should control that the code works correctly with sufficiently distinct inputs. The true issue, and it has been raised years ago, is that there are no random tests.
It failed with recursion error when I tried, though.
I would not be quite as critical, but for sure this is aligned with my comment.
This is just not a class or OOP kata at all.
It's a like, an algo, data type kata dropped inside a class that the kata creator made on their own to start the example for you.
no spoiler flag, here, I answered in the description of the fork.
@beniolenio:
Thing is, renaming vars and splitting differently a code, it can improve a lot its readability. So if you're aiming for this, that's pretty often the way to go, imo.
Now about your algo, let's see...
g
is an iterator =>g
should stand for[*g]
js
) => do that one time for all, then manage the resultant data structure (whatever it is). Or maybe use something likestr.split(sep,n)
? I never use that, might be appropriate, here.js
, first to group, then to build the values. => split once, then work on the split data. This makes the previous point useless (edit: well, I wrote this thinking about something like what I used. But you can use the suggestion of the previous point to keep your approach and end up wih a better managment of thejs
step).root
is quite disturbing. To me, that means you're merging two different functions in one.If I go further, I guess that means I'll fork your solution...
edit: btw... why
js
??@Blind4Basics:
True, valid points. I haven't mastered OOP design at all, so I'm bound to make mistakes like the ones you point out. In my defense, I do try to stick to just the requirements of the kata (i.e. the only "user" here is me, when creating the object in the tree() function). As far as I'm concerned, the "user" never sees anything beyond the existence of the tree() function.
As for the sorting stuff, yeah it's not ideal. I can't remember exactly (this was a while ago) but based on my docstrings I believe I may have been running into performance issues. These kind of restrictions often influence my solutions, and they won't be obvious after the fact.
In a real world setting a class would rarely ever be truly "finished", as a project progresses, I'd keep making changes. But on CW, the implementation is done exactly when the solution passes all the tests (there are thousands of other katas waiting :)
Thanks for the feedback!
Sure, no doubt you have your conventions and as long as you stick to them, you know what they mean. Here's two challenges though:
If you can answer these with "sure", then you're golden. E.g. in my case, after seeing your notification, I just had to glance at my code for a minute or two and I immediately knew what the kata was and how my code solved it. That's my personal preference; long, verbose and clear, because I'm not smart enough to understand a one-liner I wrote a year ago. That's why I skip all the code golf challenges and others like them: I personally find brevity a useless skill outside of pure entertainment settings like these. But that's just me. If it works for you, then that's all that really matters.
As for your last point, I totally agree, I have that experience with almost every kata at 5kyu and above. Other always seem to find the most concise and simple way of solving it, and I always take the complicated route. Comes from experience, I suppose.
Hi,
I'm sorry, but I don't like this kind of longer code ;) Too short isn't good, yeah, but the longer the code, the harder it is to not introduce inconsistencies in the logic.
For example, your current design isn't coherent about the sorting step. Sorting shouldn't be done as a separate action but should instead be trigered during the iteration. Moreover, your class needs the user to triger it manually. Meaning the designed class is relying on user actions to behave correctly which is just... not a good design (at all..) (talking about encapsulation).
There is one simple way to encapsulate the current version to hide this problem, but you still do all the sorting steps even when useless (hence, you lose the advantage of the generator version):
where
PathObject.from
is a class method holding the current code of thetree
function. This way, you at least keep something clean about encapsulation of the logic (but again, the sorting still isn't made in an appropriate way, to my taste).Cheers :)
Thanks! I wouldn't say it's necessarily more elegant, but it is definitely more readable. List comprehensions, while powerful and often performant, tend to be hard to reason about, especially because we have a tendency to try and cram it all into as few lines as possible, so we use variable names like "k", "x", "g", which say nothing about what their role is.
Being able to reason about the code I'm reading is much more valuable than brevity (which I believe is why you say mine is more elegant); I'd rather read 100 lines of code and know exactly what is happening, than read 3 lines of deeply nested comprehensions and have to put on my genius hat to figure out what is going on.
I think the biggest difference between our approaches is that yours is a "lazy" generator, it creates the values only when they're requested. Mine generates the entire tree structure upfront and then just iterates over the results. Yours is probably more efficient in that regard.
Approved
(there actually is a "somewhat way", but not bullet proof...)
Sure, I can't prevent all these things in python, so feel free to find ways around the current restrictions.
The
|
is called a guard.Loading more items...