On Wed, May 5, 2021 at 11:34 AM Matt del Valle <matthew...@gmail.com> wrote: > The only way you could ever resolve D in a single attribute lookup like > getattr(A, "B.C.D") is if you literally typed that statement out verbatim: > > >>> getattr(A, "B.C.D") > > That would actually work, because `namespace A` would prepend its name to the > attribute lookup and forward it on to its parent scope, serving up > (sys.modules[__name__])['A.B.C.D'], which is where the key under which D is > stored in the module globals. > > But if you just look it up using normal attribute access syntax, like you > would 99% of the time: > > >>> A.B.C.D > > Then it would be done in 3 separate lookups, one for each dot, exactly the > way you described: getattr(getattr(getattr(A, "B"), "C"), "D") > > Looking B up on `namespace A` gets you `namespace A.B`, looking up C on > `namespace A.B` gets you `namespace A.B.C`, and looking up D on `namespace > A.B.C` finally gets you a reference to whatever D contains. > > This isn't a cartesian product though. It's just one attribute lookup per > level of reference nesting, just the same as any other form of attribute > access.
So if A is capable of looking up "B.C.D", but it's also capable of looking up "B" and following the chain... what happens when you reassign something? What does this line of code do? >>> A.B.C.D = "spam" Does it change what getattr(A, "B.C.D") returns? > I've found that on this list there are a few people who fancy themselves > gatekeepers and will dismiss virtually any new idea that gets posted here > out-of-hand in a way that is often pretty unkind, and without really offering > up much of a rationale. Maybe it's just a fundamental difference of mindset, > but to me, the idea that python is 'finished' and should remain largely > untouched forever is kind of horrifying. > That's not why ideas get dismissed out of hand. Onus is not on the status quo to prove itself; onus is on the proposal to show its value. If you want your idea to be taken seriously, you have to demonstrate that it would give some sort of real improvement. > Of course we don't need syntactic sugar. We could all write code like this: > > >>>(3).__add__((4).__mul__(2)) > 11 > > rather than: > >>>3 + 4*2 That's not the same, though. Binary operators are NOT syntactic sugar for method calls - they do a number of checks that allow for reflected methods and such. > and > > evens = [] > for num in range(1, 11): > if not num % 2: > evens.append(num) > > rather than: > > [num for num in range(1, 11) if not num % 2] There are some things that are syntactic sugar for gigantic blobs (even worse than this one - check out what "yield from iter" actually does), and there, the benefit is much easier to demonstrate. The expressiveness of a simple and clear line of code IS the benefit. > So yeah, to make this point explicit. This is a proposal for syntactic sugar. > It doesn't really add anything you can't do currently, although many of the > things that would be idiomatic and trivial with `namespace` would be horrible > antipatterns without it (and equivalent implementations available currently > are much more verbose and less performant). but it should hopefully allow for > more organized and DRYer code, and more easy usage of namespacing in > situations where it makes sense and would be otherwise non-trivial to add > them in (there are several examples of this in this thread and in the doc). > > Arguing that this is pointless because it doesn't add completely new > functionality misses the mark in the same way that it's not particularly > helpful to argue that listcomps are pointless because for-loops exist. When > they were first introduced many people hated them, and yet they (and other > types of comprehensions) are one of the most beloved features of the language > nowadays. > Since Python is Turing-complete, there's nothing that will ever truly be "new functionality" in that sense. That's not the point. The point is whether it allows programmer intent to be expressed in a better way - and, specifically, whether the benefits in expressiveness are worth the costs. > I can respect that many people will feel that the upsides of this proposal > don't justify the growth in complexity of the language. > Precisely. :) > Maybe something like how people wanted switch-cases and they were judged to > be not sufficiently worth it, but then led to the match statement later on > (basically switch-cases on steroids that also do your laundry and walk your > dog). > That's actually a great example, since they've been requested so many times over the years. Why did the proposals keep getting knocked back? Because they didn't really offer any notable advantage. The match statement has some *huge* advantages, but it also has a lot of costs (it's complex, does a lot of different things, etc, etc), and the pushback has been quite significant. So I'll give you the same advice that many people have been given on this list: Get concrete examples. Go through the Python standard library and pull out a number of situations that would be able to be rewritten using this namespace syntax, and show how they'd be better for it. (Or some other large codebase, but the standard library is usually the best place to start.) Toy examples like "A.B.C.D" are all well and good for explaining what the syntax *does*, but they're not very good at explaining why the syntax *has value*. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/P3SPMNLTR26WU2AGFGATZU2LO6FYTB2Y/ Code of Conduct: http://python.org/psf/codeofconduct/
