On Wed, May 5, 2021, 02:11 Steven D'Aprano wrote:
> My comments follow, interleaved with Matt's.
>
>
> On Mon, May 03, 2021 at 11:30:51PM +0100, Matt del Valle wrote:
>
> > But you've pretty much perfectly identified the benefits here, I'll just
> > elaborate on them a bit.
> >
> > - the
Thanks Paul, you channelled my thinking exactly correctly.
I am not an expert on C++, but I think that's roughly how C++ namespaces
work. Any C++ coders care to confirm or correct me?
Steve
On Wed, May 05, 2021 at 12:05:56PM +0100, Paul Moore wrote:
> On Wed, 5 May 2021 at 11:33, Matt del
Whoops. I totally misread that! My brain unhelpfully supplied string quotes
in the return statement of the `eggs` methods, rather than parsing them as
function calls. ...for some reason I could not explain to you.
Maybe I've grown too dependent on syntax highlighting!
I see what Steven meant
On Wed, 5 May 2021 at 11:33, Matt del Valle wrote:
>> To give an example:
>>
>> def spam():
>> return "spam spam spam!"
>>
>> def eggs():
>> return spam()
>>
>> namespace Shop:
>> def spam():
>> return "There's not much call for spam here."
>>
On Wed, May 5, 2021 at 8:33 PM Matt del Valle wrote:
> Creating lots of unnecessary classes just for namespacing, as we currently
> have to resort to, isn't ideal.
>
> What you're calling 'an unnecessary level of indirection', quickly becomes a
> big boost to clarity (both in the written code
>
> 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 is capable of looking up B.C.D in one step if you use `getattr` because
the way A forwards on
My comments follow, interleaved with Matt's.
On Mon, May 03, 2021 at 11:30:51PM +0100, Matt del Valle wrote:
> But you've pretty much perfectly identified the benefits here, I'll just
> elaborate on them a bit.
>
> - the indentation visually separates blocks of conceptually-grouped
>
On Wed, May 5, 2021 at 11:34 AM Matt del Valle 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
>
> I don't pretend to fully understand the proposal and how it would be
> implemented, but IMO adding an overhead (not to mention more complicated
> semantics) to *every* chained attribute lookup...
It's a good thing that isn't the case then :p
Sorry, couldn't resist that quip. But more
On 04/05/2021 14:39, Paul Bryan wrote:
A problem I sense here is the fact that the interpreter would always
need to attempt to resolve "A.B.C" as getattr(getattr(A, "B"), "C")
and getattr(A, "B.C"). Since the proxy would be there to serve up the
namespace's attributes, why not just let
Response inline.
On Mon, 2021-05-03 at 23:30 +0100, Matt del Valle wrote:
> @Paul Bryan, I'll try to address your questions one-by-one
>
> > 1. It seems that I could get close to what you're aiming for by
> > just using underscores in names, and grouping them together in the
> > class
@Paul Bryan, I'll try to address your questions one-by-one
1. It seems that I could get close to what you're aiming for by just using
> underscores in names, and grouping them together in the class definition.
> Is there any advantage to declaring methods in a namespace beyond
> indentation and
Correction:
4. What would you expect getattr(A.B, "C") to yield?
Paul
On Mon, 2021-05-03 at 12:10 -0700, Paul Bryan wrote:
> I've read the proposal, and this thread.
>
> Questions:
>
> 1. It seems that I could get close to what you're aiming for by just
> using underscores in names, and
I've read the proposal, and this thread.
Questions:
1. It seems that I could get close to what you're aiming for by just
using underscores in names, and grouping them together in the class
definition. Is there any advantage to declaring methods in a namespace
beyond indentation and the dot
On Mon, May 3, 2021 at 6:49 PM Stestagg wrote:
> class A:
> Namespace B:
> C = 1
>
> A.__dict__ == {‘B.C’: 1, ‘B’: }
OK, that is a difference. I don't really understand why it's desirable,
but I see the difference.
I can make that happen with a metaclass that would allow:
class
The first example in the doc lays out the difference:
Assignments within the namespace block have this special behaviour whereby
the assigned-to name is changed to be:
‘.’
And the assignment is made in the ‘parent scope’ of the namespace.
I.e. (again, as described in the doc):
class A:
On Mon, May 3, 2021 at 6:37 PM Stestagg wrote:
> On Mon, 3 May 2021 at 19:24, David Mertz wrote:
>
>> So yes... as I thought, SimpleNamespace does EVERYTHING described by the
>> proposal, just without needing more keywords:
>>
>
> Except that the code and description of the proposal explicitly
On Mon, 3 May 2021 at 19:24, David Mertz wrote:
> So yes... as I thought, SimpleNamespace does EVERYTHING described by the
> proposal, just without needing more keywords:
>
Except that the code and description of the proposal explicitly outline
behaviours that SimpleNamespace does not provide
So yes... as I thought, SimpleNamespace does EVERYTHING described by the
proposal, just without needing more keywords:
>>> from types import SimpleNamespace
>>> class A(SimpleNamespace):
... class B(SimpleNamespace):
... foo = 'bar'
...
>>> A.B.foo
'bar'
>>> A.B
>>> import sys
>>>
So for simplicity let's assume that the content of 'bar' is 3, and let's
assume that the module is __main__
Then:
>>> vars(sys.modules[__name__])["A.B.foo"]
3
And it can be accessed in the usual way like:
>>>A.B.foo
3
Likewise for the namespace objects that are created during the namespace
OK, tell me what this does.
namespace A:
namespace B:
foo = bar
On Sat, May 1, 2021 at 7:55 PM Matt del Valle 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
>
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
A further point to Steve's example is that a proxy object like the one he
described would probably have to change its implementation ever so slightly
in order to work as expected in a multi-step lookup involving namespaces
(so that the `wrap` function is only applied to the final value at the
This shouldn't be a problem.
For instance:
class Wrapped:
namespace foo:
bar = True
facade = proxy(Wrapped())
facade.foo.bar # True
Basically, when you try to look up 'foo' on the proxy object, the
'__getattr__' returns the namespace object, which then forwards on the
second
On Sun, 2 May 2021 at 00:57, Matt del Valle wrote:
> Hi all!
>
> So this is a proposal for a new soft language keyword:
>
> namespace
>
> …
> - 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
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
So this is exactly the same as `types.SimpleNamespace`, but with special
syntax?!
On Sat, May 1, 2021, 7:57 PM Matt del Valle 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
>
27 matches
Mail list logo
