[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

The Zen of python could potentially be interpreted to heartily endorse
adding nested namespaces to modules:

Namespaces are one honking great idea — let’s do more of those!

One concern about the implementation, from the sys documentation:

"*CPython implementation detail:* The settrace()
 function is
intended only for implementing debuggers, profilers, coverage tools and the
like. Its behavior is part of the implementation platform, rather than part
of the language definition, and thus may not be available in all Python
implementations."

Since the implementation uses the settrace function to grab the function
frame at execution time to turn the namespace into a module object, the
approach would seem to be very much at odds with the statement above. It's
definitely not a debugging or coverage tool we're talking about here.

On Sun, Aug 18, 2019, 10:12 AM Niklas Rosenstein 
wrote:

> You may be interested in this working example of a @namespace decorator
> (for functions though, not for classes).
>
> https://stackoverflow.com/a/52358426/791713
>
> —
> @namespace
> def mynamespace():
> eggs = 'spam'
> class Bar:
> def hello(self):
> print("Hello, World!")
>
> assert mynamespace.eggs == 'spam'
> mynamespace.Bar().hello()
> —
>
>
> It uses sys.settrace() to find the frame of the function before it is
> called to convert it into an actual module object.
>
> My (largely underdeveloped and not recommended to be used) “Node.py”
> project implements a preprocessor for Python code in order to implement
> such a namespace keyword.
>
>
> —
> namespace Example:
> def hello(name):
> print('Hello, {}!'.format(name))
>
> Example.hello('World')
> —
>
>
> It does this by converting the code above to the below (and
> _NamespaceSyntax__namespace_decorator points to the same namespace
> decorator from above)
>
>
> —
> @require._NamespaceSyntax__namespace_decorator
> def Example():
>
> def hello(name):
> print('Hello, {}!'.format(name))
> —
>
>
> (Link to code here:
> https://github.com/nodepy/nodepy/blob/f9e572aa20159af7a1a57b503d0c57693c7a9665/nodepy/extensions.py#L173-L264
> )
>
> Personally I like the suggestion by Ricky Teachey to use “def” instead of
> introducing a new keyword. If we cannot settle on this kind of syntax
> addition, the namespace decorator may be a good addition to the standard
> library?
>
> The full code below for reference.
>
>
> —
> import sys
> import types
>
>
> def call_function_get_frame(func, *args, **kwargs):
> """
> Calls the function *func* with the specified arguments and keyword
> arguments and snatches its local frame before it actually executes.
> """
>
> frame = None
> trace = sys.gettrace()
> def snatch_locals(_frame, name, arg):
> nonlocal frame
> if frame is None and name == 'call':
> frame = _frame
> sys.settrace(trace)
> return trace
> sys.settrace(snatch_locals)
> try:
> result = func(*args, **kwargs)
> finally:
> sys.settrace(trace)
> return frame, result
>
>
> def namespace(func):
> frame, result = call_function_get_frame(func)
> try:
> module = types.ModuleType(func.__name__)
> module.__dict__.update(frame.f_locals)
> return module
> finally:
> del frame
> —
>
>
> Best,
> -Niklas
> ___
> 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/LMC2ECO5K7NXOYZLQKPWRF3SAVFPYBGE/
> 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/L5ALAVILR52FECPI2ZQUG3I3CD33FVYZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Niklas Rosenstein]

You may be interested in this working example of a @namespace decorator
(for functions though, not for classes).

https://stackoverflow.com/a/52358426/791713

—
@namespace
def mynamespace():
eggs = 'spam'
class Bar:
def hello(self):
print("Hello, World!")

assert mynamespace.eggs == 'spam'
mynamespace.Bar().hello()
—


It uses sys.settrace() to find the frame of the function before it is
called to convert it into an actual module object.

My (largely underdeveloped and not recommended to be used) “Node.py”
project implements a preprocessor for Python code in order to implement
such a namespace keyword.


—
namespace Example:
def hello(name):
print('Hello, {}!'.format(name))

Example.hello('World')
—


It does this by converting the code above to the below (and
_NamespaceSyntax__namespace_decorator points to the same namespace
decorator from above)


—
@require._NamespaceSyntax__namespace_decorator
def Example():

def hello(name):
print('Hello, {}!'.format(name))
—


(Link to code here:
https://github.com/nodepy/nodepy/blob/f9e572aa20159af7a1a57b503d0c57693c7a9665/nodepy/extensions.py#L173-L264
)

Personally I like the suggestion by Ricky Teachey to use “def” instead of
introducing a new keyword. If we cannot settle on this kind of syntax
addition, the namespace decorator may be a good addition to the standard
library?

The full code below for reference.


—
import sys
import types


def call_function_get_frame(func, *args, **kwargs):
"""
Calls the function *func* with the specified arguments and keyword
arguments and snatches its local frame before it actually executes.
"""

frame = None
trace = sys.gettrace()
def snatch_locals(_frame, name, arg):
nonlocal frame
if frame is None and name == 'call':
frame = _frame
sys.settrace(trace)
return trace
sys.settrace(snatch_locals)
try:
result = func(*args, **kwargs)
finally:
sys.settrace(trace)
return frame, result


def namespace(func):
frame, result = call_function_get_frame(func)
try:
module = types.ModuleType(func.__name__)
module.__dict__.update(frame.f_locals)
return module
finally:
del frame
—


Best,
-Niklas
___
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/LMC2ECO5K7NXOYZLQKPWRF3SAVFPYBGE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

On Thu, Aug 08, 2019 at 10:28:44AM +0100, Ivan Levkivskyi wrote:
> On Tue, 30 Jul 2019 at 04:00, Steven D'Aprano  wrote:
> 
> > [...]
> > Should it be aliased in collections if we want people to consider
> > using it instead of namedtuple? I would never go looking in typing for
> > non-annotation-related uses, and I'm probably not the only one.
> >
> 
> I think this makes sense. Could you please open an issue on b.p.o. so that
> we don't forget about this?

Done: https://bugs.python.org/issue37809


-- 
Steven
___
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/PRTXZQJMKWQYIQ7D7NKKMABR36UZ5KLB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> Forgive me if this doesn't make sense, but what about a way to make a copy
> of a function's locals while it is being called?
>
>
This can be easily accomplished if you simply return locals() at the end of
creating the namespace, but this isn't all that elegant:

def namespace(ns):
ns_locals = ns()
from types import ModuleType
mod = ModuleType(ns.__name__)
mod.__dict__.update(ns_locals)
return mod

@namespace
def ns():
x=1
y=2
def f(): ...
return locals()
___
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/6GJOTSMEPLYPDOS2H4XNFHANPB6BPSGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> > A class + decorator gets so almost there that it might be possible
> > with just a tiny bit of language support. What if there could be a way
> > to change a function's __globals__?


Forgive me if this doesn't make sense, but what about a way to make a copy
of a function's locals while it is being called?

Maybe something like:

@namespace
def ns():
x = 1
def f(): ...

Inside the decorator, you simply call the function, make a copy of the
locals, and assign it to the function name as a module?
___
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/WJAOEIM5MF3BVEWRCM7QAJTF5O64GZUE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

On Tue, Jul 30, 2019 at 12:54:12PM +1000, Chris Angelico wrote:

> A class + decorator gets so almost there that it might be possible
> with just a tiny bit of language support. What if there could be a way
> to change a function's __globals__? Currently that's readonly
> according to funcobject.c, but by hacking that flag out, I can create
> the following example:

That's one of the problems I hit in my experiments.

I don't think you need to hack funcobject.c if you are willing to 
disassemble the function object (all of the parts are accessible as 
attributes) and re-assemble it into a new function using the 
types.FunctionType constructor.


> Due to CPython limitations, the new __globals__ MUST be a plain dict
> (not the mappingproxy that cls.__dict__ is, and not a ChainMap),

In my experiments, I think I overcame that by subclassing ChainMap and 
dict:

class MyChainMap(ChainMap, dict):
pass

was, I think, enough to fool the function constructor. Don't quote me 
on this, it's been a while and I don't remember all the details. But I'm 
pretty sure nothing segfaulted, I'd remember it if it did :-)

I'm pretty sure that this is doable, at least well enough to get a 
working prototype that people can experiment with. At worst, we might 
need AST or bytecode hacking to get the functions defined inside the 
namespace to work correctly.

> but
> this is extremely close to what could actually be quite useful. Also,
> since the function objects get mutated by the decorator, calling a
> function during the namespace's construction will have the wrong
> behaviour.

Yes, there's that too. But then the namespace doesn't actually exist at 
that point, so this is rather analogous to what happens when you call a 
function inside a class during class construction. I can live with that 
limitation.


-- 
Steven
___
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/PNBJWGT5DLJO2DP24NH2VC5TKHFFE5NZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

On Mon, Jul 29, 2019 at 07:19:42PM -0700, Guido van Rossum wrote:
> On Mon, Jul 29, 2019 at 6:55 PM Ricky Teachey  wrote:
> [Steven]
> 
> > If the core developers don't consider namedtuples important enough to
> >> get syntactic support, I doubt that namespaces will.
[...]

> Except it's wrong. The successor of namedtuple is typing.NamedTuple which
> supports this syntactically. From the [docs](
> https://docs.python.org/3/library/typing.html#typing.NamedTuple):
> ```
> class Employee(NamedTuple):
> name: str
> id: int
> ```

Oh that's nice!

I thought that typing.NamedTuple was only for type annotations, I had no 
idea you could use it for actual named tuples.

Should it be aliased in collections if we want people to consider 
using it instead of namedtuple? I would never go looking in typing for 
non-annotation-related uses, and I'm probably not the only one.

In any case, that's still using existing syntax (class statement), 
not a dedicated new "NamedTuple" keyword. And if there's no NamedTuple 
keyword, we shouldn't expect a Namespace keyword either :-)



-- 
Steven
___
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/SXF3RKYQ6DXFKX2RFMUDUKAWQEGXGHP3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Chris Angelico]

On Tue, Jul 30, 2019 at 12:13 PM Steven D'Aprano  wrote:
>
> On Mon, Jul 29, 2019 at 09:53:38PM -0400, Ricky Teachey wrote:
>
> > But I ask: how is it possible, then, to create a with block that "gobbles
> > up" things declared in it and adds those things to some namespace using
> > existing python syntax...?
> [...]
> > I currently can't create an object that allows this to work:
> >
> > with NameSpace('ns') as ns:
> > a = 1
> > assert ns.a=1
>
> Neither can I, and I've been mucking about with this idea for about
> three years. (To be honest, I poke it with a stick about every six
> months, so its not like I've spend a lot of time on it.)
>
> I kinda-sorta got it to work with a class statement plus a decorator,
> not too different from your metaclass example, but couldn't get
> functions to work correctly.

A class + decorator gets so almost there that it might be possible
with just a tiny bit of language support. What if there could be a way
to change a function's __globals__? Currently that's readonly
according to funcobject.c, but by hacking that flag out, I can create
the following example:

def namespace(cls):
"""Decorate a class to turn it into a namespace"""
ns = dict(cls.__dict__)
for member in ns.values():
if hasattr(member, "__globals__"):
member.__globals__ = ns
return cls

@namespace
class ns:
x = 1
def foo(y):
return x + y
def replace(new_x):
global x
x = new_x

print(ns.foo(4)) # 5
ns.replace(100)
print(ns.foo(4)) # 104


Due to CPython limitations, the new __globals__ MUST be a plain dict
(not the mappingproxy that cls.__dict__ is, and not a ChainMap), but
this is extremely close to what could actually be quite useful. Also,
since the function objects get mutated by the decorator, calling a
function during the namespace's construction will have the wrong
behaviour. Maybe the only language support needed is some way to say
"from now on, functions should be created with THIS value for their
globals"?

It might be possible to get even closer using a metaclass rather than
a decorator.

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/FAE7WDCKTH272M6LTUJ3QEUIOEMKJIVD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

> (On the other hand, if this is just a hypothetical "wouldn't it be cool
> if this worked?" post, then we're actually no closer to a technical
> solution.)


That's how I took it. And as has already been said, I definitely don't see
how it could be made to work using current syntax.
___
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/4KBHVN363CT2UVPSDGRTZH7ROPPJCNSS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> Except it's wrong. The successor of namedtuple is typing.NamedTuple which
> supports this syntactically.
>

Point taken. And I definitely don't mean to imply the core devs aren't
reasonable people or are unwilling to make big changes, I'm just not
experienced enough to be the guy making the
very-thoroughly-well-thought-out-version of the case for a major
syntax change.
___
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/TY4NFHR7LOCSE3IVY3JXLHM4UIDWD6UI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Guido van Rossum]

On Mon, Jul 29, 2019 at 6:55 PM Ricky Teachey  wrote:
[Steven]

> If the core developers don't consider namedtuples important enough to
>> get syntactic support, I doubt that namespaces will.
>>
>
[Ricky]

> This by itself is pretty convincing.
>

Except it's wrong. The successor of namedtuple is typing.NamedTuple which
supports this syntactically. From the [docs](
https://docs.python.org/3/library/typing.html#typing.NamedTuple):
```
class Employee(NamedTuple):
name: str
id: int
```

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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/WTBXYJJ7CSGDLLJHHPHSH5ZCCA4C7QEP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

On Mon, Jul 29, 2019 at 09:53:38PM -0400, Ricky Teachey wrote:

> But I ask: how is it possible, then, to create a with block that "gobbles
> up" things declared in it and adds those things to some namespace using
> existing python syntax...? 
[...]
> I currently can't create an object that allows this to work:
> 
> with NameSpace('ns') as ns:
> a = 1
> assert ns.a=1

Neither can I, and I've been mucking about with this idea for about 
three years. (To be honest, I poke it with a stick about every six
months, so its not like I've spend a lot of time on it.)

I kinda-sorta got it to work with a class statement plus a decorator, 
not too different from your metaclass example, but couldn't get 
functions to work correctly.

But if I understand the original post here:

https://mail.python.org/archives/list/python-ideas@python.org/message/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/

Batuhan Taskaya has got it to work using a dict. If that's the case, 
that seems to be the hardest part done.

(On the other hand, if this is just a hypothetical "wouldn't it be cool 
if this worked?" post, then we're actually no closer to a technical 
solution.)



-- 
Steven
___
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/M55BXCBOPRCQW6MXX6TVVIAKRDOJJEGF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> If the core developers don't consider namedtuples important enough to
> get syntactic support, I doubt that namespaces will.
>

This by itself is pretty convincing.

This doesn't "just happen", but because the interpreter does the work


I understand that; my conception of the idea was to add this syntax to the
interpreter, so that it is creating module objects.

One could get around the "why is my function broken?" issue by recycling
another already used keyword, if there could be one made to work (perhaps
import?). But you made a pretty convincing case that this is very unlikely
to happen (though I'd definitely argue for it, I think, if I thought it
were actually a possibility...).

But I ask: how is it possible, then, to create a with block that "gobbles
up" things declared in it and adds those things to some namespace using
existing python syntax...? Won't the syntax HAVE to be changed- or the way
that syntax is currently interpreted be modified- to make any of the
suggested versions of the idea possible?

I currently can't create an object that allows this to work:

with NameSpace('ns') as ns:
a = 1
assert ns.a=1

That would require blessing a big change by the core devs to work.

One could write a metaclass that does it, I suppose... but it doesn't look
particularly great to me:

import types

class NameSpace(type):
def __new__(mcls, name, bases, dct):
if bases:
raise TypeError("this is a namespace, not a class.")
mod = types.ModuleType(dct.pop("__qualname__"), dct.pop("__doc__",
None))
mod.__dict__.update(dct)
return mod

class ns(metaclass=NameSpace):
class Desc:
def __get__(self, obj, cls):
return None
d = Desc()

assert ns.d  # descriptor protocol broken as expected

This seems to work. I'm sure there are tons of things wrong with it that
could be fixed. But again, the code isn't very elegant.

>
___
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/TSYOK2JU2PGBCWPQ2GWUHESYVSWJ3HXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

On Mon, Jul 29, 2019 at 05:58:02PM -0400, Ricky Teachey wrote:

> I agree. This is why my preferred solution would be more something like I
> proposed, such as:
> 
> def my_namespace:
> a = 1
> def f(x): ...

This has the advantages of:

1. Avoiding the need to repeat the name twice.

2. Avoiding the need for a new keyword

but two serious disadvantages:

1. It is currently illegal syntax, so it doesn't work without compiler 
support. That means we can't publish it as a module on PyPy, can't 
backport it to older versions, and you have to convince the core-devs 
that both the feature itself and the syntax are worth building into the 
language.

2. It looks like a function. That means that these two very similar 
looking defs do *radically* different things:

def spam():  # creates a FUNCTION and binds to name "spam"

def spam:# creates a NAMESPACE and binds to name "spam"

That will lead to a lot of accidental "why is my namespace/function not 
working?" problems.

As a prototype, it might be possible to wrap the machinary to create a 
namespace in a function call, but as permanant language syntax, it isn't 
a good idea.


> etc etc.
> 
> I also do not see any benefit in being able to provide some arbitrary
> string as the module/namespace name, as others have proposed:
> 
> with Namespace('ns') as ns: ...

It's not ideal because we are repeating ourselves, but if its good 
enough for namedtuples, its good enough for namespaces.

If the core developers don't consider namedtuples important enough to 
get syntactic support, I doubt that namespaces will.

If namespace objects are considered a kind of module or module-like 
object, they need a name for the repr and for introspection, and they 
need to be bound to a name (a variable). The name binding is 
automatically handled by the with-statement, but how else are you going 
to inform the namespace object of its internal name?

 
> Modules are already named by the file name they reside in. Functions 
> (also defined using "def") are named using the name given to the 
> function. Same with a class.

This doesn't "just happen", but because the interpreter does the work 
of extracting the name and feeding it to the constructors, which have 
these signatures:

ModuleType(name[, doc])

FunctionType(code, globals[, name[, argdefs[, closure]]])

type(name, bases, dict)  # Creates a new class.


> Creating a namespace/module type thing 
> that receives its name as some argument would seem, to me, to be 
> orthogonal to these other situations.

How else are you going to inform the namespace object what name it 
should use internally, without interpreter support?




-- 
Steven
___
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/UWXWJ677LH2NUCL3RFLCITUJ6DAP5QMF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> This proposal seems to be harking back to the meaning of 'with' in
> earlier languages, e.g. Pascal, where it makes the fields of a
> structure temporarily accessible without qualification.
>
> Before we got the current version of 'with' in Python, there were
> periodic proposals to add a similar kind of 'with', but the
> consensus was that it was better to just assign the object to a
> short local name and qualify with that. As far as I can see, the
> situation hasn't changed.
>

I agree. This is why my preferred solution would be more something like I
proposed, such as:

def my_namespace:
a = 1
def f(x): ...

etc etc.

I also do not see any benefit in being able to provide some arbitrary
string as the module/namespace name, as others have proposed:

with Namespace('ns') as ns: ...

Modules are already named by the file name they reside in. Functions (also
defined using "def") are named using the name given to the function. Same
with a class. Creating a namespace/module type thing that receives its name
as some argument would seem, to me, to be orthogonal to these other
situations.
___
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/2SRX5SHNBTBDH7RV4A35LHSTNN6KTQWL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Greg Ewing]

This proposal seems to be harking back to the meaning of 'with' in
earlier languages, e.g. Pascal, where it makes the fields of a
structure temporarily accessible without qualification.

Before we got the current version of 'with' in Python, there were
periodic proposals to add a similar kind of 'with', but the
consensus was that it was better to just assign the object to a
short local name and qualify with that. As far as I can see, the
situation hasn't changed.

--
Greg
___
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/3REMRJJGQTXKXEVZGCLIFGI67I3XJYT3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Rhodri James]

On 26/07/2019 08:13, Batuhan Taskaya wrote:

I am proposing namespace context managers with implementing `__enter__` and
`__exit__` on dict objects.


Didn't we have this discussion recently?  What do these __enter__() and 
__exit__() do?  Please don't answer with an example, I want to 
understand what this mechanism is supposed to achieve.


Also, I can't tell if you're proposing to add __enter__ and __exit__ to 
dict objects or have the "with" statement magically add them.  Is it 
just dicts, or will any mapping type do?



It would make closures possible in python with
a pythonic syntax.

a = 4
namespace = {}

with namespace:
 a = 3

assert a == 4
assert namespace["a"] == 3


Right, so it's in effect supplying a different dictionary for local 
variables.  How do these stack?  Innermost namespace takes priority? 
Are outer namespaces accessible using nonlocal?  How does this interact 
with other sorts of namespaces?


I don't think dicts are the right place to start.  I think you want a 
specialised namespace object that supplies a mapping interface.  That 
gives you a lot more flexibility when it comes to implementation, 
amongst other things.


(I'm not actually very keen on namespaces like this, personally.  Too 
much debugging of C++ code has made me very twitchy about unstructured 
names.  That's besides the point, though.)


--
Rhodri James *-* Kynesim Ltd
___
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/XKE2D6JEE6464I66F5FOBB4BWX654L7X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> > It’s not clear to me whether people want a module-like, class-like, or
> > function-like namespace here
>
> I'm not going to speak for "people", but for me, I think that the answer
> should be obvious: it is module-like.
>

I was also talking 100% about module-like namespaces, and I also am not
clear what definition or use the other two kinds would have.
___
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/6PG7YFT2J2OTWU56M4G7LHOEJFPLW227/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ryan Gonzalez]

I feel like this could have some interesting side uses (typing on mobile so
ignore the crappy indentation):

with Namespace('a'):
 x = 1
 y = 2

print(a.__dict__) # we now have a dict

The GN build system flat-out has no dictionary / mapping type in favor of
scopes like this.

On Sun, Jul 28, 2019, 9:36 PM Steven D'Aprano  wrote:

> On Fri, Jul 26, 2019 at 10:52:46AM -0400, Calvin Spealman wrote:
>
> > Let's say you do this or any of the variants suggested... What does this
> do?
> >
> > a = {"foo": 1}
> > b = {}
> > with a:
> > with b:
> > foo = 0
>
> Re-writing that to my suggested version:
>
> with namespace("a") as a:
> with namespace("b") as b:
> foo = 0
>
> will create a namespace object (a subclass of ModuleType) and bind it to
> "a", containing a namespace object "b", containing a variable "foo":
>
> assert isinstance(a, NamespaceType)
> assert isinstance(a.b, NamespaceType)
> assert a.b.foo == 0
>
>
> That would be analogous to this existing code:
>
> class a:
> class b:
> foo = 0
>
>
> except classes have different scoping rules to modules.
>
>
> --
> Steven
> ___
> 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/W3XEBOHQS3AWJ3Z26GA3H24GBGECM6FL/
> 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/REXZHAZ2SW3CJMQHB7IETICF3XNVMRS4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

On Fri, Jul 26, 2019 at 10:52:46AM -0400, Calvin Spealman wrote:

> Let's say you do this or any of the variants suggested... What does this do?
> 
> a = {"foo": 1}
> b = {}
> with a:
> with b:
> foo = 0

Re-writing that to my suggested version:

with namespace("a") as a:
with namespace("b") as b:
foo = 0

will create a namespace object (a subclass of ModuleType) and bind it to 
"a", containing a namespace object "b", containing a variable "foo":

assert isinstance(a, NamespaceType)
assert isinstance(a.b, NamespaceType)
assert a.b.foo == 0


That would be analogous to this existing code:

class a:
class b:
foo = 0


except classes have different scoping rules to modules.


-- 
Steven
___
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/W3XEBOHQS3AWJ3Z26GA3H24GBGECM6FL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Steven D'Aprano]

On Fri, Jul 26, 2019 at 01:37:29PM -0700, Andrew Barnert wrote:

> It’s not clear to me whether people want a module-like, class-like, or 
> function-like namespace here, but I do think it’s probably exactly one 
> of those three. And it’ll be a lot easier to define and implement—and 
> for everyone to understand future Python code—if it is.

I'm not going to speak for "people", but for me, I think that the answer 
should be obvious: it is module-like.

I'm not even sure what you mean by "function-like" or "class-like" 
namespaces. Functions aren't namespaces (except in the sense that they 
are objects with a __dict__ and so support attributes): you can't access 
a function locals from the outside. Classes are namespaces, but if you 
want a namespace that behaves like a class, use a class.

For me, the idea is to (optionally) decouple module objects from .py 
files. Of course most of the time when you want a module object, it is 
most useful to split the code out into a seperate file, and that won't 
change.

But there are times when you have a relatively small amount of code that 
cries to be split off into a seperate namespace, but shifting it into a 
seperate physical file is inconvenient. Going from one physical file to 
two physical files is a significant jump in project complexity that's 
not always worth the cost.

So a namespace object that behaves like a module but doesn't need to 
split off into a seperate .py file would be helpful.

The code in a namespace object ought to behave precisely the same as 
if it were copied into a seperate file. (*Almost* -- see below.)

That is, given some module file containing code:

# module.py
code


I should be able to copy the content of the file ("code"), and paste it 
into another file like this:

# another.py
with Namespace("module") as module:
# paste and indent here
code


and the resulting namespace object bound to the name "module" should be 
(almost) identical to what you would have got from calling "import 
module" in the first place.

A few possible differences:

1. It isn't clear what the namespace __file__ and __package__ attributes
   ought to contain, or if it should have them at all.

2. For introspection purposes, and to allow for possible future 
   changes, it might be wise to use a subclass of ModuleType for 
   namespace objects.

3. The repr will probably be different.

One more difference needs a bit of explanation:

The standard scoping rule used by Python is LEGB, which goes:

- Local
- Enclosing functions (non-local/closures)
- Global (module)
- Builtins

with a slight variation on that for code inside classes. So when you run 
code in module.py, the global namespace it sees is module.py i.e. 
itself.

But consider what happens when you copy the code from module.py and 
paste it into another file, into a namespace. It would be surprising if 
the code inside the namespace with block couldn't see module level 
globals. So we need a slight variation on the scoping rule:

- Local
- Enclosing functions (non-local/closures)
- Namespace
- Global (module)
- Builtins

(and an analogous change for when classes are involved). To make it more 
clear with a concrete example:


a = 1
b = 2
c = 3
with Namespace("ns") as ns:
a = 100
b = 200
def function():
a = 999
return a, b, c


ns.function() ought to return (999, 200, 3).

This implies a small difference in behaviour for code in a namespace 
versus a seperate physical file. If I copied that code block out of ns 
above, and pasted it into a physical file, then running function() would 
raise:

NameError: name 'c' is not defined

I think that this slight difference will be considered desirable, 
unsurprising (it would be surprising if namespaces didn't see their 
surrounding global scope, and even more surprising if external modules 
could pry into another module!) and hopefully uncontroversial.


> I don’t think anyone cares about fast locals here, and I hope nobody 
> cares about things like super magic.

A function shouldn't become slower just because you move it into a 
namespace. And classes ought to behave the same, including super, 
whether they were defined inside or outside a namespace.


> But the differences in how 
> variables in the namespace interact with functions and classes (and 
> new-kind-of-namespace-things) defined within the namespace do probably 
> matter. And you’d probably want to know what to expect from eval/exec, 
> locals/globals/vars, etc., 

Absolutely! There are a couple of tricky corner cases involving eval 
(and exec?) already, related to comprehensions. They will need to be 
ironed out.

I've spent some time (unsuccessfully) trying to get this to work using a 
class statement:

@namespace
class ns:
a = 100
def function():
print(a)

but I couldn't get the function inside the class to see the surrounding 
"a". If Batuhan Taskaya has solved that problem using a with statement, 
it sounds like there's no 

[Python-ideas] Re: Namespace context managers

[Andrew Barnert via Python-ideas]

On Jul 26, 2019, at 05:25, Ricky Teachey  wrote:

> This is a neat idea and I have wanted something similar myself in situations 
> I do not want to instantiate class object or break code out to another module.
> 
> Controversial opinion: it may even justify a keyword.  But it wouldn't have 
> to be a new one, def could work just fine:
> 
> def ns:
> a = 3 

It’s not clear to me whether people want a module-like, class-like, or 
function-like namespace here, but I do think it’s probably exactly one of those 
three. And it’ll be a lot easier to define and implement—and for everyone to 
understand  future Python code—if it is.

I don’t think anyone cares about fast locals here, and I hope nobody cares 
about things like super magic. But the differences in how variables in the 
namespace interact with functions and classes (and 
new-kind-of-namespace-things) defined within the namespace do probably matter. 
And you’d probably want to know what to expect from eval/exec, 
locals/globals/vars, etc., because someone is going to do that and you want it 
to be obvious what it means, rather than having to dig through the spec or 
trial-and-error at the interactive prompt to figure it out. And people probably 
occasionally want to know how to do the same thing programmatically (just like 
people occasionally want to know how to call a metaclass explicitly). But the 
nesting is the key question.

Meanwhile, do we even need to name the namespace? While it does allow the 
JS-style trick you gave for defining a “prototype” object without a class, do 
we actually want that in Python? And are there any other practical uses for 
names here? If not, there’s a really easy design and implementation, something 
like one of the following:

A bare “def:” statement defines a function, doesn’t bind it to anything, calls 
it with no args, and discards both the function and the result. So locals, 
nonlocal, eval, etc. work exactly the same way as in any other def body.

A bare “class:” statement defines a class namespace, doesn’t call the 
metaclass, and doesn’t bind anything to anything. Again, everything works 
exactly the same way as in any other class body.

A bare “import:” statement defines a module namespace, doesn’t construct a 
module out of it, and doesn’t bind anything to anything.

> Final observation: I think one shortfall in python is that it nudges the user 
> to use OOP a little bit too forcefully

I think it’s a strength of Python that it uses OOP under the hood for all kinds 
of stuff, but usually doesn’t make you think in OOP terms while writing and 
reading the code. And I think your version of the proposal takes it farther in 
that direction, which is good.

For example, nobody thinks of def as being syntactic sugar for constructing an 
object of type function that has a descriptor that returns an object of type 
method, and then binding it to a name. It just defines a method on a class, and 
it works. But, because that’s what it does under the covers, on the rare 
occasions where you need to go under the covers, you use the same OO style as 
with everything else. Compare that to the way reflection on methods works in, 
say, ObjC, where you end up calling a bunch of C functions, and passing them 
not actual classes and methods but pointers to opaque Class and Selector 
objects, and it feels more like you’re writing an ObjC interpreter than writing 
ObjC code.

___
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/C3T65OO4UAELIGMPMPYQXASMLPN5OMWY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ethan Furman]

On 07/26/2019 09:52 AM, Dan Sommers wrote:


There Is Only One Way To Do It.


There should be one-- and preferably only one --obvious way to do it.

There is very little in Python that can only be done one way.

--
~Ethan~
___
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/LLLBNAM2M5WNCHVCRICEG75K6AWX2DLE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Dan Sommers]

On 7/26/19 12:23 PM, Ricky Teachey wrote:
>>
>> The class statement works in this fashion.
>>
> I would argue there are at least 2 significant reasons why a separate
> namespace would be preferred over using class in this way:

[...]

> 2. using class means that all of the "new style class" machinery
> is at work-- for good or for ill-- when working in your
> class-defined namespace.  so if, for example, you create a
> descriptor and instantiate it inside a class namespace, the
> descriptor __get__ method will be invoked when accessing the
> descriptor via the class name. this could be very limiting in
> certain cases.

Flat is better than nested.  Yes, at some point, flat becomes unweildy,
and you have to do something.  Or not.

Simple is better than complex.  With every one of these nesting
constructs (e.g., comprehensions, classes, functions, methods, modules),
there are possibly subtle scoping and name lookup rules.  For every new
such construct, there are new and possibly subtle such rules.  At some
point, the expressiveness of a language disappears into the noise of
complexity (no, I don't have a citation, just lots of experience).

There Is Only One Way To Do It.  Enough said.

I'm pretty sure I'm not a luddite, but I'm also pretty sure that new
ways to capture ("close over") a value and/or to encapsulate state is a
long way from your father's executable pseudo code.

Yes, at some point, every little throwaway automation script takes on a
life of its own, and you have to make a choice.  Please choose the
simplicity of small reusable building blocks (aka modules full of
functions; or classes full of methods if you must) rather than yet
another way to inline your encapsulation.
___
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/R24IUB5VSCEHF7LRHA4FQXD55N7O2YEJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> The class statement works in this fashion.
>
>
I would argue there are at least 2 significant reasons why a separate
namespace would be preferred over using class in this way:

   1. using class in this way signals to the user that you are writing a
   class (ie, meant to be instantiated), and not a namespace; the author has
   to tell the reader it isn't actually intended to be a class in the
   docstring or in the class name ("eg, MyNamespace")
   2. using class means that all of the "new style class" machinery is at
   work-- for good or for ill-- when working in your class-defined namespace.
   so if, for example, you create a descriptor and instantiate it inside a
   class namespace, the descriptor __get__ method will be invoked when
   accessing the descriptor via the class name. this could be very limiting in
   certain cases.
___
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/KUFOJ4FK2H76JA5KO3H5AZAY2NYD3P5M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Michael Selik]

The class statement works in this fashion.

foo = 1
class Bar:
foo = 2

assert foo = 1
assert Bar.foo = 2

On Fri, Jul 26, 2019, 12:19 AM Batuhan Taskaya 
wrote:

> I am proposing namespace context managers with implementing `__enter__`
> and `__exit__` on dict objects. It would make closures possible in python
> with a pythonic syntax.
>
> a = 4
> namespace = {}
>
> with namespace:
> a = 3
>
> assert a == 4
> assert namespace["a"] == 3
> ___
> 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/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
> 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/SL2VZACTCSYB76BZI5QFP2CE3WSUFXPA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Batuhan Taskaya]

> a = {"foo": 1}
> b = {}
> with a:
>with b:
>   foo = 0
It doesnt change `foo` value of `a` namespace unless `nonlocal` usage.

assert a == {"foo": 1}
assert b == {"foo": 0}

On Fri, Jul 26, 2019 at 5:53 PM Calvin Spealman  wrote:

> Let's say you do this or any of the variants suggested... What does this
> do?
>
> a = {"foo": 1}
> b = {}
> with a:
> with b:
> foo = 0
>
> On Fri, Jul 26, 2019 at 3:20 AM Batuhan Taskaya 
> wrote:
>
>> I am proposing namespace context managers with implementing `__enter__`
>> and `__exit__` on dict objects. It would make closures possible in python
>> with a pythonic syntax.
>>
>> a = 4
>> namespace = {}
>>
>> with namespace:
>> a = 3
>>
>> assert a == 4
>> assert namespace["a"] == 3
>> ___
>> 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/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> cspea...@redhat.com  M: +1.336.210.5107
> [image: https://red.ht/sig] 
> TRIED. TESTED. TRUSTED. 
>
___
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/MMPDY47QNAMBYZITWSBAF3W3ZANPJPED/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Calvin Spealman]

Let's say you do this or any of the variants suggested... What does this do?

a = {"foo": 1}
b = {}
with a:
with b:
foo = 0

On Fri, Jul 26, 2019 at 3:20 AM Batuhan Taskaya 
wrote:

> I am proposing namespace context managers with implementing `__enter__`
> and `__exit__` on dict objects. It would make closures possible in python
> with a pythonic syntax.
>
> a = 4
> namespace = {}
>
> with namespace:
> a = 3
>
> assert a == 4
> assert namespace["a"] == 3
> ___
> 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/TAVHEKDZVYKJUGZKWSVZVAOGBPLZVKQG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

cspea...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
___
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/WIXNCWAEKSOUP6IY7CPCY6TOUJJSTDOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Anders Hovmöller]

On 26 Jul 2019, at 14:25, Ricky Teachey  wrote:

>> a = 4
>> 
>> with Namespace("ns") as ns:
>> a = 3
>> print(a)  # prints "3", not "4"
>> 
>> def func():
>> return a  # Closes on ns.a, not global a
>> 
>> assert isinstance(ns, types.ModuleType)
>> assert ns.name = "ns"
>> assert ns.func() == 3
>> assert a == 4
>  
> This is a neat idea and I have wanted something similar myself in situations 
> I do not want to instantiate class object or break code out to another module.
> 
> Controversial opinion: it may even justify a keyword.  But it wouldn't have 
> to be a new one, def could work just fine:
> 
> def ns:
> a = 3 
> 
> Food goodly or for badly: something like this would allow one to write code 
> similar to how you can in javascript (by simply putting it in curly braces in 
> js), without going to the effort of creating a full fledged class:
> 
> def a:
> x = 1
> def b:  
> x = 2
> def func():
> return x  # prints 1  
> 

This looks pretty nice. Seems like it can be implemented with a subclass of 
dict pretty easily if we change the syntax a bit:

a = ns(
  x=1,
  b=ns(
x=2),
  func=lambda self: self.x)
)

?___
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/KONYW4MWQC42YIREPDHI6HO53PGTUUFH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Ricky Teachey]

>
> a = 4
>
> with Namespace("ns") as ns:
> a = 3
> print(a)  # prints "3", not "4"
>
> def func():
> return a  # Closes on ns.a, not global a
>
> assert isinstance(ns, types.ModuleType)
> assert ns.name = "ns"
> assert ns.func() == 3
> assert a == 4
>

This is a neat idea and I have wanted something similar myself in
situations I do not want to instantiate class object or break code out to
another module.

Controversial opinion: it may even justify a keyword.  But it wouldn't have
to be a new one, def could work just fine:

def ns:
a = 3

Food goodly or for badly: something like this would allow one to write code
similar to how you can in javascript (by simply putting it in curly braces
in js), without going to the effort of creating a full fledged class:

def a:
x = 1
def b:
x = 2
def func():
return x  # prints 1

print(a.b.x)  # prints 2

Final observation: I think one shortfall in python is that it nudges the
user to use OOP a little bit too forcefully-- especially inexperienced
users, after learning how to write a class the first time. I remember very
well regretting using classes quite a bit too readily in my first couple
years of coding (on year 6 now), when a module would have done much better.
It's true you CAN create a module object and do all of this, but as a
relatively "non expert user" IMO it is very opaque syntax for someone
getting started.
___
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/6HHDIOYGIYLHQGOVE7UAZRCXLR2HGSWT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Namespace context managers

[Batuhan Taskaya]

As an extra it will be identical with contextvars but it is going work on
builtin dicts.

On Fri, Jul 26, 2019 at 10:13 AM Batuhan Taskaya 
wrote:

> I am proposing namespace context managers with implementing `__enter__`
> and `__exit__` on dict objects. It would make closures possible in python
> with a pythonic syntax.
>
> a = 4
> namespace = {}
>
> with namespace:
> a = 3
>
> assert a == 4
> assert namespace["a"] == 3
>
___
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/GHMOUUC36KREUCQMJ67SRUR7WRTCCF7O/
Code of Conduct: http://python.org/psf/codeofconduct/