Re: [Python-ideas] Add shutil.chown(..., recursive=False)

[Steven D'Aprano]

On Tue, May 29, 2018 at 10:11:22AM +1000, Chris Angelico wrote:
> On Tue, May 29, 2018 at 9:47 AM, Steven D'Aprano  wrote:

> > Certainly not. You only have to be root to change permissions on files
> > that you otherwise wouldn't be able to change permissions on. chmod -R
> > works fine for regular users changing their own files. Why wouldn't it?
> 
> That's chmod. The OP asked about chown.

/face-palm

Indeed he did. But it doesn't matter: regular users can call chown -R:

[steve@ando ~]$ chown -R steve.users test
[steve@ando ~]$ ls -lR test
test:
total 12
-rw-rw-rw- 1 steve users5 Feb  4  2017 eggs.py
drwxrwxrwx 2 steve users 4096 May 29 09:41 package
-rw-rw-rw- 1 steve users   40 Feb  4  2017 spam.py

test/package:
total 0
-rw-rw-rw- 1 steve users 0 May 29 09:41 __init__.py
-rw-rw-rw- 1 steve users 0 May 29 09:41 spam.py


The limitations on calling chown apply equally to the recursive and 
non-recursive case.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add shutil.chown(..., recursive=False)

[Chris Angelico]

On Tue, May 29, 2018 at 9:47 AM, Steven D'Aprano  wrote:
> On Mon, May 28, 2018 at 10:13:47PM +0100, Barry wrote:
>>
>> > On 28 May 2018, at 21:23, Giampaolo Rodola'  wrote:
> [...]
>> > It appears like a common enough use case to me ("chown -R path").
>> > Thoughts?
>>
>> I wonder if it is very common.
>> Don’t you have to be root or use sudo chown?
>> In which case it is only python code running as root that could use this.
>
> Certainly not. You only have to be root to change permissions on files
> that you otherwise wouldn't be able to change permissions on. chmod -R
> works fine for regular users changing their own files. Why wouldn't it?

That's chmod. The OP asked about chown.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add shutil.chown(..., recursive=False)

[Steven D'Aprano]

On Mon, May 28, 2018 at 10:13:47PM +0100, Barry wrote:
> 
> > On 28 May 2018, at 21:23, Giampaolo Rodola'  wrote:
[...]
> > It appears like a common enough use case to me ("chown -R path"). 
> > Thoughts?
> 
> I wonder if it is very common.
> Don’t you have to be root or use sudo chown?
> In which case it is only python code running as root that could use this.

Certainly not. You only have to be root to change permissions on files 
that you otherwise wouldn't be able to change permissions on. chmod -R 
works fine for regular users changing their own files. Why wouldn't it?


[steve@ando ~]$ ls -lR test
test:
total 12
-rw-rw-r-- 1 steve steve5 Feb  4  2017 eggs.py
drwxrwxr-x 2 steve steve 4096 May 29 09:41 package
-rw-rw-r-- 1 steve steve   40 Feb  4  2017 spam.py

test/package:
total 0
-rw-rw-r-- 1 steve steve 0 May 29 09:41 __init__.py
-rw-rw-r-- 1 steve steve 0 May 29 09:41 spam.py

[steve@ando ~]$ chmod -R a-w test
[steve@ando ~]$ ls -lR test
test:
total 12
-r--r--r-- 1 steve steve5 Feb  4  2017 eggs.py
dr-xr-xr-x 2 steve steve 4096 May 29 09:41 package
-r--r--r-- 1 steve steve   40 Feb  4  2017 spam.py

test/package:
total 0
-r--r--r-- 1 steve steve 0 May 29 09:41 __init__.py
-r--r--r-- 1 steve steve 0 May 29 09:41 spam.py



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Greg Ewing]

Michael Lohmann wrote:

I just wanted to override the
class-variable `magic_number` to give a reason why I don’t ever want to call
Magic.__init__ in Foo. If you want, you can have this class instead:

class Magic:

> def __init__(self): raise RuntimeError("Do not initialize this

class")

>

but I figured that this might look a bit artificial...


But your original example looks just as artificial. Skipping
the initialisation of a class you're inheriting from is an
extremely weird thing to do, and in any real-life situation
there's almost certainly a better design.

In any case, I don't see how this has anything to do with
invisible passing of **kwds.

In short, I don't understand what you're saying at all.

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Greg Ewing]

Michael Lohmann wrote:


   class Ethel(Aardvark, Clever):
   """Ethel is a very clever Aardvark"""
   def __init__(self):
   super().__init__(quantity="some spam", cleverness=1000))

>>

if you want to instantiate an Aardvark directly there is NO WAY EVER that
you could give him ANY kwargs. So why should the __init__ indicate
something else?


You seem to want the signature of Ethel.__init__ to indicate exactly
what arguments it can accept.

But even with your proposed feature, that isn't going to happen.
It will only show arguments that appear explicitly in Ethel.__init__'s
argument list. If it didn't override the default value for cleverness,
you would never know that it was a possible parameter.

In situations like this there's no substitute for hand-written
documentation, and that can include explaining what is allowed
for **kwds.

--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add shutil.chown(..., recursive=False)

[Wes Turner]

path.py Path.choen supports names in addition to the uid/gid numbers which
os.chown supports:

https://pathpy.readthedocs.io/en/stable/api.html#path.Path.chown
https://github.com/jaraco/path.py/blob/master/path.py#L1176

https://pathpy.readthedocs.io/en/stable/api.html#path.Path.walk


On Monday, May 28, 2018, Giampaolo Rodola'  wrote:

>
>
> On Mon, May 28, 2018 at 11:13 PM, Barry  wrote:
>
>>
>> On 28 May 2018, at 21:23, Giampaolo Rodola'  wrote:
>>
>> ...as in (not tested):
>>
>> def _rchown(dir, user, group):
>> for root, dirs, files in os.walk(dir, topdown=False):
>> for name in files:
>> chown(os.path.join(root, name), user, group)
>>
>> def chown(path, user=None, group=None, recursive=False):
>> if recursive and os.path.isdir(path):
>> _rchown(dir, user, group)
>> ...
>>
>> It appears like a common enough use case to me ("chown -R path").
>> Thoughts?
>>
>>
>> I wonder if it is very common.
>> Don’t you have to be root or use sudo chown?
>> In which case it is only python code running as root that could use this.
>>
>> Barry
>>
>
> You're right, I didn't think about that. I remember myself doing "chown -R
> dir" every once in a while but didn't recall I prepended "sudo". =)
>
> --
> Giampaolo - http://grodola.blogspot.com
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add shutil.chown(..., recursive=False)

[Barry]

> On 28 May 2018, at 21:23, Giampaolo Rodola'  wrote:
> 
> ...as in (not tested):
> 
> def _rchown(dir, user, group):
> for root, dirs, files in os.walk(dir, topdown=False):
> for name in files:
> chown(os.path.join(root, name), user, group)
> 
> def chown(path, user=None, group=None, recursive=False):
> if recursive and os.path.isdir(path):
> _rchown(dir, user, group)
> ...
> 
> It appears like a common enough use case to me ("chown -R path"). 
> Thoughts?

I wonder if it is very common.
Don’t you have to be root or use sudo chown?
In which case it is only python code running as root that could use this.

Barry
> 
> -- 
> Giampaolo - http://grodola.blogspot.com
> 
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add shutil.chown(..., recursive=False)

[Giampaolo Rodola']

...as in (not tested):

def _rchown(dir, user, group):
for root, dirs, files in os.walk(dir, topdown=False):
for name in files:
chown(os.path.join(root, name), user, group)

def chown(path, user=None, group=None, recursive=False):
if recursive and os.path.isdir(path):
_rchown(dir, user, group)
...

It appears like a common enough use case to me ("chown -R path").
Thoughts?

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] multiprocessing, freeze support by default for Pool

[Brett Cannon]

I would just open an issues on bugs.python.org for this.

On Wed, 23 May 2018 at 17:54 Bradley Phillips <
bradleyp81+python-id...@gmail.com> wrote:

> Hi All
>
> There are about 347 results for the following query on the google search
> engine:
> "python multiprocessing pyinstaller crash site:stackoverflow.com"
>
> The windows fork bomb is a known frequent occurrence. I know that
> freeze_support is supposed to be called but this issue still catches me out
> most times (and many others).
>
> I propose adding to line 117 of multiprocessing/context.py
> if (sys.platform == 'win32'):
> self.freeze_support()
>
> Thanks
> Regards
> Brad
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposal: A Reduce-Map Comprehension and a "last" builtin

[Nick Coghlan]

On 28 May 2018 at 10:17, Greg Ewing  wrote:

> Nick Coghlan wrote:
>
>> Aye, while I still don't want comprehensions to implicitly create new
>> locals in their parent scope, I've come around on the utility of letting
>> inline assignment targets be implicitly nonlocal references to the nearest
>> block scope.
>>
>
> What if you're only intending to use it locally within the
> comprehension? Would you have to put a dummy assignment in
> the surrounding scope to avoid a NameError? That doesn't
> sound very nice.
>

The draft PEP discusses that - it isn't saying "Always have them raise
TargetNameError, now and forever", it's saying "Have them raise
TargetNameError in the first released iteration of the capability, so we
can separate the discussion of binding semantics in scoped expressions from
the discussion of declaration semantics".

I still want to leave the door open to giving comprehensions and lambdas a
way to declare and bind truly local variables, and that gets more difficult
if we go straight to having the binding expressions they contain
*implicitly* declare new variables in the parent scope (rather than only
binding previously declared ones).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Jacco van Dorp]

Bright idea the moment after sending that mail:

You could remove the globals() hack if you make it a class decorator instead.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Jacco van Dorp]

2018-05-28 11:07 GMT+02:00 Michael Lohmann :
> But maybe it is just me who thinks that you should make it as obvious as 
> possible what a class itself really can get as an input and what is done just 
> to get the multiple inheritance to work... So I think if no one else agrees 
> with me, we don’t need to further spam everybody.

I think the largest difference is that most people have a different
opinion about what is more explicit/obvious.
It does look like you could build something like this for yourself
with a decorator:

from inspect import signature, Parameter

def forwards_kwargs_to_super(classname):
def deco(method):
sig = signature(method)
numargs = len([param for param in sig.parameters.values() if
param.kind is Parameter.POSITIONAL_ONLY])
keykwargs = {param.name for param in sig.parameters.values()
if param.kind in (Parameter.POSITIONAL_OR_KEYWORD,
Parameter.KEYWORD_ONLY)}
def newinit(self, *args, **kwargs):
print(f"Call looks like: {classname}: {args[:numargs]}, {
{key: val for key, val in kwargs.items() if key in keykwargs} }")
method(self, *args[:numargs], **{key: val for key, val in
kwargs.items() if key in keykwargs})
super(globals()[classname],
self).__init__(*args[numargs:], **{key: val for key, val in
kwargs.items() if key not in keykwargs})
return newinit
return deco


And then use it like this:

class Aardvark:
@forwards_kwargs_to_super("Aardvark")
def __init__(self, quantity):
print("There is some quantity:", quantity)
# I actually don’t care about **kwargs and just hand them on

class Clever:
@forwards_kwargs_to_super("Clever")
def __init__(self, cleverness=1):
print("You are %d clever" % cleverness)

class Ethel(Aardvark, Clever):
"""Ethel is a very clever Aardvark"""
@forwards_kwargs_to_super("Ethel")
def __init__(self):
pass

e = Ethel(quantity="some spam", cleverness=100)


Disclaimer:
 - Whenever you import the inspect module, you should ask yourself
whether it's really a good idea.
 - I'm assuming that decorated functions have no *args or **kwargs in
their signature that you DO want to accept, and that all arguments
with a default value are given as keyword arguments.
 - If you are passing new positional arguments with this function, the
subclass positional arguments need to come before the superclass
positional arguments (only important if both have positional
arguments.)
 - If you use multiple decorators, this should be the innermost
decorator, or it'll probably make your code barf at runtime.
 - If you try do this in my company, i'll do whatever I can to get you
fired. For the love of Python, don't use this code at places where
anybody except you has to do maintenance. And if you come back in half
a year and are amazed by your own code, I promise you'll understand
why this might not be a real good solution.
 - Yes, passing your class name and then getting it from globals is an
ugly hack. The alternative is grabbing it from the stack. If anybody
else has a better idea, feel free, but AFAIK it's impossible to do
this better. (I once wrote an overload decorator as a personal
exercise, using the stack hack.)
 - I haven't tested this with actual positional arguments, but I
-think- it will work.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Jacco van Dorp]

2018-05-28 9:44 GMT+02:00 Michael Lohmann :
>
>> I'd say NOT wanting to call an __init__ method of a superclass is a
>> rather uncommon occurence. It's generally a huge error. So I think
>> it's worth not accomodating that.
>
> I will give you an example then where I am absolutely fine with calling 
> super().__init__ in all classes and describe why I am not really satisfied 
> with the current status. (It is from my email from yesterday 17:19 GMT):
>
>> What bugs me is that in my example from yesterday (
>> class Aardvark:
>> def __init__(self, quantity, **kwargs):
>> print("There is some quantity:", quantity)
>> # I actually don’t care about **kwargs and just hand them on
>> super().__init__(**kwargs)
>>
>> class Clever:
>> def __init__(self, cleverness=1):
>> print("You are %d clever“ % cleverness)
>>
>> class Ethel(Aardvark, Clever):
>> """Ethel is a very clever Aardvark"""
>> def __init__(self):
>> super().__init__(quantity="some spam", cleverness=1000)
>> ) if you want to instantiate an Aardvark directly there is NO WAY EVER that 
>> you could give him ANY kwargs. So why should the __init__ indicate something 
>> else? Well, just to make the MRO work. All I want is to make it as obvious 
>> as possible that an Aardvark only takes `quantity` as input, but is fully 
>> "cooperative" with other classes if it is in the middle of the MRO (by which 
>> I mean that it will automatically call the __init__ and hand on any kwargs 
>> it didn’t expect to a class from a different branch of the class hierarchy).

This is more an issue with your Ethel class. In *normal* subclassing,
it's init would look like:

class Ethel(Aardvark, Clever):
def __init__(self, **kwargs):
super().__init__(**kwargs)

and you'd instantiate it like:
e = Ethel(quantity="some spam", cleverness=1000)
or even (because keyword argument order doesn't matter):
e = Ethel(cleverness=1000, quantity="some spam")

Because don't forget:
assert isinstance(e, Ethel)
assert isinstance(e, Aardvark)
assert isinstance(e, Clever)

will all pass perfectly fine. It's not just an Ethel or an Aardvark,
it's also a Clever. (which doesn't sound like it makes sense...perhaps
clever should be an attribute on an Aardvark/Ethel instead ?).

That all aside, for a moment. You actually CAN call
object.__init__(**kwargs) no problem - as long as kwargs is empty. I'd
have written your classes like this:

class Aardvark:
def __init__(self, quantity, **kwargs):
print("There is some quantity:", quantity)
# I actually don’t care about **kwargs and just hand them on
super().__init__(**kwargs)

class Clever:
def __init__(self, cleverness=1, **kwargs):
print("You are %d clever" % cleverness)
super().__init__(**kwargs)

class Ethel(Aardvark, Clever):
"""Ethel is a very clever Aardvark"""
def __init__(self, **kwargs):
super().__init__(**kwargs)

Just try it - it works perfectly fine. Each constructor will consume
the keywords meant for it, therefore, the last super() call will call
the object constructor without keyword arguments.

**kwargs is the price we have to pay for good multiple inheritance -
and IMO, it's a low one.

If we're talking about signalling what the arguments mean, just ensure
you have a good docstring.

class Aardvark:
def __init__(self, quantity, **kwargs):
"""
Aardvarks are gentle creatures, and therefore cooperate with
multiple inheritance.
:param quantity: The quantity of Aardvark(s).
"""
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Michael Lohmann]

> I'd say NOT wanting to call an __init__ method of a superclass is a
> rather uncommon occurence. It's generally a huge error. So I think
> it's worth not accomodating that.

I will give you an example then where I am absolutely fine with calling 
super().__init__ in all classes and describe why I am not really satisfied with 
the current status. (It is from my email from yesterday 17:19 GMT):

> What bugs me is that in my example from yesterday (
> class Aardvark:
> def __init__(self, quantity, **kwargs):
> print("There is some quantity:", quantity)
> # I actually don’t care about **kwargs and just hand them on
> super().__init__(**kwargs)
> 
> class Clever:
> def __init__(self, cleverness=1):
> print("You are %d clever“ % cleverness)
> 
> class Ethel(Aardvark, Clever):
> """Ethel is a very clever Aardvark"""
> def __init__(self):
> super().__init__(quantity="some spam", cleverness=1000)
> ) if you want to instantiate an Aardvark directly there is NO WAY EVER that 
> you could give him ANY kwargs. So why should the __init__ indicate something 
> else? Well, just to make the MRO work. All I want is to make it as obvious as 
> possible that an Aardvark only takes `quantity` as input, but is fully 
> "cooperative" with other classes if it is in the middle of the MRO (by which 
> I mean that it will automatically call the __init__ and hand on any kwargs it 
> didn’t expect to a class from a different branch of the class hierarchy).
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Jacco van Dorp]

I'd say NOT wanting to call an __init__ method of a superclass is a
rather uncommon occurence. It's generally a huge error. So I think
it's worth not accomodating that.

2018-05-28 9:27 GMT+02:00 Michael Lohmann :
>
>>>class Magic:
>>>magic_number = 42
>>>def __init__(self):
>>>A.magic_number = 0  # As soon as you look too deep into it all 
>>> the Magic vanishes
>>
>> What is A here? Did you mean something else?
>
> Sorry for that. Yes, it should have been Magic (I renamed the class after 
> writing it and didn’t pay attention). I just wanted to override the 
> class-variable `magic_number` to give a reason why I don’t ever want to call 
> Magic.__init__ in Foo. If you want, you can have this class instead:
>
> class Magic:
> def __init__(self):
> raise RuntimeError("Do not initialize this class")
>
> but I figured that this might look a bit artificial...
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Keyword for direct pass through of kwargs to super

[Michael Lohmann]

>>class Magic:
>>magic_number = 42
>>def __init__(self):
>>A.magic_number = 0  # As soon as you look too deep into it all 
>> the Magic vanishes
> 
> What is A here? Did you mean something else?

Sorry for that. Yes, it should have been Magic (I renamed the class after 
writing it and didn’t pay attention). I just wanted to override the 
class-variable `magic_number` to give a reason why I don’t ever want to call 
Magic.__init__ in Foo. If you want, you can have this class instead:

class Magic:
def __init__(self):
raise RuntimeError("Do not initialize this class")

but I figured that this might look a bit artificial...
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] ternary without else

[Jacco van Dorp]

2018-05-26 11:24 GMT+02:00 Antoine Rozo :
> Dismiss my message, I have read `if "art_wt" not in article`. But in the
> same way, you could have a function to reset a value in your dict if the
> current value evaluates to False.

That won't work, since at other places, I do the same with bools and
strings in the same dict. (I read out an online database, which only
yields data in json format. I dont want an extra parsing step to
transform it to another data structure than dicts. ). Also, empty
fields are set to None, no matter actual field type(actually, it
doesn't pass empty fields for some godawful reason, so I have a
__missing__ that returns None if and only if it's in a list of
expected fields. ).

As for the dangling else problem, noting a good rule (left to right ?)
and a few parens in other cases can't fix.

That said, because of the rest of this thread, it seems to me like a
statement would be the proper implementation. So the thread title has
become misleading. This would remove the dangling else problem unless
there's an if/else in the condition, which I can't figure out why
you'd need that.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "Assignment expression" with function call-alike syntax

[Jacco van Dorp]

2018-05-26 11:00 GMT+02:00 Kirill Balunov :
> The main point is to collect more information, since the idea of assignment
> expression will have a huge impact in all aspects of Python programming: how
> you structure your programm, how you write code, how you read code, how you
> parse code... Because at the moment the rule is simple that any name binding
> must occur only in statements.
>
> With kind regards,
> -gdg

Downside here is, if you first implement it like this, everyone will
be used to that implementation. If after that a special syntax gets
introduced, there will be people confusing it and having to use
multiple libraries which use the two different ways. And most people
will stick to the old way because it'll have more compatible python
versions, no matter how much better a new syntax could be. Unless you
want a deprecation cycle planning for a feature not even implemented
yet ?

I think that if implemented, it needs to be the final implementation right away.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/