real base creative solution for Building Base by veky - python coding challenges

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

real base solution in Creative category for Building Base by veky

from collections import namedtuple
class Building(namedtuple("Base", "south west width_we width_ns height")):
    east = property(lambda I: I.west + I.width_we)
    north = property(lambda I: I.south + I.width_ns)
    corners = lambda I: {y + "-" + x: (getattr(I, y), getattr(I, x))
                        for x in ("west", "east") for y in ("north", "south")}
    area = lambda I: I.width_ns * I.width_we
    volume = lambda I: I.area() * I.height
    __repr__ = lambda I: I.__class__.__name__ + repr(tuple(I))
Building.__new__.__defaults__ = 10,

Nov. 5, 2014

Comments:

nickie on Feb. 2, 2015, 8:15 p.m.
Holy cow!

veky on Feb. 2, 2015, 11:23 p.m.
I'll consider this a compliment. ;-]

nickie on Feb. 3, 2015, 12:01 a.m.
Yes, it was. For a moment I started wondering if we switched from Python to something else... :-)

veky on Feb. 3, 2015, 8:53 a.m.
Like what? Haskell? :-D (Or do you mean something like Java? You probably don't since you said it was a compliment.:) nameduple is incredibly Pythonic, especially as a base class. Yes, it means you have to tinker with `new` instead of `init` if you want to do something unusual, but it's not so bad. property is not Pythonic in a completely pure sense, but for designing interfaces it's irreplaceable and immensely practical. code reuse (in `volume` and `repr`) is the reason for OO in Python. dict comprehensions are a beautiful consequence of Python's consistency and genereality. getattr is a monument of Python dynamicity and DRY principle. On lambdas the jury is still out, but I like them as a concept and you won't seize them from me so easily - I fight for them on many levels. "I" is just a one-letter alias for "self" - surely unPythonic but IMO can be forgiven. Lack of vertical whitespace is a problem, but at least the horizontal whitespace is all there. Overall, I think Bayes leans more towards "this is Python" than "this is something else". And if you update your priors with "Veky wrote it", of course it becomes obvious. :-D

nickie on Feb. 3, 2015, 1:02 p.m.
Oh, yes, absolutely. It was not a statement about what Python is or is not. It was a statement about how much I know of Python.

veky on Feb. 3, 2015, 1:13 p.m.
Could it be because until recently CheckiO didn't have OO tasks, so you learned from me how to write True Python only in the classical procedural sense? :-D

OMFGNuts on Feb. 5, 2015, 11:47 a.m.
Oh veky-veku :D

veky on Feb. 5, 2015, 2:19 p.m.
I suspect this is some kind of word play that's supposed to mock my arrogance, but I'm arrogant only about Python. I'm humble enough to admit I don't get the above. ;-)

Czarinov on Aug. 18, 2016, 10:37 p.m.
Oh man, I was trying to understand this solution for quite some time and got somewhere, but it's still not 100 % clear. <ol> <li>Tried understanding the magic behind inheritance of namedtuple by Building. Realized init is gone, but don't really know how Building uses namedtuple for assignment of self.south = south for example.</li> <li>Tried following: <pre class='brush: python'>class Building: def __init__(self,...): self.south=south... ... Building.__new__.__defaults__=10 </pre></li> </ol> But it just gave me <pre class='brush: python'> "AttributeError: 'builtin_function_or_method' object has no attribute '__defaults__'" </pre> So I guess defaults is something special for a class using namedtuple.

veky on Aug. 19, 2016, 2:17 a.m.
Oh man, I was trying to understand this comment for quite some time and got somewhere, but it's still not 100% clear. :-P :-) <ol> <li>The magic behind inheritance of `namedtuple` by `Building` is the same as the magic of inheritance of any other (Python) class. And yes, `namedtuple` is written (by `exec`ing a dynamically generated Python code) in pure Python, which you can check by `print(Building._source)`. :-) And that magic is code reuse.</li> </ol> "`init` is gone" implies it has been somewhere, to be gone somewhere else. No, since Building has no `init`, inheritance says to look at base classes. <pre class='brush: python'>>>> Building.mro() [<class 'Building'>, <class 'Base'>, <class 'tuple'>, <class 'object'>] >>> next(cls for cls in _ if '__init__' in vars(cls)) <class 'object'> >>> Building.__init__ is object.__init__ True </pre> <ol> <li>So Building reuses `object`'s `init`, which does (almost) nothing. And that's just fine, since you can't really initialize a tuple in a way you've tried - they are immutable. And yes, Buildings are (namedtuples, which are) tuples - look at the MRO. In that context, `self.south = south` does the same thing as `self[0] = south` when self is a tuple, and you already know it isn't going to end well. :-)</li> </ol> No, for immutable types we need something more sophisticated. Go look at the `Building._source` once again. It has no `init`, but it has `new`. That is a real constructor, that takes a class and returns an object of that class. <pre class='brush: python'>def __new__(cls, south, west, width_we, width_ns, height): """Create new instance of Base(south, west, width_we, width_ns, height)""" new_tuple = (south, west, width_we, width_ns, height) return super().__new__(cls, new_tuple) </pre> In that way, we can really construct a new tuple, and an object of class Building from that tuple, without mutating anything. <ol> <li>What you tried is just inheriting `Building` from `object`, and then mutating `object.new` by setting its `defaults`. Python does allow you to shoot yourself in the foot here and there:-), but this would simply be too dangerous. `object.new` is not really an ordinary Python function: since `object` is at the end of every MRO, every `super().new` chain ends up in it when you actually need to construct a new Python object, and that is something that only the environment knows how to do.</li> </ol> But ordinary Python functions do have `defaults`, and it just says what are the default values for last few positional parameters of that function. We usually set them using a special syntax you probably already know. <pre class='brush: python'>>>> def f(x, y, z, a=2, b='spam'): pass >>> f.__defaults__ (2, 'spam') </pre> But of course, here I cannot alter the source of `Building.new` to say <pre class='brush: python'>..., height=10): </pre> since by the time I get there, that function is already defined. I might make a new metaclass to intercept the construction of a namedtuple and alter its source, but that's completely unnecessary. A function code is already compiled, but `defaults` is a separate attribute, and it's writable. I just set it to a tuple `(10,)` (not a number 10 as you did) to say that the last parameter (height) should have a default value of 10.

Czarinov on Aug. 23, 2016, 9:25 p.m.
<blockquote> Oh man, I was trying to understand this comment for quite some time and got somewhere, but it’s still not 100% clear. :-P :-) </blockquote> Are you just playing with words or am I missing some sarcasm here :P <hr /> I highly appreciate you took the time explain all the stuff. ;) Thank you, Veky.

veky on Aug. 23, 2016, 9:35 p.m.
Just playing with words. No hidden meaning (as opposed to the titles of my solutions, of course;).

bsquare on Sept. 14, 2019, 11:15 p.m.
Nice solution @veky. I see you have been OOP allergic since a long time :o

veky on Sept. 14, 2019, 11:20 p.m.
Nope, just allergic to Java. But we already discussed that.

bsquare on Sept. 14, 2019, 11:21 p.m.
So you like C++, Eiffel, C# for instance? :)

veky on Sept. 14, 2019, 11:27 p.m.
No. But I do like them more than Java (except C#, that's just Microsoft's Java). Which is really not much. 😛

bsquare on Sept. 14, 2019, 11:28 p.m.
Haha, I agree on that part! :D Where can I read about why you are so against Java-ish?

veky on Sept. 14, 2019, 11:30 p.m.
Lol. If you haven't already read enough on this forum, I guess I can't help you much more. 😝

bsquare on Sept. 14, 2019, 11:31 p.m.
I didn't see solid and constructive criticisms, yet.

veky on Sept. 14, 2019, 11:38 p.m.
Nor did I of my style. As I said, we're speaking dogmas here. Which is precisely why I cannot hope to have any influence on you, and why I tried to end this discussion three times already. Bit, this might shock you: I'm not against Java unconditionally. I'm just against writing Java in Python. Just as I'm against writing C in Python, LISP in Python, Haskell in Python, and as I would be against writing Forth in Python if anybody did that. 😀

bsquare on Sept. 14, 2019, 11:43 p.m.
I agree with that :)

tssrkt777 on Nov. 10, 2021, 1:06 p.m.
Really amazing solution) good of you)

U.V on Dec. 12, 2023, 6:57 p.m.
I'm too lazy to use namedtuple, but it's time to start.

veky on Dec. 13, 2023, 9:34 a.m.
Programmer's laziness is different from ordinary laziness: <a href="https://thethreevirtues.com/">https://thethreevirtues.com/</a> (item 1).

H0r4c3 on Dec. 17, 2023, 9:44 a.m.
Great solution using the function namedtuple() from the module collections! A new good lesson for making the code more Pythonic!

Everything is Object

0 %

PyCharm The Python IDE for Professional Developers. Enjoy productive Python, web and scientific development with PyCharm. Download it now!