Try: understand creative solution for Friends by veky - python coding challenges

Enable Javascript in your browser and then refresh this page, for a much enhanced experience.

Try: understand solution in Creative category for Friends by veky

class Friends(set):
    __init__ = lambda self, c: super().__init__(map(frozenset, c))

    def add(self, c):
        try: return c not in self
        finally: super().add(frozenset(c))

    def remove(self, c):
        try: return c in self
        finally: super().discard(c)

    names = lambda self: set.union(set(), *self)

    connected = lambda self, n: {c for e in self if n in e for c in e - {n}}

Nov. 12, 2014

Comments:

Cjkjvfnby on Nov. 13, 2014, 8:19 p.m.
fif nine for cine :)

veky on Nov. 14, 2014, 4:57 a.m.
cfore insel. ;)

nickie on Feb. 2, 2015, 8:50 p.m.
This is arguably one of the very rare cases where Pascal's result assignment was useful. No intermediate variable (as in my case), no messing with phony exception handlers (as in your case). Wirth would have it as: <pre class='brush: python'>def add(self, c): add = c not in self super().add(frozenset(c)) </pre> I'd rather introduce a new keyword: <pre class='brush: python'>def add(self, c): finally_return c not in self super().add(frozenset(c)) </pre>

veky on Feb. 2, 2015, 10:41 p.m.
Of course. Wirth was no fool. He just made the wrong decision balancing between this, very rare as you say, case, and other much more frequent ones where you want return as flow control. That wrong decision was motivated by his philosophy of programming, but it had to be justified somehow on the surface level, and cases like this had to exist for that. While I'm at it, I'll afford myself a heresy and say Guido is not the lone genius either, he definitely stands on the shoulders of giants. Wirth is not among the tallest ones, but he's certainly one of them. <hr /> BTW it's interesting to see that first code block you've written has a semantics in current Python, and it has to, since functions are as dynamically reboundable as anything else (up to the interesting fact that they know their real name:), and we really like to have function's name in its scope, if for nothing else, for trivial things like a sporadical recursion here and there. ;-) (Hmm, my memory eludes me... do you recall how Wirth solved that? I sincerely hope he didn't disallow recursion completely... and having two independent semantixes of a function name within the body by whether there is a `(` after it seems too ugly even for him.:) <hr /> And I wouldn't call my approach "phony exception handlers" (in the same sense I wouldn't call `for/else` construct a "phony branching statement":). Construct is there, semantics is more or less fixed, and as can be seen, `try` doesn't syntactically need to have an `except` (analogously as `else` doesn't need an `if`). So it is not only about "do this, but if it raises do something else", but it can also be about "do this, and afterwards finally (in the sense of 'unconditionally', that is, even if 'this' told you not to) do that". Yes, the keywords are a bit misused there, but really less than in "for/else" case IMO. "Final" can mean "unconditional", if I know my English right. Even if you don't agree with the previous paragraph: your new keyword, besides being ugly as toad:-P, seems wrong to me, especially when we have the current semantics of `finally` keyword, which means kinda opposite from this.

nickie on Feb. 2, 2015, 11:51 p.m.
In Pascal, if the function's name constitutes the LHS of an assignment, it denotes the result that eventually will be returned (an l-value of the type that is returned by the function). If it's used anywhere else, e.g. in the RHS of assignments, it's the function itself and has to be used accordingly (e.g., it has to be called recursively or passed as a parameter to a higher-order function). This double meaning is definitely ugly. The reason I called your approach a "phony exception handler" is indeed that the `try` keyword seems misleading to me. We do not expect this to fail, we just want to set up a piece of code to be executed just before control flow exits the `try` block (for any reason). The implementation of this, in general, requires a mechanism similar (in fact, identical) to exception handling, so using `try`/`finally` in Python seems to be the right way to do it. Exceptions are a structured mechanism for radically changing control-flow. The keyword `try`, in my mind, makes sense for code blocks that may throw exceptions. On the other hand, Java and later on Python introduced the `finally` clause, which applies to all possible ways in which control flow may exit the `try` code block, including exceptions and normal termination. So, if this goes beyond `throw`/`raise` and extends to `return` (or to following any other given continuation, should the language allow it) then maybe the `try` construct has to be renamed to something more general.

veky on Feb. 3, 2015, 8:35 a.m.
About Pascal: that's even more inconsistent than what I thought. So "it's a local variable whose value at the moment of exit will be returned" is a very leaky abstraction? Because I can't update it as a normal variable during execution, e.g. `funcname:=funcname*5`. Or even do something like `Inc(funcname)`. It's interesting how quickly we (or at least I:) forget the horrible, horrible things we had to live with in the past. :-D <hr /> <blockquote> then maybe the try construct has to be renamed to something more general. </blockquote> Yes. In the tradition of your ugly-as-toad keywords with underscores, I propose <pre class='brush: python'>alter_control_flow: </pre> :-PP (My God, it seems like I'm writing COBOL. At least it's not uppercase.;)) Of course I was facetious. I really think names should reflect the most usual use-case, not all possible generalities. As I say many times in such occasions, Python is not Java. :-] <hr /> <blockquote> The keyword try, in my mind, makes sense for code blocks that may throw exceptions. </blockquote> Of course. And the keyword `else`, in my mind, makes sense for alternate branch of an `if` statement, where the condition is not satisfied. The problem is, Python doesn't agree with such a narrow sense :-D (though of course it's the most widely used one). This made me think about another thing, how (probably) Python's lack of braces and insistence on indentation made (what in other languages were called) "compound statements" a much more loosely connected bunch of "suites", each with its introducing keyword, that can be mix'n'matched in nonobvious ways. You can have if/elif without else, or try/finally without except, or for/else without if... more startlingly: if, elif, try, except, while, and for, each can have an "else", which means "else" is not just a part of a fixed compound, but a block on its own. Yes, it can't appear just anywhere, but that's just syntactic constraint. :-) Of course the language doesn't really work that way, but people do exploit that metaphor when asking for new features. I remember how someone wanted to give `with` statement an optional `except` handler, and it totally made sense - in a way. (Guido shot it down because `with` protocol is already too complicated, not because the meaning would be unclear. In a way, `with` is just a `try` with a default `finally`. Of course it's obvious what `except` would do there.:) If we were bolder, we could have gotten away without need for special decorator syntax with <pre class='brush: python'>finally: classmethod def blah(cls): ... </pre> :-D (can be trivially extended to class decorators, too;).

veky on Nov. 26, 2015, 6:45 p.m.
I'm just reading Slatkin, Effective Python, and I found an amusing sentence: <blockquote> `try/finally` is also intuitive because it means "Always do what is final after trying the block before". </blockquote> It's nice to know I'm not the only one identifying `finally` with that meaning of "final". :-)

Czarinov on Aug. 7, 2015, 9:42 p.m.
Wow, that's nice :D... my code is 4 times longer... But at least I solved it. Will dig into yours once I'm rested.

veky on Aug. 7, 2015, 11:15 p.m.
<pre class='brush: python'>try: understand except TooTired: rest finally: give(me, thumb) </pre> ;-D

Czarinov on Aug. 8, 2015, 9:35 a.m.
:D careful now, you can break life if you start programming it into python!! :D

veky on Aug. 8, 2015, 11:31 a.m.
<blockquote> careful now </blockquote> Now? TooLateException. :-P

bsquare on Aug. 9, 2019, 10:10 a.m.
So funny^^

vvm70 on May 9, 2021, 4:40 p.m.
Thank you for such a code! You should name it: Try to understand. :) It seems, <pre class='brush: python'>set.union(set(), *self) </pre> could be shorten to <pre class='brush: python'>set().union(*self) </pre>

veky on May 9, 2021, 5:29 p.m.
<blockquote> You should name it: Try to understand. :) </blockquote> I did. :-P <blockquote> set().union(*self) </blockquote> Yes. But not `set.union(*self)` (why?). :-)

vvm70 on May 9, 2021, 5:48 p.m.
<pre class='brush: python'>names = lambda self: set.union(*self) </pre> TypeError: descriptor 'union' for 'set' objects doesn't apply to a 'frozenset' object

veky on May 9, 2021, 5:49 p.m.
Ah yes. Why not `frozenset.union(*self)` then? :-D

vvm70 on May 9, 2021, 5:51 p.m.
Because of return type (set)

veky on May 9, 2021, 5:53 p.m.
Let me tell you a secret, Python doesn't care that much about return types. frozensets are sets, mostly. :-) But ok. Why not `set(frozenset.union(*self))`? (There is an important lesson hiding here...;)

vvm70 on May 9, 2021, 5:57 p.m.
<blockquote> Why not set(frozenset.union(*self))? </blockquote> Maybe unnecessary type casting?

veky on May 9, 2021, 5:59 p.m.
You're so hung up on types. Python types are dynamic, and Python is slow anyway. :-D I'm not talking about style, and I'm not talking about performance. I'm talking about masking a bug. :-]

vvm70 on May 9, 2021, 6:01 p.m.
What bug could it be?

veky on May 9, 2021, 6:04 p.m.
Ok, so you give up. :-) Imagine self being an empty set. Try calling `frozenset.union(*set())`. Lesson: ordinary methods are always called on an object---they always must have a `self`, even when we don't care much about what object it is.

vvm70 on May 10, 2021, 2:44 a.m.
<blockquote> Try calling frozenset.union(*set()). </blockquote> <ol> <li>It raises an exception. But frozenset().union(*set()) doesn't. Why?</li> <li>And frozenset.union(*self) doesn't raise an exception if an object is empty. Why?</li> </ol>

veky on May 10, 2021, 6:10 a.m.
<ol> <li>As I said, a method (which is not staticmethod nor classmethod) must always be called on an object. If you have class T: def m(x, y, z): ... t = T()</li> </ol> then `t.m(3,5)` is the same as `T.m(t,3,5)`. The first argument of a method, usually called `self`, is passed as the object on which the method is obtained, if it is of the type that actually has the method defined. So: `frozenset` is a type. `frozenset()` is a frozen set. `frozenset.union(s1,s2,s3)` is the same as `s1.union(s2,s3)` (if s1 is a frozen set). But `frozenset.union()` makes no sense, because there is no `self`. <ol> <li>I have no idea what are you talking about. :-) If `self` is a set, and it is empty, you'll get a TypeError.</li> </ol>

viktor.chyrkin on Jan. 8, 2022, 3:52 p.m.
wow!

veky on Jan. 8, 2022, 6:11 p.m.
Did you try? 😜

viktor.chyrkin on Jan. 8, 2022, 8:42 p.m.
yeah. It did not work out though.

veky on Jan. 8, 2022, 8:58 p.m.
Was there a concrete problem I could help with?

Different kind of sets

0 %

You ClassRoom Demo is Ready With the new tool CheckiO ClassRoom, you will be able to analyze your students' progress, have your own leaderboard, change missions order on the map, and so on.