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 <[email protected]> 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 <[email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/[email protected]/message/7DAX2JTKZKLRT4CKKBRACNBJLHQUCN6E/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/QNXVFRMUCXMOTB3F24ZMS2TG2G7MOTG4/ Code of Conduct: http://python.org/psf/codeofconduct/
