I read the entire long description, but admittedly skimmed some. Certainly 90%+ can be done, in almost the same way, with `class Mine(Simple namespace)`, but I could have missed some corner.
Perhaps highlight that. But I am certain I remain -1, in any event. On Sun, May 2, 2021, 5:16 AM Matt del Valle <matthew...@gmail.com> wrote: > Nope! > > I know it's hard to convey tone through text, so I just wanna assure you > I'm not being snarky or whatever. > > With that said, I'd ask that you please read through the full proposal > before making assumptions like 'this is exactly the same as > types.SimpleNamespace'. I know it's a bit long (sorry for that!), but > that's the only way we can be on the same page for this discussion. There > are several code examples in there which do things that could not be done > by using types.SimpleNamespace. > > Also, types.SimpleNamespace doesn't offer the same declarative syntax > (where assigning to names within its block gets transformed into > attributes). Its interface is mostly dynamic, whereas the way a 'namespace' > block would be used would be declarative. > > The closest analogue to the proposed 'namespace' block, would not be > types.SimpleNamespace, but rather, a 'class' definition that makes use of > the syntactic sugar for declaring class attributes when assigning to names > within the class block. It might well be that the consensus is that this > suggestion is *too similar* to that and *doesn't offer enough* to warrant > adding a new keyword. That's fine. I wrote this up knowing that it's a > pretty high bar to add any new keyword to an existing language and there's > a good chance this doesn't go anywhere. I still just wanted to get a > conversation going to get a feel for the community's appetite for something > like this. > > But yeah, probably the biggest difference between a namespace block and a > class block would be that a namespace block within a class block still > allows any functions that are defined within it to become bound methods for > that class, which would not be the case using a nested class block. Also, > attributes are not actually stored within the namespace, but rather within > whatever scope the namespace block ultimately lives. This is very different > to how nested classes or types.SimpleNamespace works. > > I'm happy to answer any questions, just please read the full proposal > first :) > > On Sun, May 2, 2021 at 1:25 AM David Mertz <me...@gnosis.cx> wrote: > >> So this is exactly the same as `types.SimpleNamespace`, but with special >> syntax?! >> >> On Sat, May 1, 2021, 7:57 PM Matt del Valle <matthew...@gmail.com> wrote: >> >>> Hi all! >>> >>> So this is a proposal for a new soft language keyword: >>> >>> namespace >>> >>> I started writing this up a few hours ago and then realized as it was >>> starting to get away from me that there was no way this was going to be >>> even remotely readable in email format, so I created a repo for it instead >>> and will just link to it here. The content of the post is the README.md, >>> which github will render for you at the following link: >>> >>> https://github.com/matthewgdv/namespace >>> >>> I'll give the TLDR form here, but I would ask that before you reply >>> please read the full thing first, since I don't think a few bullet-points >>> give the necessary context. You might end up bringing up points I've >>> already addressed. It will also be very hard to see the potential benefits >>> without seeing some actual code examples. >>> >>> TLDR: >>> >>> - In a single sentence: this proposal aims to add syntactic sugar for >>> setting and accessing module/class/local attributes with dots in their name >>> >>> - the syntax for the namespace keyword is similar to the simplest form >>> of a class definition statement (one that implicitly inherits from object), >>> so: >>> >>> namespace some_name: >>> ... # code goes here >>> >>> - any name bound within the namespace block is bound in exactly the same >>> way it would be bound if the namespace block were not there, except that >>> the namespace's name and a dot are prepended to the key when being inserted >>> into the module/class/locals dict. >>> >>> - a namespace block leaves behind an object that serves to process >>> attribute lookups on it by prepending its name plus a dot to the lookup and >>> then delegating it to whatever object it is in scope of >>> (module/class/locals) >>> >>> - This would allow for small performance wins by replacing the use of >>> class declarations that is currently common in python for namespacing, as >>> well as making the writer's intent explicit >>> >>> - Crucially, it allows for namespacing the content of classes, by >>> grouping together related methods. This improves code clarity and is useful >>> for library authors who design their libraries with IDE autocompletion in >>> mind. This cannot currently be done by nesting classes. >>> >>> I live in the UK so I'm going to bed now (after working on this for like >>> the last 6 hours). I'll be alive again in maybe 8 hours or so and will be >>> able to reply to any posts here then. >>> >>> Cheers everyone :) >>> _______________________________________________ >>> 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/7DAX2JTKZKLRT4CKKBRACNBJLHQUCN6E/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>
_______________________________________________ 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/P7UQGKAHPQ2OS2X64WA6DQT4PVY6QLFZ/ Code of Conduct: http://python.org/psf/codeofconduct/
