[Python-ideas] Re: Efficiency of set difference

[Serhiy Storchaka]

06.06.22 10:51, Stephen J. Turnbull пише:

Couldn't it be linear on min(len(left), len(right))?  Ie,

 if len(left) < len(right):
 for elem in left:
 if elem in right:
left.discard(elem)
 else:
 for elem in right:
 left.discard(elem)

The upper loop is probably only about half as fast as the lower (two
hashes needed), so maybe the length test could be tuned.

The whole idea is probably not worth it, I can't think of practical
use cases at a scale where it would matter.


It is close to the current implementation:

 if len(left) < len(right)//8:
 right = left & right
 for elem in left:
 if elem in right:
left.discard(elem)

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

[Python-ideas] Re: Expand the try-expect syntax to support conditional expect block

[Serhiy Storchaka]

03.06.22 21:43, Nadav Misgav пише:

should I try to implement this? seems there is some acceptance


No core developer supported this feature.

My example shows that there is a problem with the proposed syntax. It is 
too similar to the existing valid syntax, it will confuse both people 
and the compiler. Even if the current parser is able to handle this, we 
should not abuse this, because it will still look ambiguous to people 
and diagnostic of syntax errors will be very hard.


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

[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions

[Serhiy Storchaka]

01.06.22 16:59, Chris Angelico пише:

On Wed, 1 Jun 2022 at 23:55, Serhiy Storchaka  wrote:

The advantage is that you cannot accidentally turn a function into a
generator by adding "yield". If the result of the call is ignored (it is
expected to be None), this bug can live a long time. It is a common
issue: test containing yield always passes. Since 3.11 the unittest
module emits a warning if a test method returns not None, but it will
not solve all problems: the test can call helpers, and if they are
generators, the call is virtually no-op. This error can also occur in
non-test code.


That might be nice, but without a massive backward compatibility break
(or another keyword for non-generator functions), it can't happen. Is
there any advantage to being able to declare that it must be a
generator (as opposed to simply returning a generator object)?


The advantage is not in the ability to declare that it must be a 
generator, but in the ability to declare that it must not be a generator 
(and this should be the default).


Of course it is a massive backward compatibility break, and the 
transition should be very slow and careful. First introduce a new 
optional syntax for generator functions, after 4 or 5 years (when all 
maintained Python versions support the new syntax) start to emit a quiet 
warning for a generator function with old syntax, after few more years 
make it more loud, and finally, after yet more years, an error. In 
between, third-party linters can start complaining about old syntax, 
first these warnings will be disable by default. It all will take 8-10 
years or more. Or we can just break the world in Python 4.0 (but this is 
not the plan).


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

[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions

[Serhiy Storchaka]

31.05.22 16:21, Chris Angelico пише:

On Tue, 31 May 2022 at 23:00, Aaron L via Python-ideas
 wrote:

After getting used to writing async functions, I’ve been wanting use a similar 
syntax to declare generator functions.


What's the advantage? You can just use normal function syntax to
define them, and it works correctly. Do you need the ability to
declare that it's a generator even without any yields in it?


The advantage is that you cannot accidentally turn a function into a 
generator by adding "yield". If the result of the call is ignored (it is 
expected to be None), this bug can live a long time. It is a common 
issue: test containing yield always passes. Since 3.11 the unittest 
module emits a warning if a test method returns not None, but it will 
not solve all problems: the test can call helpers, and if they are 
generators, the call is virtually no-op. This error can also occur in 
non-test code.


Asynchronous functions are more reliable. "async" is mandatory, and if 
you do not await the result of an asynchronous function call you will 
get a loud warning. I think it is a time to apply the same approach to 
generator functions.


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

[Python-ideas] Re: Expand the try-expect syntax to support conditional expect block

[Serhiy Storchaka]

19.05.22 09:45, nadav.mis...@gmail.com пише:

Awesome! never seen this syntax used before and the above libraries are not 
using it.

Can you elaborate on the else part ? Why is it needed for the syntax to be 
correct and could you put any expression in the parenthesis ?


https://docs.python.org/3/reference/expressions.html#conditional-expressions

The tricky part is that isinstance(obj, ()) and issubclass(cls, ()), and 
corresponding internal check used in the `except ()` clause always 
return False. It is not explicitly stated (unlike to all() and any()), 
but it follows from the description if you read it carefully.


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

[Python-ideas] Re: Expand the try-expect syntax to support conditional expect block

[Serhiy Storchaka]

18.05.22 22:08, Nadav Misgav пише:
I was thinking of a way to expand the current try-expect block to 
support condinitial expect block. I was imagining the new syntax as


try:
     expression block
expect Exception if condition
     expression block

where the expect expression block would only run if the condition is met 
else it would raise the exception, for example the following code


You already can do this!

try:
expression block
expect Exception if condition else ():
expression block

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

[Python-ideas] Re: infile and outfile parameters for the input function

[Serhiy Storchaka]

02.05.22 22:55, sam.z.e...@gmail.com пише:

```
with open('/dev/tty', 'r+') as file:
 name = input('Name: ', infile=file, outfile=file)

print(name)
```


How does it differ from just:
```
file.write('Name: ')
name = file.readline()
```
?

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

[Python-ideas] Re: int.to_base, int.from_base

[Serhiy Storchaka]

02.05.22 08:03, Chris Angelico пише:

Let's not go as far as a PEP yet, and figure out a couple of things:


A PEP is necessary if we add Roman numerals and Cyrillic numerals, and 
Babylonian cuneiform numerals to the heap.


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

[Python-ideas] Re: Allow os.getenv to optionally convert result to boolean

[Serhiy Storchaka]

30.03.22 14:05, Adrian Torres Justo пише:
We've used a lot of boolean environment variables in a recent project 
I've been working on, this led us to create a wrapper to os.getenv that 
essentially converts the result to a boolean using 
distutils.util.strtobool if an optional kwarg to our wrapper is set to True.


Would it be far-fetched to have os.getenv incorporate this 
functionality? We already have the building blocks (strtobool and 
getenv), and the signature change would be minimal and backwards-compatible:


def getenv(key, default=None, to_bool=False):
     ...


Why not use just to_bool(getenv(key))?


The implementation would be trivial too.


No. There would be hundreds different trivial implementations.

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

[Python-ideas] Re: A string function idea

[Serhiy Storchaka]

28.03.22 15:13, StrikerOmega пише:

And I want to grab some kind of value from it.


There is a powerful tool designed for solving such problems. Is is 
called regular expressions.



sample.grab(start="fruit:", end="\n")
 >> 'apple'


re.search(r'fruit:(.*?)\n', sample)[1]


sample.grab(start="tree:[", end="]")
 >> 'Apple tree'


re.search(r'tree:\[(.*?)\]', sample)[1]



sample.grab(start="quantity:{", end="}", list_out=True)
 >> [5, 3]


list(re.findall(r'quantity:\{(.*?)\}', sample))

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

[Python-ideas] Re: An unambiguous way of initializing an empty set and dictionary

[Serhiy Storchaka]

14.03.22 15:07, Joao S. O. Bueno пише:

- but what about keeping what exists and adding {,}  for an empty set?
(it is not that unlike the one-element tuple, which already exists)


If you want to create an empty set without using any identifier, use 
{*()}. The advantage is that it works in old Python versions.


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

[Python-ideas] Re: Creating ranges with ellipsis

[Serhiy Storchaka]

16.02.22 14:44, Soni L. пише:
> This might be a silly idea but, would it be a good idea to have
> ...[a:b:c] return a range(a, b, c)?

See PEP 204.

https://www.python.org/dev/peps/pep-0204/

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

[Python-ideas] Re: Missing expandvars equivalent in pathlib

[Serhiy Storchaka]

10.02.22 12:59, anthony.flury via Python-ideas пише:
> I know that /os.path/ includes a function /expandvars(..)/ which expands
> any environment variables in a given path, but from looking at the
> /pathlib/ documentation It seems there is
> no equivalent to /os.path.expandvars(..) on any class/ in /pathlib/, and
> the recommendation seems to be to use /pathlib/ to do any and all path
> manipulations, with the exception of expanding environment variables.

expandvars() does not operate on paths, it operates on strings and
bytestrings. There is nothing path-specific here. Expanding environment
variables consists of three distinct steps:

1. Represent a path as a string.
2. Expand environment variables in the string.
3. Create a new path from a new string.

Note that there are two implementations of expandvars(): in posixpath
and ntpath. You may want to apply Posix substitution on Windows and
Windows substitution on Linux or macOS, so it cannot be tied to
PosixPath or WindowsPath.

Perhaps the shlex module would more appropriate place for expandvars()
than os.path, but what done is done.

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

[Python-ideas] Re: staticmethod vs classmethod [was: Add a decorators called @staticproperty]

[Serhiy Storchaka]

19.12.21 19:41, Ethan Furman пише:
> On 12/19/21 5:40 AM, Serhiy Storchaka wrote:
> 
>> classmethod supersedes staticmethod. It was not clearly known when they
>> were introduced, but now we see that there is very few use cases for
>> staticmethod which cannot be replaced by classmethod (actually only one
>> specific case).
> 
> What is the one case?

Setting a Python function as a class attribute without making it a method.

def func(*args, **kwargs): ...
class A:
f = staticmethod(func)
a = A()
a.f(1)  # calls func(1), not func(a, 1)

It is used in tests if there are C and Python implementations.
staticmethod(func) could be replaced with

lambda self, /, *args, **kwargs: func(*args, **kwargs)

or

property(lambda self: func)

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

[Python-ideas] Re: Add a decorators called @staticproperty

[Serhiy Storchaka]

18.12.21 13:18, m...@chenjt.com пише:
> It might be a good idea to use "@staticproperty" to solve this problem.
> "@staticproperty" is a decorators, it mix the @staticmethod and @property.
> Then the static property has getter and setter.

classmethod supersedes staticmethod. It was not clearly known when they
were introduced, but now we see that there is very few use cases for
staticmethod which cannot be replaced by classmethod (actually only one
specific case). If it would be known in advance staticmethod would be
not added.

So you can use a combination of @classmethod and @property.

class Data:
@classmethod
@property
def imagesTotal(cls):
return 10

There are some issues with help() and unittest.mock. They may not work
as you expected.

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

[Python-ideas] Re: Context managers in expressions

[Serhiy Storchaka]

25.10.21 21:26, jcg.stu...@gmail.com пише:
> I've been thinking for a while that it would be good to be able to use 
> context managers in an expression context, and I haven't been able to come up 
> with any arguments against it (although it may not be to everyone's taste) 
> and I can't see any sign that it's come up before (although the words of it 
> don't make very specific search terms).
> My suggestion is that a "with" clause could be written after an expression 
> (consistent with the conditional operator being written with "if" after the 
> first expression).
> 
> In general, this would be:
>   a(b) with c(d) as b
> or it could allow multiple context managers:
>   a(b, c) with d(e) as b, f(g) as c
> 
> My original motivating example was this:
> 
> if name.startswith("https://";):
> data = requests.get(name).json()
> else:
> with open(name) as stream:
> data = json.load(stream)
> 
> which I'd much rather be able to write with a single expression:
> 
> data = (requests.get(name).json()
> if name.startswith("https://";)
> else (json.load(stream)
>   with open(name) as stream))
> 
> It would behave just like a "with" statement, but pass a value / values back.

I was going to propose this idea for discussion but did not have enough
time to formulate it.

It is not just a "what if we combine two random features idea", it would
cover most cases of recurrent requests for adding functions which merge
open() and json.load(), etc or adding new very specialized methods to
the Path object. Currently you can write

with open(filename, 'rb') as f:
data = json.load(f)

The only minor drawback of this idiom is that it is not expression (but
you always can write a new function). If you could write

data = json.load(f) with open(filename, 'rb') as f

this counter-argument will disappear.

Now, Mark Gordon asked a good question -- what to do if the context
manager suppresses an exception. We do not have value and we do not have
exception. The only answer I have -- raise a RuntimeError (or other
specialized exception). It should be an error to use context managers
which suppress exceptions in the "with" expression. Maybe there are
better ideas.

Before adding the "with" expressions we should consider other feature:
the "with" clause in comprehensions.

Currently comprehensions can contain "for" and "if" clauses. There
should be at least one "for" clause and it should be the first clause. I
propose to add the with clause. It will be interpreted the same way as
"if" and nested "for" clauses. [expr for x in iterable if cond() with
cm() as y] should be equivalent to:

result = []
for x in iterable:
if cond():
with cm() as y:
result.append(expr)

It should be discussed because there is a conflict between its syntax
and the "with" expression. The "with" clause should have priority over
the "with" expression (as the "if" clause has priority over the "if"
expression), but it is a breaking change if the latter will be
implemented first.

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

[Python-ideas] Re: Return False from __contains__ method if object not hashable for set and dict.

[Serhiy Storchaka]

25.10.21 18:49, Kazantcev Andrey пише:
> Now if do something like `[] in set()` python raise an exception, but if an 
> object isn't hashable then we know for sure that it isn't in the set. Propose 
> return False for these cases. What do you think?

What was changed since this topic was discussed last time?

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

[Python-ideas] Re: def variable = value

[Serhiy Storchaka]

24.10.21 15:20, Stephen J. Turnbull пише:
> What do you mean by "constructor" here?  Normally that word refers to
> methods that populate the attributes of instances (in Python, __init__
> and__new__).  But functions and methods don't have such, so you must
> mean something else?

They have. Both function and type classes have constructors and they are
called when a function or class is created. Values of __name__,
__qualname__ and __module__ attributes are directly or indirectly passed
to constructors.

We do not have generalized way to call arbitrary constructor with
automatically passing __name__, __qualname__ and __module__. And it
would be convenient.

create namedtuple Point(x, y, z=0)
create enum Mode(read, write, append)
create NewType UserId(int)
create TypeVar T

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

[Python-ideas] Re: Syntax for late-bound arguments

[Serhiy Storchaka]

23.10.21 19:07, Chris Angelico пише:
> _missing = object()
> def spaminate(thing, count=_missing):
> if count is _missing: count = thing.getdefault()
> 
> Proposal: Proper syntax and support for late-bound argument defaults.
> 
> def spaminate(thing, count=:thing.getdefault()):
> ...

Few years ago I proposed a syntax for optional arguments without default
value:

def spaminate(thing, count=?):
try:
count
except UnboundLocalError:
count = thing.getdefault()
...

It would help in cases in which we now use None or special singleton
value. It is more general than late-bound arguments, because it can be
used in cases in which the default argument cannot be expressed, like in
getattr() and dict.pop().

The code for initialization of the default value is something
complicated, but we can introduce special syntax for it:

if unset count:
count = thing.getdefault()

or even

count ?= thing.getdefault()

> 1) Inspecting the function would reveal the source code for the late-bound 
> value
> 2) There is no value which can be passed as an argument to achieve the
> same effect

This is the largest problem of both ideas. The inspect module has no way
to represent optional arguments without default value, and any solution
will break user code which is not ready for this feature.

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

[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

[Serhiy Storchaka]

17.10.21 16:08, Eric V. Smith пише:
> Serhiy: could you explain the difference?


The difference between `for x in it: yield x` and `yield from it` is
than in the latter case any values passed in with send() and any
exceptions passed in with throw() are passed to the underlying iterator
if it has the appropriate methods. See
https://www.python.org/dev/peps/pep-0380/ .


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

[Python-ideas] Re: Accessing target name at runtime

[Serhiy Storchaka]

08.10.21 22:23, Jeremiah Paige пише:
 Point = namedtuple(<<<, 'x, y, z')
 Point
> 
> 
> 
 UUIDType = NewType(<<<, str)
 UUIDType
> __main__.UUIDType

In many cases similar to namedtuple and NewType this is not enough. You
need to pass to the constructor not only name, but module name and full
qualified name. The full qualified name is needed to make nested
declarations working. And to getting the module name we currently need
to use _getframe() which is ugly and non-portable.

It may be useful to provide access also to globals and locals of the
outer scope.

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

[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

[Serhiy Storchaka]

16.10.21 17:07, Erik Demaine пише:
> (*it for it in its)  # tuple with the concatenation of iterables in 'its'

As others already have said, it should evaluate to a generator, not to a
tuple.

But other question is occurred now. Should it be equivalent to

def gen(its):
for it in its:
for x in it:
yield x

or to

def gen(its):
for it in its:
yield from it

? There is a subtle difference between these codes.

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

[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

[Serhiy Storchaka]

16.10.21 17:07, Erik Demaine пише:
> Extended unpacking notation (* and **) from PEP 448 gives us great ways
> to concatenate a few iterables or dicts:
> 
> ```
> (*it1, *it2, *it3)  # tuple with the concatenation of three iterables
> [*it1, *it2, *it3]  # list with the concatenation of three iterables
> {*it1, *it2, *it3}  # set with the union of three iterables
> {**dict1, **dict2, **dict3}  # dict with the combination of three dicts
> # roughly equivalent to dict1 | dict2 | dict3 thanks to PEP 584
> ```
> 
> I propose (not for the first time) that similarly concatenating an
> unknown number of iterables or dicts should be possible via comprehensions:
> 
> ```
> (*it for it in its)  # tuple with the concatenation of iterables in 'its'
> [*it for it in its]  # list with the concatenation of iterables in 'its'
> {*it for it in its}  # set with the union of iterables in 'its'
> {**d for d in dicts} # dict with the combination of dicts in 'dicts'
> ```

It was considered and rejected in PEP 448. What was changed since? What
new facts or arguments have emerged?

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

[Python-ideas] Re: Implementing additional string operators

[Serhiy Storchaka]

13.10.21 22:03, Marc-Andre Lemburg пише:
> Some examples:
> - removal of file extensions
> - removal of end tags
> - removal of units
> - removal of currencies
> - removal of standard suffixes
> - removal of wildcard patterns
> etc.
> 
> I find lots of such uses in the code bases I work with.

I did not have opportunity to use removesuffix yet. The problem is that
almost always when I need to remove a suffix or prefix, I need to know
whether it was removed or no. removesuffix does not help, it does not
even make the code shorter. And I need to support versions older than 3.9.


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

[Python-ideas] Re: Implementing additional string operators

[Serhiy Storchaka]

13.10.21 22:53, Peter Ludemann пише:
> [*] Floating point x+y isn't always y+x, but floating point is its own 
> problematic world.

AFAIK floating point x+y is always y+x, but (x+y)+z is not always x+(y+z).

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

[Python-ideas] Re: Implementing string unary operators

[Serhiy Storchaka]

13.10.21 03:10, Jelle Zijlstra пише:
> To get a new operator on a builtin type, you'll have to show that:
> - It's a common operation;
> - There's no convenient way to do it already; and
> - The meaning of the operator is reasonably clear to a reader of the code.
> 
> Recent examples of new features that met that bar are dict |
> in https://www.python.org/dev/peps/pep-0584
>  and matrix multiply
> in https://www.python.org/dev/peps/pep-0465/
> .

I think it fails two first criteria. It is not enough common operation
and we already did have convenient ways to do it.

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

[Python-ideas] Re: Implementing string unary operators

[Serhiy Storchaka]

13.10.21 03:05, MarylandBall Productions пише:
> I would think `~string` could be good for a shorthand way to convert a string 
> to an integer, considering you’re “inverting” the string to another type, 
> though a downside to this would be that explicit is always better than 
> implicit and ~string will be a confusing operation to many users.

Then it should be a shorthand for json.loads().

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

[Python-ideas] Re: Invalidate list iterators after size changes?

[Serhiy Storchaka]

09.10.21 01:24, Tyler Hou via Python-ideas пише:
> Concretely, I'm proposing the following set of changes to Python:
> 
> 1. If the size of a list, set, or dict changes, invalidate all existing 
> iterators to that containers. Document this behavior as part of the public 
> API.
> 2. Attempting to call next() on an invalidated iterator raises a RuntimeError.
> 3. Add a key_iter function to itertools (name up for debate), which 
> replicates the existing functionality for lists. It could also make a copy of 
> the keys of a set/dict, so you could use it to mutate those as well during 
> iteration (to allow users to write functions that mutate an arbitrary 
> duck-typed collection)
> 4. Gate (1, 2) for lists behind a __future__ flag with a long migration 
> window (e.g. ~3.16).

I see two drawbacks:

1. It is a breaking change. I do not think there is much code which
modify a list during iteration, but still.
2. It adds an overhead to iteration and mutating operations. And this is
more severe drawback, because it affects a much of code.

And the only argument for this change is consistency with set and dict.
It is very weak argument, because list differs from set and dict in so
many ways.

Iteration of lists after mutating is deterministic and well predictable.
This is why it can be used in code and no RuntimeError is raised. In
contrary, iteration of sets and dicts after mutating is unpredicable.
You can miss some items, get some items multiple times, and it depends
on the history of set and dict, types and values of keys, and just be
random. We try to detect this and raise RuntimeError because there is no
way to use it correctly.

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

[Python-ideas] Re: Reusing more builtins for type-hinting

[Serhiy Storchaka]

02.10.21 17:10, Todd пише:
> Is there a reason we can't use "Object" and make "Any" just an alias for
> "Object"?

If you mean "object", then the reason is that "object" has no methods
and attributes (besides few dunder methods like __repr__ and
__reduce__), while "Any" has all methods and attributes.

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

[Python-ideas] Re: pathlib update idea: iterable Path that returns subpaths

[Serhiy Storchaka]

02.10.21 15:44, Paul Moore пише:
> The counter-argument is "there should be one obvious way" - we
> definitely don't only have *one* way, at the moment, but none of them
> are "obvious". My big problem is that I don't think that making Path
> instances iterable is "obvious", either. What if the path is a file,
> not a directory? Why are we doing a recursive traversal, not just
> doing iterdir?

Ideas of making Path iterable are proposed every several months. The
problem is that they are different ideas. One want to iterate path
components. Other want to iterate a directory specified by the path
(recursively or not). Originally it was rejected because some
third-party Path-like implementations can subclass str, and therefore
inherit yet different iteration behavior from strings. It is safer to
not make Path iterable and provide different methods for iterating
different things in different way.

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

[Python-ideas] Re: Reusing more builtins for type-hinting

[Serhiy Storchaka]

01.10.21 15:01, Matt del Valle пише:
> `any` (for use  instead of `typing.Any`)
> `callable` (for use instead of `typing.Callable`)

The problem is than any() and callable() are not types, but functions,
whose names are accidentally similar to names of some typing types.
If the name of callable() would be iscallable(), you would not even came
with this idea.

Now, if merge any() and typing.Any, callable() and typing.Callable, what
should help() show for any and callable? What are they signatures? How
do you explain that the same object is used for two different,
completely unrelated things?

> Having to explicitly import objects from `typing` for basic type-hinting
> use-cases is a not-inconsiderable source of frustration preventing their
> uptake, especially by beginners. 3.9 made a valuable step forward in
> reducing this friction, but I think we can go further.

In any case you need to import for Mapping, Sequence, Final, NoReturn,
TypeVar, etc. list[int] is not the same as Iterable[int], and using
interfaces and protocols in annotations is more preferable than using
concrete classes.

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

[Python-ideas] Re: Syntax Sugar for __name__ == "__main__" boilerplate?

[Serhiy Storchaka]

01.10.21 22:35, Jonathan Crall пише:
> My motivation for writing this suggestion is in an attempt to stop a
> common anti-pattern, where instead of defining a `main` function (or a
> function by any other name) an simply calling that by adding the above
> two lines, a lot of Python users I work with will just start dumping
> their logic into the global scope of the module.

It is not an attipattern. It is how Python works (note that import, def
and class are statements executable at runtime), and it is what you
normally expect from a scripting language.

Now, sometimes you want to use the same file for two purposes: as a
module and as an executable script. You need a way to distinguish these
cases. And __name__ == "__main__" is an idiomatic way to do it in
Python. But if you do not need to mix executable and module in one file
you do not need to use it.

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

[Python-ideas] Re: PEP Draft: Power Assertion

[Serhiy Storchaka]

25.09.21 17:46, Guido van Rossum пише:
> - I was envisioning something that provides an API that would allow a
> test framework to do what pytest does; not a behavior chance to the
> assert statement by default.
> 
> - Please, please collaborate with the pytest developers on the design.

+++

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

[Python-ideas] Re: A better math.factorial

[Serhiy Storchaka]

17.09.21 05:23, Steven D'Aprano пише:
 factorial(23) == better_factorial(23)
> False
> 
> The problem is that since floats only have about 17 significant figures 
> or so, once you get to 23! the gamma function doesn't have enough 
> precision to give an exact answer. Of course that's easily fixable. 
> (Only call gamma if the input argument is a float.)

It is not even easily fixable.

First, the resulting function which uses different algorithms for
integers and non-integers can be non-monotonic.

Second, factorial() supports large arguments for which gamma() raises an
overflow error.

Third, it will have non-uniform computational complexity. The time of
calculating gamma() is virtually constant, but the time of calculating
factorial() grows with increasing argument.

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

[Python-ideas] Re: os.workdir() context manager

[Serhiy Storchaka]

14.09.21 22:43, Marc-Andre Lemburg пише:
> Would there be interest in adding something like this to the os module
> as os.workdir() ?

There is already an open issue and PR for this:

https://bugs.python.org/issue25625
https://github.com/python/cpython/pull/28271

My main concern is that it is not thread-safe (nor generator-safe, nor
coroutine-safe), but on other hand, redirect_stdout() and
redirect_stderr() have same limitations.

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

[Python-ideas] Re: Power Assertions: Is it PEP-able?

[Serhiy Storchaka]

12.09.21 21:36, Chris Angelico пише:
> I wonder, could this be simplified a bit, on the assumption that a
> well-written assertion shouldn't have a problem with being executed
> twice? Instead of keeping all the subexpressions around (a run-time
> cost), keep the AST of the expression itself (a compile-time cost).
> Then, when the exception is about to be printed to the console,
> re-evaluate it and do the display.

Yes, it would simplify, but we cannot guarantee this (especially in
tests). If we could, we would not need an assert.

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

[Python-ideas] Re: Power Assertions: Is it PEP-able?

[Serhiy Storchaka]

12.09.21 21:20, Guido van Rossum пише:
> Maybe you all could collaborate on a PEP? This sounds a worthy topic.

I can write an implementation if we decide on the interface. I am
currently have higher priorities of other tasks than to make a research
on this feature.

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

[Python-ideas] Re: Power Assertions: Is it PEP-able?

[Serhiy Storchaka]

12.09.21 17:28, Guido van Rossum пише:
> This is cool.
> 
> AFAIK pytest does something like this. How does your implementation differ?

What pytest does is awesome. I though about implementing it in the
standard compiler since seen it the first time.

> What is your argument for making this part of the language? Why not a
> 3rd party library?

It needs a support in the compiler. The condition expression should be
compiled to keep all immediate results of subexpressions on the stack.
If the final result is true, immediate results are dropped. If it is
false, the second argument of assert is evaluated and its value together
with all immediate results of the first expression, together with
references to corresponding subexpressions (as strings, ranges or AST
nodes) are passed to the special handler. That handler can be
implemented in a third-party library, because formatting and outputting
a report is a complex task. The default handler can just raise an
AttributeError.

> What about asserts that are not used for testing, but as classic “unless
> there’s a bug, this should hold”? Those may not want to incur the extra
> cost. 

The only extra cost is that immediate results are temporary save on
stack instead of just be dropped. It increases the size of bytecode and
stack, but I don't think it will be significant.

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

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Serhiy Storchaka]

03.09.21 10:34, Thomas Grainger пише:
> I think that it would be good to make TypeError more fine-grained.
> Another example is:
> 
 sum(1, 2, 3)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: sum() takes at most 2 arguments (3 given)

I agree that TypeErrors raised for incorrect number or names of
arguments is a separate class of TypeErrors. But it is not related to my
proposition.

It includes also two kinds of errors:

1. Programming error. The author of the calling code uses a known
function improperly or the author of the function break compatibility.
2. User input error. If a user provides an incompatible callable.

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

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Serhiy Storchaka]

03.09.21 10:34, Thomas Grainger пише:
> what's the reason for this not to raise AttributeError?

At least backward compatibility. Currently a TypeError is raised in such
cases, and AttributeError is not a subtype of TypeError.

Also, not always any attribute is involved. For example, float() raises
a TypeError if __float__() returns not float. And even if some dunder
name is involved, rules for resolving special methods and common
attributes are different.

> I assume you asked this question in relation to the 3.11 changes to `with x:` 
> raising TypeError vs AttributeError ?

No, it is not related. It was a bug to raise AttributeError, now it is
fixed, but the fix is not backported for compatibility reasons.

> How about `AttributeNotFoundError` or `AttributeRequiredError` ?

It would be confused with completely unrelated AttributeError.

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

[Python-ideas] Re: Add a special TypeError subclass for implementation errors

[Serhiy Storchaka]

12.09.21 07:48, Ram Krishna пише:
> I guess having subclass for implementation errors to distinguish will be very 
> helpful, Typeerror has become very generic and finding solution is like 
> searching a needle in haystack for the new developers.
> 
> Eg- TypeError: ‘int’ object is not iterable
> 
> students=int(input('Please enter the number of students in the class: '))
> 
> for number in students:
> math_grade=(input("Enter student's Maths grade: "))
> science_grade=(input("Enter student's Science grade: "))
> social_grade=(input("Enter student's Scoial grade: "))
> 
> Common homeworks/tutorial for beginners who find difficult to understand why 
> this error occurred. So a fine grained exception would be lot easier to 
> understand and resolve quickly.

My proposition does not change the type of exception here. It is a
vanilla TypeError: you use a value of improper type in operation.

A new implementation error would be raised if you implement your own
iterable class and return int in __iter__(). Most beginners will never
see such errors because it is an advanced topic.

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

[Python-ideas] Re: classmethod __eq__ comparisons and Any wildcards

[Serhiy Storchaka]

09.09.21 17:19, Randolf Scholz пише:
> As a sidenote, I think it would actually be kinda cool to have the 
> `typing.Any` behave this way, i.e. always comparing to True.
> One example where this would be useful is that it would allow comparisons like
> 
> ```python
> assert mytuple == (Any, "abc")
> ```
> 
> which would then be equivalent, but imo a lot more elegant than
> 
> ```python
> assert len(mytuple) == 2 and mytuple[-1] == "abc"
> ```

Did you try to use unittest.mock.ANY?

typing.Any cannot behave this way. First, list[Any] and list[int] are
different types. Second, an object which is equal to everything cannot
be hashable, but typing.Any is hashable, and should be hashable for
using in caching.

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

[Python-ideas] Re: Add @parametrize decorator to unittest library

[Serhiy Storchaka]

07.09.21 05:31, Leonardo Freua пише:
> When writing some unit tests with the standard Unittest library, I missed 
> being able to create parameterized tests. This functionality exists in PyTest 
> (https://docs.pytest.org/en/6.2.x/parametrize.html) and there is also a 
> library called *parameterized*(https://github.com/wolever/parameterized) 
> which aims to add this functionality.
> 
> However, I think it would be beneficial to have a decorator in Python's 
> standard Unittest library.
> 
> Note: If this functionality exists natively in Python, please put some 
> example or documentation link below.

It was discussed before and subTest() was added as more general alternative.

Instead of

@parametrize("a", [1, 2, 10])
def test(self, a):
...

you should write

def test(self):
for a in [1, 2, 10]:
with self.subTest(a=a):
...

The advantage is that you can generate parameters at run time. You can
add a code before and after the loop. Use several sequential loops.
There are also other use cases for subTest().

The disadvantage is that it adds at least two indentation levels (more
if you use nested loops) to the test code. A simple decorator would be
more convenient in simple cases.

It is easy to implement the decorator in terms of subtests, but
currently there are some issues with outputting results of subtests:
https://bugs.python.org/issue25894
https://bugs.python.org/issue30856

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

[Python-ideas] Re: Improve traceback for common `with` statement mistake

[Serhiy Storchaka]

06.09.21 18:42, Chris Angelico пише:
> On Tue, Sep 7, 2021 at 1:36 AM Finn Mason  wrote:
>> Thank you for testing that. I dug through the change log, and found 
>> bpo-12022:
>> https://bugs.python.org/issue12022
>> It has been fixed in 3.11, but not mentioned in the What's New document. 
>> Should it be?
> 
> If it was indeed a side effect of that change, then there *is* a
> What's New entry about it, but it's focusing on other changes:

"TypeError: __enter__" would look silly.

Minor changes in error messages and docstrings are not worth mentioning
in What's New. And changing the type of exception outweigh a change in
error message.

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

[Python-ideas] Re: define an idiomatic way to make a generator that throws StopIteration immediately and add it to PEP8

[Serhiy Storchaka]

03.09.21 10:28, Thomas Grainger пише:
> the way to make an (aysnc)generator that immediately raises 
> Stop(Async)Iteration immediately is to insert an unreachable `yield` 
> statement, however there's two ways to do it:

I think it is too uncommon case to specify it in PEP 8.

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

[Python-ideas] Add a special TypeError subclass for implementation errors

[Serhiy Storchaka]

There are two different kinds of TypeError: if the end user passes an
instance of wrong type and if the author of the library makes an error
in implementation of some protocols.

For example, len(obj) raises TypeError in two cases: if obj does not
have __len__ (user error) and if obj.returns non-integer (implementation
error). for x in obj raises TypeError if obj does not have __iter__
(user error) and if iter(obj) does not have __next__ (implementation error).

User errors can be fixed on user side, implementation errors can only be
fixed by the author of the class. Even if the user and the author is the
same person, these errors point to different places of code.

Would it be worth to add a special TypeError subclass for implementation
errors to distinguish them from user errors? How to name it
(ImplementationError, ProtocolError, etc)?

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

[Python-ideas] Re: NAN handling in statistics functions

[Serhiy Storchaka]

26.08.21 12:05, Marc-Andre Lemburg пише:
> Oh, good point. I was under the impression that NAN is handled
> as a singleton.
> 
> Perhaps this should be changed to make to make it easier to
> detect NANs ?!

Even ignoring a NaN payload, there are many different NaNs of different
types. For example, Decimal('nan') cannot be the same as float('nan').

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

[Python-ideas] Re: Add explicit method overloading to STL

[Serhiy Storchaka]

24.08.21 05:10, Will Bradley пише:
> Don't know if this is already a PEP, but I'd love to see something
> like this
> 
>  in
> Python— a decorator @overload that creates multiple copies of
> functions/methods based on their arguments' types. (This is much
> narrower in scope than PEP 3124, before anyone asks.)

What is STL 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/5AEDREQFP2BSRRTNTYST5NFLNHKDXQXD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: We should have an explicit concept of emptiness for collections

[Serhiy Storchaka]

22.08.21 16:27, Steven D'Aprano пише:
> Quoting the subject line:
> 
> "We should have an explicit concept of emptiness for collections"
> 
> We do. It's spelled:
> 
> len(collection) == 0
> 
> You can't get more explicit than that.

(len(collection) == 0) is True

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

[Python-ideas] Re: startswith() and endswith() methods returning the matched value

[Serhiy Storchaka]

09.08.21 17:05, fgalla...@gmail.com пише:
> Two possibilities:
> 
> 1) the perfectly backward compatible, retrun False
> 2) the more pythonic, return the empty value of the object (i.e. "" for str)

The problem is that for backward compatibility it should return True.
And empty string's boolean value is false.

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

[Python-ideas] Re: startswith() and endswith() methods returning the matched value

[Serhiy Storchaka]

09.08.21 05:05, fgalla...@gmail.com пише:
> This is a proposal to change the behaviour of the startswith() and
> endswith() methods for str, bytes and bytearray objects, making them
> return the matched value instead of the True boolean.

And what should it return for empty matched value?

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

[Python-ideas] Re: C API for converting Python integers to/from bytes sequences

[Serhiy Storchaka]

08.08.21 11:41, Barry Scott пише:
>> On 7 Aug 2021, at 19:22, Serhiy Storchaka  wrote:
>> 1. How to encode the byte order?
>>
>> a) 1 -- little endian, 0 -- big endian
>> b) 0 -- little endian, 1 -- big endian
>> c) -1 -- little endian, +1 -- big endian, 0 -- native endian.
> 
> Use an enum and do not use 0 as a valid value to make mistakes easier to 
> detect.
> I think you are right to have big endian, little endian and native endian.
> I do not think the numeric values of the enum matter (apart from avoiding 0).

There is a precedence of using +1/-1/0 for big/little/native in the
UTF16 and UTF32 codecs. I think that using the same convention will be
more error-proof.

> Maybe a single enum that has:
> signed (modulo)
> signed saturate
> unsigned (modulo)
> unsigned saturate

There is a problem with enum -- the size of the type is not specified.
It can be int, it can be 8 bits, it can be less than 8 bits in
structure. Adding new members can change the size of the type. Therefore
it is not stable for ABI.

But combining options for signessness and overflow handling (or
providing a set of functions for different overflow handling, because
the output overflow parameters is not in all cases) may be the best option.

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

[Python-ideas] Re: C API for converting Python integers to/from bytes sequences

[Serhiy Storchaka]

08.08.21 07:08, Stephen J. Turnbull пише:
> Serhiy Storchaka writes:
> 
>  > Python integers have arbitrary precision. For serialization and
>  > interpolation with other programs and libraries we need to
>  > represent them [...].  [In the case of non-standard precisions,]
>  > [t]here are private C API functions _PyLong_AsByteArray and
>  > _PyLong_FromByteArray, but they are for internal use only.
>  > 
>  > I am planning to add public analogs of these private functions, but more
>  > powerful and convenient.
>  > 
>  > PyObject *PyLong_FromBytes(const void *buf, Py_ssize_t size,
>  >int byteorder, int signed)
>  > 
>  > Py_ssize_t PyLong_AsBytes(PyObject *o, void *buf, Py_ssize_t n,
>  >   int byteorder, int signed, int *overflow)
> 
> I don't understand why such a complex API is useful as a public facility.

There are several goals:

1. Support conversion to/from all C integer types (char, short, int,
long, long long, intN_t, intptr_t, intmax_t, wchar_t, wint_t and
corresponding unsigned types), POSIX integer types (pid_t, uid_t, off_t,
etc) and other platfrom or library specific integer types (like
Tcl_WideInt in libtcl). Currently only supported types are long,
unsigned long, long long, unsigned long, ssize_t and size_t. For other
types you should choose the most appropriate supertype (long or long
long, sometimes providing several varians) and manually handle overflow.

There are requests for PyLong_AsShort(), PyLong_AsInt32(),
PyLong_AsMaxInt(), etc. It is better to provide a single universal
function than extend API by several dozens functions.

2. Support different options for overflow handling. Different options
are present in PyLong_AsLong(), PyLong_AsLongAndOverflow(),
PyLong_AsUnsignedLongMask() and PyNumber_AsSsize_t(). But not all
options are available for all types. There is no *AndOverflow() variant
for unsigned types, size_t, ssize_t, and saturation is only available
for ssize_t.

3. Support serialization of arbitrary precision integers. It is used in
pickle and random, and can be used to support other binary data formats.

All these goals can be achieved by few universal functions.

> So I might want
> PyLong_AsGMPInt and PyLong_AsGMPRatio as well as the corresponding
> functions for MP, and maybe even PyLong_AsGMPFloat.  The obvious way
> to write those is (str(python_integer)), I think.

PyLong_AsGMPInt() cannot be added until GMP be included in Python
interpreter, and it is very unlikely. Converting via decimal
representation is very inefficient way, especially for very long
integers (it has cubic complexity from the size of the integer). I think
GMP support more efficient conversions.

> In the unlikely event that an
> application needs to squeeze out that tiny bit of performance, I guess
> the library constructors all accept buffers of bytes, too, probably
> with a similarly complex API that can handle whatever the Python ABI
> throws at them.

For using the library constructors accepting buffers of bytes we need
buffers of bytes. And the proposed functions provide the only interface
for conversion Python integers to/from buffer of bytes.

> In which case why not just expose the internal
> functions?

If you mean _PyLong_FromByteArray/_PyLong_AsByteArray, it is because we
should polish them before exposing them. They currently do not provide
different options for overflow, and I think that it may be more
convenient way for common case of native bytes order. The names of
functions, the number and order of parameters can be discussed. For such
discussion I opened this thread. If you have alternative propositions,
please show them.

> Is it at all likely that that representation would ever
> change?

They do not rely on internal representation. They are for
implementation-indepent representation.

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

[Python-ideas] C API for converting Python integers to/from bytes sequences

[Serhiy Storchaka]

Python integers have arbitrary precision. For serialization and
interpolation with other programs and libraries we need to represent
them as fixed-width integers (little- and big-endian, signed and
unsigned). In Python, we can use struct, array, memoryview and ctypes
use for some standard sizes and int methods int.to_bytes and
int.from_bytes for non-standard sizes. In C, there is the C API for
converting to/from C types long, unsigned long, long long and unsigned
long long. For other C types (signed and unsigned char, short, int) we
need to use the C API for converting to long, and then truncate to the
destination type with checking for overflow. For integers type aliases
like pid_t we need to determine their size and signess and use
corresponding C API or wrapper. For non-standard integers (e.g. 24-bit),
integers wider than long long, and arbitrary precision integers all is
much more complicated. There are private C API functions
_PyLong_AsByteArray and _PyLong_FromByteArray, but they are for internal
use only.

I am planning to add public analogs of these private functions, but more
powerful and convenient.

PyObject *PyLong_FromBytes(const void *buf, Py_ssize_t size,
   int byteorder, int signed)

Py_ssize_t PyLong_AsBytes(PyObject *o, void *buf, Py_ssize_t n,
  int byteorder, int signed, int *overflow)

PyLong_FromBytes() returns the int object. It only fails in case of
memory error or incorrect arguments (e.g. buf is NULL).

PyLong_AsBytes() writes bytes to the specified buffer, it does not
allocate memory. If buf is NULL it returns the minimum size of the
buffer for representing the integer. -1 is returned on error. if
overflow is NULL, then OverfowError is raised, otherwise *overflow is
set to +1 for overflowing the upper limit, -1 for overflowing the lower
limit, and 0 for no overflow.

Now I have some design questions.

1. How to encode the byte order?

a) 1 -- little endian, 0 -- big endian
b) 0 -- little endian, 1 -- big endian
c) -1 -- little endian, +1 -- big endian, 0 -- native endian.

Do we need to reserve some values for mixed endians?

2. How to specify the reduction modulo 2**(8*size) (like in
PyLong_AsUnsignedLongMask)?

Add yet one flag in PyLong_AsBytes()? Use special value for the signed
argument? 0 -- unsigned, 1 -- signed, 2 (or -1) -- modulo. Or use some
combination of signed and overflow?

3. How to specify saturation (like in PyNumber_AsSsize_t())? I.e. values
less than the lower limit are replaced with the lower limit, values
greater than the upper limit are replaced with the upper limit.

Same options as for (2): separate flag, encode in signed (but we need
two values here) or combination of other parameters.

4. What exact names to use?

PyLong_FromByteArray/PyLong_AsByteArray,
PyLong_FromBytes/PyLong_AsBytes, PyLong_FromBytes/PyLong_ToBytes?


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

[Python-ideas] Re: `not not x` much faster than `bool(x)`

[Serhiy Storchaka]

06.08.21 10:29, wyz2...@163.com пише:
> Before the introduction of bool and also in other languages, `not not x` 
> was/is used to convert to True (1) and False (0). However, the old way is 
> still much faster than bool(x) or even operator.truth(x).
> Test:
>> py -3.10 -m timeit -s "objects = 1, 0, -0.0, "20", "False", 93, 28.569, [], 
>> set(), {1: 5}" "[(not not x) for x in objects]"
> 20 loops, best of 5: 1.12 usec per loop
>> py -3.10 -m timeit -s "objects = 1, 0, -0.0, "20", "False", 93, 28.569, [], 
>> set(), {1: 5}" "[(bool(x)) for x in objects]"
> 20 loops, best of 5: 2.32 usec per loop
>> py -3.10 -m timeit -s "from operator import truth; objects = 1, 0, -0.0, 
>> "20", "False", 93, 28.569, [], set(), {1: 5}" "[(truth(x)) for x in objects]"
> 20 loops, best of 5: 2.04 usec per loop
>> py -3.10 -V
> Python 3.10.0rc1
> 
> That's nearly 52%/46% faster! I guess the name lookup and the FUNCTION_CALL 
> is slower than UNARY_NOT. So actually, using `not not` is an optimize, 
> although it isn't clear. This is interesting.

I got very different results on Linux (optimized build). bool() and
truth() are only 18%/32% slower in 3.10. In 3.9 it is 88%/28% slower.
Calling a constructor in general is slower that calling a simple builtin
function, but some constructors, including the bool constructor, were
optimized in 3.10.

What surprised me is that bool() is faster than truth(). I have no other
explanation of this except that it may be a compiler glitch. The
compiler can randomly optimize some parts of code at the expense of
others. Microbenchmarking results are unreliable in these 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/UWVNOSSCXPN75IMSNTUCZTA365ZEVWUR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Serhiy Storchaka]

13.07.21 14:15, sandhoners...@gmail.com пише:
> My suggestion is to have either a writelines2 or a newline kwarg which does 
> put new lines automatically at the end of every line written

The writelines method is the part of interface. Adding new parameter or
new method to interface is a major breaking change. It will make invalid
all existing user code which implements this interface.

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

[Python-ideas] Re: builtins for running context managers

[Serhiy Storchaka]

13.07.21 18:59, Thomas Grainger пише:
> given that it's hard to implement this correctly I think there should be a 
> builtins.enter and builtins.aenter for use like this:
> 
> 
> ```
> @dataclasses.dataclass
> class WrapCmgr:
> _cmgr: ContextManager[T]
> 
> def __enter__(self) -> Wrapped[T]:
> exit, value = enter(self._cmgr)
> self.__exit = exit
> return wrap(value)
> 
> def __exit__(self, \, t: Type[BaseException] | None, v: BaseException, 
> tb: types.TracebackType) -> bool:
> return self.__exit(t, v, tb)
> ```

I considered similar idea when worked on issue12022 and issue44471. The
only difference is that I added the helper in the operator module, and
my operator.enter() returned the value and the callback in the different
order.

def enter(cm):
# We look up the special methods on the type to match the with
# statement.
cls = type(cm)
try:
enter = cls.__enter__
exit = cls.__exit__
except AttributeError:
raise TypeError(f"'{cls.__module__}.{cls.__qualname__}' object
does "
f"not support the context manager protocol")
from None
callback = _MethodType(exit, cm)
return enter(cm), callback

I still investigate possible consequences and alternatives.

Since we need to save the callback as an object attribute in any case,
one of alternatives is using ExitStack instead of introducing new API.
It is more heavyweight, but if implemented in C the difference can be
reduced.

Other alternative is to expose _PyObject_LookupSpecial() at Python
level. It would be useful not only for __enter__ and __exit__, but for
other special methods.

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

[Python-ideas] Re: Allow modifying message of TypeError from NotImplemented

[Serhiy Storchaka]

19.06.21 06:30, wyz2...@163.com пише:
> Python raises TypeError when NotImplemented is returned from __add__, 
> __invert__ etc. and __radd__ etc. aren't available.
> However, this disallows the customization of error messages. For example, in 
> Python 3.8, __float__ etc. were removed from complex to allow methods like 
> __rfloat__. But this makes abs(z) undiscoverable for many users. The original 
> error message is very helpful.
> I suggest to make a way for this usage. Maybe NotImplementedType can accept 
> *args, and NotImplemented can be callable, equal to __init__:
> 
 class A:
> def __add__(self, other):
> return NotImplemented  # Just like before
> def __neg__(self, other):
> return NotImplemented(f'bad operand type for unary -: 
> {type(self).__name__!r}; use ~ to invert')  # <--
> def __invert__(self):
> return ~5
 a = A()
 a + 2
> TypeError: unsupported operand type(s) for +: 'A' and 'int'
 -a
> TypeError: bad operand type for unary -: 'A'; use ~ to invert
 ~a
> -6

NotImplemented is a singleton. And all code which tests for
NotImplemented does it by checking identity. Returning any other object
instead of the NotImplemented would not work.

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

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

19.06.21 18:12, Marc-Andre Lemburg пише:
>> But there could be endless debate about whether flatten( ("x", "y") ) should
>> return a list or a tuple...
> 
> Have it return an iterator :-)

flatten = itertools.chain.from_iterable

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

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

19.06.21 07:33, Guido van Rossum пише:
> [1] Does the unary star operator have a name when used like this in
> Python? In JavaScript the equivalent syntax ("...chunk", where the "..."
> are a literal ellipsis) is called "spread". We could borrow this term.

I would not call is an operator. Operator forms an expression, but *x is
not an expression. It is not more operator than colon.

Is there such term as "syntax form" in English? I would call *x, x for x
in a, x:y syntax forms. They are not expressions, but can be part of
expression. They can only be used in some context, and the meaning
depends on the context (x:y are two different things in {x:y} and in
a[x:y]).

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

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

18.06.21 18:42, Mathew Elman пише:
> I don't see how allowing 
> 
> [x, y for x in a] 
> 
> follows from allowing 
> 
> [*chunk for chunk in list_of_lists].

Because in all other contexts you can replace `*(x, y)` with `x, y`.

f(*(x, y)) => f(x, y)
[*(x, y)] => [x, y]
{*(x, y)} => {x, y}
*(x, y), => x, y, => (x, y)

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

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

18.06.21 17:38, Guido van Rossum пише:
> Note the ambiguity around whether the user might have meant
> 
>     [x,(y for y in a)]
> 
> or
> 
>     [(x, y) for y in a]

Yes, I think that it could be interpreted in one of the following ways:

 [x, (y for y in a)]
 [x, *(y for y in a)]
 [(x, y) for y in a]
 [*(x, y) for y in a]  # if allow [*chunk for ...]

Any interpretation can be well-justified and formally non-ambiguous once
we choose the one to be allowed. But it will still *look* ambiguous, so
it is better to avoid such syntax in Python which is famous for its
clear syntax.

I withed that I could write just [*chunk for ...] several times per
year, but I understand that there were reasons to not allow it.

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

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

18.06.21 00:22, Ben Rudiak-Gould пише:
> Okay, slightly off-topic, but can we *please* allow
> 
>     [*chunk for chunk in list_of_lists]
> 
> some day. I think it was left out because some discussion concluded it
> would be too confusing, which is ridiculous. I assumed it would work and
> was confused to find that it didn't. It's blatantly inconsistent.

It was originally proposed in PEP 448 (Additional Unpacking
Generalizations) but was excluded after discussing.

If we allow

[*chunk for chunk in list_of_lists]

we should allow also

[x, y for x in a]

which would be equivalent to

[a[0], y, a[1], y, a[2], y, ...]

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

[Python-ideas] Re: Deprecate sum of lists

[Serhiy Storchaka]

17.06.21 06:03, David Mertz пише:
> I'm sympathetic to raising an exception on `sum(list_of_lists)` similar
> to `sum(list_of_strings)`.  But what exactly is the recommended
> substitute?  We have this:
> 
> list(chain.from_iterable(list_of_lists))
> 
> Which is pretty nice, and what I'd probably do, but it DOES require
> importing from itertools to use it.  That feels like a drawback, at
> least a minor one.

And it is equivalent to pure Python code

[x for chunk in list_of_lists for x in chunk]

It has linear complexity and is only by a constant factor slower because
it iterates loops in bytecode instead of the C code. It would be
possible to make the compiler recognizing such pattern and generating
more efficient bytecode (LIST_EXTEND instead of an internal loop with
LIST_APPEND), but I am not sure that this case is common enough to
complicate the compiler.

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

[Python-ideas] Re: The name Ellipsis should be a constant

[Serhiy Storchaka]

31.05.21 22:24, André Roberge пише:
> 
> 
> On Mon, May 31, 2021 at 4:17 PM Serhiy Storchaka
>  <mailto:storch...@gmail.com>> wrote:
> 31.05.21 17:37, André Roberge пише:
> > For consistency, `Ellipsis` (the name) should **always** refer to the
> > same object that `...` refers to, so that both could not be assigned a
> > new value.
> 
> Making Ellipsis a keyword will break ast.Ellipsis (and maybe some
> third-party libraries).
> 
> I realized that after my initial post which is why I subsequently
> suggested that its repr should perhaps be "Ellipsis (...)".

It does not help. If Ellipsis is a keyword, it is not possible to have
ast.Ellipsis. Not mentioned that it would be pretty confusing by itself
-- why you need to write Ellipsis(), but not None() or True()?

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

[Python-ideas] Re: The name Ellipsis should be a constant

[Serhiy Storchaka]

31.05.21 23:28, Chris Angelico пише:
> Although... since that's an arbitrary placeholder, it could be changed
> to pretty much anything. Maybe <...> or something? The current repr
> may not technically be ambiguous, but it will silently do the wrong
> thing if you try to eval it. You can even ast.literal_eval(repr(a))
> and it'll appear to work.

It was already discussed in 2015 [1], but the idea of <...> was rejected
by Guido [2].

[1]
https://mail.python.org/archives/list/python-ideas@python.org/thread/T2T7WR52AYLM7R77G6QMSDSPFYWBEBCL/
[2]
https://mail.python.org/archives/list/python-ideas@python.org/thread/RAZMTY2VGVXZYIO7RTA4DVW5C7MCTWOQ/

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

[Python-ideas] Re: The name Ellipsis should be a constant

[Serhiy Storchaka]

31.05.21 22:59, Jelle Zijlstra пише:
> Why isn't `repr(...)` just `...`?

Because it would confuse with reprs for recursive collections.

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

[Python-ideas] Re: The name Ellipsis should be a constant

[Serhiy Storchaka]

31.05.21 22:46, Chris Angelico пише:
> Originally, the notation "..." could only be used inside a subscript,
> and anywhere else, you'd have to spell it "Ellipsis". Now that you can
> use "..." anywhere, would it be worth switching the repr to just be
> that?

How would you then distinguish a recursive list from a list containing
Ellipsis?

   >>> a = []; a.append(a); a
   [[...]]
   >>> [[...]]
   [[Ellipsis]]

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

[Python-ideas] Re: The name Ellipsis should be a constant

[Serhiy Storchaka]

31.05.21 17:37, André Roberge пише:
> For consistency, `Ellipsis` (the name) should **always** refer to the
> same object that `...` refers to, so that both could not be assigned a
> new value.

Making Ellipsis a keyword will break ast.Ellipsis (and maybe some
third-party libraries).

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

[Python-ideas] Re: New Idea: A safe keyword to execute the following statement in a failsafe mode.

[Serhiy Storchaka]

23.05.21 12:42, Shivam Saini пише:
>     except:
>         pass

Don't do this. Never write a bare except handler which does not re-raise
an exception. There are few exceptions of this rule, but it is unlikely
that you will see them in first years of your practice. It is an
anti-pattern, and a feature that facilitates its use will never be added.

Always specify exceptions which you expect to catch. If you want to look
cool, you can use contextlib.suppress(), although it can make further
refactoring more difficult.

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

[Python-ideas] Re: New Idea: A safe keyword to execute the following statement in a failsafe mode.

[Serhiy Storchaka]

23.05.21 16:22, Shivam Saini пише:
> After all, python is known for one liners

It is not Python that is known for one liners. Python syntax is rather
opposed to one liners. It encourages and sometimes forces a user to
write well-indented 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/75RY5BWJEJDV36EHIKPWPKQ5BZL5BSWM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: division of integers should result in fractions not floats

[Serhiy Storchaka]

14.05.21 15:12, Martin Teichmann пише:
> when dividing two integers, the result is a float, which means we immediately 
> lose precision. This is not good if you want to use code which supports 
> higher precision. Decimals come to mind, but also sympy. This loss of 
> precision could be avoided if the result of a division is a fraction instead: 
> a fraction is exact.

Please read
http://python-history.blogspot.com/2009/03/problem-with-integer-division.html
.

In short, it was a feature of Python's predecessor, ABC. But it turned
out to be not as good as it seemed at first glance. Fixing this mistake
was one of causes of creating Python.

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

[Python-ideas] Re: Add support for private variables, methods and functions in Python

[Serhiy Storchaka]

06.05.21 15:46, Shreyan Avigyan пише:
> But Python doesn't have pointers and getattr, settatr can be adjusted to work 
> with private members.

It doesn't work this way. You cannot distinguish the use of getattr()
which breaks encapsulation from the one which does not. Inside getattr()
you only have an object, the name of the attribute, and possible
fallback value. You don't know whether it was called from the method of
that object, in which case the access to private attribute should not be
restricted, or outside of it. Changing this would require rewriting
significant part of the interpreter code, with possible performance
loss, introducing new bugs, and making the maintenance more difficult.
There would be needed separate storage for private attributes in object
(otherwise you could just access them via __dict__). I am not sure even
that the goal is achievable in principle, since in Python there is no
hard boundary between methods and functions. You can easily add new
methods at runtime.

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

[Python-ideas] Re: Add support for private variables, methods and functions in Python

[Serhiy Storchaka]

05.05.21 17:18, Shreyan Avigyan пише:
> I don't know if it's worth adding private to python modules but what about 
> classes? Private in class is an important feature in OOP that Python lacks 
> (Most OOP languages have private like Java, C++, etc.). I don't know why it 
> was introduced in the first place but it's kind of a convention to have that 
> feature in OOP.

Private fields in Python are no less private than in C++. In C++ you can
read private fields:

class User {
  public:
string name;
  private:
string password;
};

class HackedUser {
  public:
string name;
string password;
};

password = ((HackedUser*)&user)->password;

Of course it is a bad practice. You should not write this in your code,
and if your code allows executing arbitrary code in the same address
space, your security is already gone.

And the same is in Python. You can access private attributes, but
usually you should not (except for debugging purpose).

> Moreover why does private exist in the first place? If there's a reason then 
> shouldn't it apply to Python as well.

Private exists as a mean of self-limitation. It allows you to separate
your data and code on these which are purposed to be used outside of the
module or the class, and these which aren't. For your own good you must
follow this convention. The same reasons are applied to both C++ and
Python. It is more complicated in Java, but its security model is not
perfect in any case, and Python prefers the convenience of debugging and
simplicity of implementation.

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

[Python-ideas] Re: Support more conversions in format string

[Serhiy Storchaka]

21.04.21 12:14, Paul Moore пише:
> I don't have a particularly strong opinion here, other than to say I'm
> not sure I like the upper case "I". It looks far too much like a lower
> case "L" in the font I'm using here, which makes me think of C's
> "long", so it's easy to confuse. So of the two options, I prefer !f,
> !d, !i over !f, !i, !I.

Thank you. The upper case "I" is used in many formatting strings:
struct, memoryview, array, PyArg_Parse, Py_BuildValue, and there are no
plans for !l to confuse. But I follow you suggestion if there would not
be other arguments. Also, %d is more common than %d, so using !d for
lossy conversion to integer is understandable.

Maybe we even repurpose rarely used %i in printf-style formatting for
lossless conversion to integer.

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

[Python-ideas] Re: Support more conversions in format string

[Serhiy Storchaka]

23.04.21 12:22, Stephen J. Turnbull пише:
> Serhiy Storchaka writes:
> 
>  > Currently format strings (and f-string expressions) support three
>  > conversions: !s -- str, !r -- repr and !a for ascii.
> 
> It's not clear to me what these are good for, to be honest.  Why not
> just have s, r, and a format codes?  The !conversions don't compose
> with format codes:
> 
> >>> f"{10!r:g}"
> Traceback (most recent call last):
>   File "", line 1, in 
> ValueError: Unknown format code 'g' for object of type 'str'

Because it converts value to string, and string formatting does not
support "g". Converters !s, !r and !a are separated from format
specifier, and it is old and widely used feature.

I only propose to add more converters, because they are needed for some
compiler optimizations. I was going to add them as private AST detail in
any case, but if we are going to make this feature public, it is worth
to discuss it ahead to avoid name conflicts in future. I asked what
letters should be chosen for convertors for int() and index().

> So I don't think I want to go further.  I have some sympathy for your
> proposal, in part because I'd like to see something done about moving
> I18N into the format() mechanism.  But I'm going to play devil's
> advocate, mostly because I'm getting old enough to not like change so
> much. ;-)

I am not sure which relation does it have to I18N.

>  > I propose to add support of additional conversions: for int, float
>  > and operator.index. It will help to convert automatically printf-
>  > like format strings to f-string expressions: %d, %i, %u -- use int,
>  > %f -- use float, %o, %x -- use operator.index.
> 
> This makes more sense to me than !s, !r, and !a -- you might or might
> not want these conversions, I guess.  But it seems like a lot of
> complexity to add.  On the other hand, isn't the answer "fix
> __format__ in class definitions?"

We need to format a value as integer or float independently from
__format__ implementation, and raise an error if it cannot be converted
to integer or float. The purpose of the feature is bypassing __format__
and get the same result as in printf-style formatting.

> But we could change int.__format__ to allow 's' as a format code[1],
> automagically calling str(), just as 'efg' are allowed and
> automagically call float().

Yes, we could add support for "s" in int.__format__, but it was decided
to not do this for some reasons. It would confuse format specifier with
converter, it would make some errors be uncaught (like passing integer
when string is expected), it would require to duplicate the code of
str.__format__ in int.__format__ (and all other __format__'s where you
want to support "s").

>  > Currently I write f"path = {repr(str(path))}" or f"path =
>  > {str(path)!r}", but want to write f"path = {path!s!r}".
> 
> I have some sympathy for this; it's not a big change, and given the
> syntax you propose I doubt anyone would be confused about the
> semantics, including the order of conversions.  However:
> 
> To me, this seems like a clear case where you want to embed the
> conversions in the format code mechanism for those specific types:
> extend the __format__ method for URL objects to allow {url:h} where
> the 'h' format code applies "hex-escape", or you could repurpose the
> "u" code from the standard minilanguage to apply url-escape, or (I
> don't know if format allows) you could use {url:%}!

Supporting the "h" format code in the __format__ method for URL objects
is a reasonable idea, and it is the purpose of __format__ methods. But
it does not relates to converters. If you want to dump the value of some
variable using repr(), do you want to add support of "r" in every
implementation of __format__ in the world (and what if some is not
support it or use it with different semantic)?  "%r" % x just calls
repr(), and we wanted this feature in new formatting.

> How many types would need an additional format code to handle whatever
> use case wants repr(str())?

All types with custom __str__. If it is convertable to str, you often
want to see the string representation, because it is shorter and more
human readable than the result of repr(). But since it can contain any
special characters, you want to see them and the boundary of that
string, thus use repr() or ascii() on the resulted string.

> Or are you envisioning heavy use of !f!a
> etc?  (I can't see how any of the existing conversions could have an
> effect on the output of the numerical conversions you propose, though.)

No, I only need !s!r an

[Python-ideas] Re: : str() vs format(): trivia question

[Serhiy Storchaka]

22.04.21 10:21, Stephen J. Turnbull пише:
> @serhiy Moving my speculative discussion to python-ideas.  CC as
> courtesy, comment from you is welcome but not necessarily expected.
> 
> Serhiy Storchaka writes:
> 
>  > format() without format specifier and str() should return the same
>  > value in general, otherwise it will confuse users.
> 
> I think this is a good rule of thumb because it's a very plausible
> default for format(), and easy to explain.
> 
> But then what is the purpose of format()?  Why not just give str() the
> functionality of format(), and deprecate format() for future use?  Or
> vice versa, format() might be the better name, but the backward
> compatibility implications given the pervasive use of str() would be
> awesome, and not in a good way.

Technically, because the second argument of str() means encoding. So you
would need either make format specifier a third positional parameter,
str(price, None, None, '8.2f') or make it a keyword-only parameter,
str(price, format_spec='8.l2'). Both are look ugly. And since a format
specifier is mutually incompatible with encoding and errors, it is clear
that there should be two distinct functions.

Also, all existing __str__ methods do not accept additional arguments.
There is no way to pass format specifier to it. So we need a new special
method. We could name it __str_ex__, but __format__ seems a better name.

> Given how pervasive both str and format are, and the fact that str
> also has both .format() and .__format__ methods, I guess I'm asking
> for a lot of trouble.  But this plethora of approaches to providing a
> string presentation of an object seems designed to confuse users, and
> it's not clear to me that trying to maintain str(thing) == format(thing)
> necessary helps dissolve that confusion.

It is not hard to maintain because object.__format__ just calls __str__.
If you do not implement __format__, you get it by default. If you
implement __format__ you are free to do what you want.

And usually, if you implement addition and multiplication, you have to
maintain thing+thing == thing*2, but it does not mean that we need to
merge addition and multiplication into single operation.

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

[Python-ideas] Support more conversions in format string

[Serhiy Storchaka]

Currently format strings (and f-string expressions) support three
conversions: !s -- str, !r -- repr and !a for ascii.

I propose to add support of additional conversions: for int, float and
operator.index. It will help to convert automatically printf-like format
strings to f-string expressions: %d, %i, %u -- use int, %f -- use float,
%o, %x -- use operator.index.

For float the conversion letter is obvious -- !f. But I am not sure for
what !i should be used, for int or operator.index. If make it
operator.index, then !d perhaps should be used for int. If make it int,
then !I perhaps should be used for operator.index. Or vice verse?

Also I propose to support applying multiple conversions for the same
item. It is common when you output a path or URL object as quoted string
with all escaping, because in general it can contain special or
non-printable characters. Currently I write f"path = {repr(str(path))}"
or f"path = {str(path)!r}", but want to write f"path = {path!s!r}".

Do we need support of more standard conversions? Do we want to support
custom conversions (registered globally as encodings and error
handlers). re.escape, html.escape and shlex.quote could be very useful
in some applications.

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

[Python-ideas] Re: Why not deprecate Py_XDECREF in a future python version? Maybe a DeprecationWarning for now?

[Serhiy Storchaka]

15.04.21 10:03, Shreyan Avigyan пише:
> After going through the 
> https://github.com/python/cpython/blob/master/Include/object.h it seems that 
> Py_XDECREF is just calling Py_DECREF if the PyObject pointer is not NULL. 
> This if statement could be directly implemented in Py_DECREF right? Therefore 
> is it really required to have Py_XDECREF? Why not use a DeprecationWarning 
> for now and plan to deprecate Py_XDECREF in the near future?
> How about implementing an if statement in Py_DECREF to make it work like 
> Py_XDECREF?

Py_XDECREF is a convenient macro which allows you to write one line

Py_XDECREF(obj);

instead of 3 lines

if (obj != NULL) {
Py_DECREF(obj);
}

The code would look uglier without it.

Also, it is very difficult to deprecate it, because it is one of most
used macros/functions. You propose to break all existing extensions.

What exactly problem do you try to solve?

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

[Python-ideas] Re: Revive: PEP 396 -- Module Version Numbers ?

[Serhiy Storchaka]

12.04.21 21:49, Christopher Barker пише:
> Over the years, I've seen __version__ used very broadly but not *quite*
> in all packages. I've always known it was a convention, not a
> requirement. But it turns out it's not even a "official" convention.

If I have a time I finish my large patch for getting rid of __version__
and other outdated variables. It was approved previously
(https://mail.python.org/archives/list/python-...@python.org/thread/KBU4EU2JULXSMUZULD5HJJWCGOMN52MK/).
It is not simple, because it should be treated on case by case basis,
and there are several groups of similar cases, so finally it will
resulted in a series of PRs.

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

[Python-ideas] Re: Python Idea - extension of 'with'

[Serhiy Storchaka]

09.04.21 21:02, Guido van Rossum пише:
> But if there are two proposals with conflicting semantics for the same
> syntax that kills both ideas, doesn’t it? Because apparently it’s not
> clear what the syntax should mean.

Maybe. But there was also different idea for the "with" statement (with
semantic similar to Pascal's).

I understand the drawback of this syntax (error handlers are located too
far from the guarded code), but I do not have other syntax which would
look Pythonic.

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

[Python-ideas] Re: Adding syntax for the empty set

[Serhiy Storchaka]

09.04.21 19:08, micro codery пише:
> 
> You can now use `{*()}` as a syntax for empty set.
> 
> I saw that in the ast module and think it's clever, mainly in a good
> way. I don't think it is the same as having dedicated syntax for the
> empty set partly because I think it needs to be taught. I don't think a
> new pythonista would turn to empty tuple unpacking to get the empty set,
> where I do think that either set() or {,} would be natural, at least
> after some trial and exceptions.

Do you think that {,} does not need to be taught? It is a new special
syntax which needs paragraphs in tutorial and language reference. In
contrary, {*()} is a simple combination of already described syntax
elements.

> It also doesn't give quite the
> optimization as {,}.

It is a trivial optimization. It was not implemented yet only because
such code is never used in tight loops, empty set creation is very rare
operation at all. We prefer to keep the compiler simpler and focus on
optimizing common operations which has significant effect.

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

[Python-ideas] Re: Adding syntax for the empty set

[Serhiy Storchaka]

09.04.21 19:42, Ricky Teachey пише:
> On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka
>  <mailto:storch...@gmail.com>> wrote:
> You can now use `{*()}` as a syntax for empty set.
> 
> Interestingly, Raymond Hettinger recently had a post on twitter
> specifically deriding this usage as obfuscatory, and expressing his
> preference that people not do it (and use set() instead).

I agree, but between introducing a new syntax for special rare case and
using uncommon (but understable) expression in existing syntax I prefer
the latter.

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

[Python-ideas] Re: Adding syntax for the empty set

[Serhiy Storchaka]

09.04.21 12:50, Matt del Valle пише:
> I think sets are the only type in the builtins module
> without a dedicated literal syntax?

Not only. bytearray, frozenset, slice. It is difficult to create some
complex objects without using constructor. Not counting range,
memoryview and dict views, descriptors (staticmethod, classmethod,
property), exceptions, iterators (filter, map, zip, enumerate, reversed
and numerous collection iterators). All these types are defined in the
builtins 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/LS43IAFFLNCCVVLF6WXMXOYZFOSNOHRL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Python Idea - extension of 'with'

[Serhiy Storchaka]

08.04.21 17:59, anthony.flury via Python-ideas пише:
> I was wondering whether a worthwhile extension might be to allow the
> `with` statement to have an `except` and  `else` clauses which would
> have the same
> semantics as wrapping the `with` block with a try - for example the
> above would now look like:
> 
> 
> with open('config.cfg', 'r') as cfg:
>     # Process the open  file
>     config = load_config(cfg)
> except FileNotFound:
>     logging.info('Config file not found - using default configuration')
> except PermissionError:
>     logging.warning('Cannot open config .cfg - using default
> configuration')
>     config = default_config()
> else:
>     logging.info('Using config from config.cfg')

A year or two ago I proposed the same syntax with different semantic: to
catch only exceptions in the context manager, not in the with block.
Exceptions in the with block you can catch by adding try/except around
the with block, exceptions in the with block and the context manager you
can catch by adding try/except around the with statement, but there is
no currently way to catch only exceptions in the context manager.

It is quite a common problem, I encounter it several times per year
since then. I still have a hope to add this feature, and it will
conflict with your idea.

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

[Python-ideas] Re: Adding syntax for the empty set

[Serhiy Storchaka]

08.04.21 19:58, ucod...@gmail.com пише:
> I would like to propose adding literal syntax to allow creation of an empty 
> set without the need to call the type constructor. I believe the best choice 
> for such a literal, and one that has been proposed before, is `{,}`.

You can now use `{*()}` as a syntax for empty set.

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

[Python-ideas] Re: Suggesting feature for python - Big Set, Big Dictionary

[Serhiy Storchaka]

23.03.21 07:55, Vijay Patel пише:
> Suggestion:
> 1. Big Set, Big Dictionary -
> During design time, i am considering this question. With limited RAM
> (example 4 GB), how can I store a dictionary/set of size greater than RAM.
> 
> Is it possible to introduce Big Set / Big Dictionary which stores data
> in hard disk (based on some partition mechanism - like big data)?
> (i.e.Big Set/Big Dictionary with set access mechanism identical to
> current set and dictionary).

Look at the shelve module. It provides a dict-like class with permanent
storage. It can be used to work with data larger than the RAM volume if
you sync the cache at times.

It has limitations: keys can only be strings. It would be not easier to
support arbitrary objects as keys because the pickle protocol does not
guarantee that equal values are serialized to the same data. But if you
need to work with non-string keys, you can write your own wrapper which
serializes your keys to strings.

In any case you can take that implementation as an example and write
your own implementation which suits your needs. I do not think it will
be added in the stdlib, as it looks pretty niche solution, but you can
publish it on PyPI.

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

[Python-ideas] Re: shouldn't slices be iterable ?

[Serhiy Storchaka]

19.03.21 01:44, Cameron Simpson пише:
> I know that range(start,end,stride) will produce what I'd want from 
> iter(slice(start,end,stride)), but wouldn't it be reasonable for a slice 
> itself to be iterable?
> 
> Yes, only one obvious way and all that, but inside eg __getitem__ it 
> seems to me that:
> 
> if isinstance(index, slice):
> for i in index:
> ... do stuff with i ...
> 
> is the obvious thing to do.

It was discussed several times before.

It cannot work, because you need to know the length of the sequence to
bound limits and to determine the start and end indices if corresponding
slice attributes are negative or if stride is negative.

If sequence a has 10 elements, a[2:100] should only iterate from 2 to 9,
a[-5:-2] should iterate from 5 to 7, and a[::-1] should iterate from 9 to 0.

slice.indices() gives you normalized start, end and stride which you can
pass to range() for iterating.

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

[Python-ideas] Re: Enum: determining if a value is valid

[Serhiy Storchaka]

12.03.21 23:48, Ethan Furman пише:
> A question that comes up quite a bit on Stackoverflow is how to test to
> see if a value will result in an Enum member, preferably without having
> to go through the whole try/except machinery.
> 
> A couple versions ago one could use a containment check:
> 
>   if 1 in Color:
> 
> but than was removed as Enums are considered containers of members, not
> containers of the member values.  It was also possible to define one's
> own `_missing_` method and have it return None or the value passed in,
> but that has also been locked down to either return a member or raise an
> exception.
> 
> At this point I see three options:
> 
> 1) add a `get(value, default=None)` to EnumMeta (similar to `dict.get()`
> 
> 2) add a recipe to the docs
> 
> 3) do nothing
> 
> Thoughts?

The Enum class is already too overloaded. I sometimes think about adding
SimpleEnum class with minimal simple functionality which would allow to
use enums in more modules sensitive to import time.

As for solving your problem, try/except looks the best solution to me.

try:
Color(1)
except ValueError:
... # invalid color
else:
... # valid color

If you don't like try/except, the second best solution is to add a
module level helper in the enum module:

def find_by_value(cls, value, default=None):
try:
return cls(value)
except ValueError:
return default

You can add also find_all_by_value(), get_aliases(), etc. It is
important that they are module-level function, so they do not spoil the
namespace of the Enum class.

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

[Python-ideas] Re: Make list.reverse() more flexible

[Serhiy Storchaka]

06.03.21 09:52, Vincent Cheong пише:
> I see. I do agree that my reply brings about that 'verbose repeated' feeling, 
> haha. But for the record, it's not about having something in hand now for the 
> future, but it's more of a paradigmatic approach to the implementation. 
> Python has changed for the better in terms of necessity:
> 
> - map() returns an iterator instead of a whole list at once
> - generator yields values only when needed (unlike list comprehension)
> 
> So I thought, 'Why do we need to make a reversed copy to assign it to the 
> original part, when we can simply reverse the original part itself.' That's 
> the paradigm.

Your proposition is not related to changes in map() and other builtins
which return now an iterator instead of list. It is more similar to idea
of adding parameters start and stop to map(), so it could be appplied to
a part of the list.

More general approach would allow you to write

a[i:j] = a[i:j][::-1]

and it would be a zero-overhead operation because slices are lazy or
because the compiler recognize the pattern and generate the optimal
code. But it requires a sophisticate compiler.

Less sophisticate approach is using an explicit wrapper for lazy slices:

a[i:j] = view(a)[i:j][::-1]

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

[Python-ideas] Re: Alternate lambda syntax

[Serhiy Storchaka]

11.02.21 13:24, J. Pic пише:
> Lambdas can be defined as such:
> 
> w = lambda: [12]
> x = lambda y: len(y)
> 
> I'd like to propose the following:
> 
> w = (): [12]
> x = (y): len(y)

This syntax is ambiguous.

if (y): len(y):

What does the first colon mean? You cannot say until you read the second
colon. It is difficult to parse for human and computer. While the
current PEG parser perhaps can handle this, it still makes parsing
slower and the code more errorprone.

Lambda is a questionable feature at all. With support of comprehensions,
local functions, the operator and functools modules there are not many
use cases for lambda expression. They are supported, well, but it is not
significant part of the language.
___
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/HX4LSMUPUGA65GQNNITM6RBPDRI34YFA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Additional LRU cache introspection facilities

[Serhiy Storchaka]

12.01.21 21:28, Sebastian Kreft пише:
> class ForcePythonLruCache(importlib.abc.MetaPathFinder):
>     def find_spec(self, fullname, path, target=None):
>         if fullname == '_functools':
>             raise ImportError('_functools not available')

You can just set sys.modules['_functools'] = None.
___
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/DQDGTHKTQLQYKD7EZAQQ2RL5HBG6QGEU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Additional LRU cache introspection facilities

[Serhiy Storchaka]

12.01.21 18:57, Steven D'Aprano пише:
> Can you explain further why the cached function needs additional 
> syncronisation overhead?

The cache uses a double-linked list to track what item is the oldest and
changes it every time you call the cached function (move the found or
new item to the beginning of the list). Code that changes links of the
list is critical. If it is interrupted, we can get a crash or infinite
loop in C. It is guarded by GIL, now Python code is called when changes
are made.

Now, if we iterate the list and save items, we can call Python code when
save items (especially if we save them into a dict). It can change the
list. In the best case it can lead to skipped or duplicated items and
random runtime errors when we use the cached function in other thread
during inspecting the cache. It is not much worse than iterating a
modifying dict. In worst case we can get crashes, perhaps in different
places of code. This code should be written very accurately. There were
three iterations by three authors of writing the C implementation of the
lru_cache, and some bugs were founds several months after that.

One of ways to do it safely is to add explicit locks in addition to GIL.
It is not the easiest, nor the safest, and of course not the most
efficient way, but it is the most obvious one.

> - If you export the cache from one thread while another thread is 
>   reading the cache, I expect that would be safe.

Reading the cache always modifies it.

> I was having trouble with the function, and couldn't tell if the right 
> arguments where going into the cache. What I wanted to do was peek at 
> the cache and see which keys were ending up in the cache and compare 
> that to what I expected.

In your case it would perhaps easier to write your own implementation of
the cache, or disable the C implementation and use the Python
implementation of lru_cache(), which allows some introspection. In any
case, it was one-time problem, and it is already solved. If it occurred
more than one time, it would make sense to think about including such
feature in the stdlib.

But the cost of it may be larger than you expect.
___
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/CRI3QNJEGAFCQXPSFAVZWJTPXF5Y7OOT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Additional LRU cache introspection facilities

[Serhiy Storchaka]

12.01.21 12:02, Steven D'Aprano пише:
> Is anyone else interested in additional introspection facilities for the 
> functools.lru_cache?
> 
> You can view the cache hit and miss statistics using the cache_info() 
> method, but you can't see what values actually are in the cache. That 
> would be useful to me.
> 
> I propose a method:
> 
> @functools.lru_cache()
> def function(arg):
> ...
> 
> function.cache_export()
> 
> that returns a dictionary {arg: value} representing the cache. It 
> wouldn't be the cache itself, just a shallow copy of the cache data.

What if the function supports multiple arguments (including passed by
keyword)? Note that internal representation of the key is an
implementation detail, so you need to invent and specify some new
representation. For example return a list of tuples (args, kwargs, result).

Depending on the implementation, getting the list of all arguments can
have larger that linear complexity.

Other cache implementations can contain additional information: the
number of hits for every value, times. Are you interesting to get that
information too or ignore it?

Currently the cache is thread-safe in CPython, but getting all arguments
and values may not be (or we will need to add a synchronization overhead
for every call of the cached function).

And finally, what is your use case? Is it important enough to justify
the cost?
___
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/IUOWLRO425FVYOA7ICRCTPYQCUBELCWB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: An option to force the path separator for the "os.path.join()" method.

[Serhiy Storchaka]

06.01.21 06:07, Mikhail V пише:
> I know there is the "pathlib" module with all conversion methods, but
> it's overkill for many
> tasks. So I'd rather like to have an option to write for example:
> 
> path = os.path.join (root, dir, sep = "posix")
> 
> So that it joins with the forward slash even if run on Windows.
> Also it seems that e.g. "os.path.split()" already supports both
> separators, so I think this addition won't bring inconsistency into
> the module and its usage.

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

[Python-ideas] Re: Option to not raise if file does not exists for os.remove()?

[Serhiy Storchaka]

29.12.20 22:58, Marco Sulla пише:
> What about a parameter, false by default, that suppresses the
> FileNotFoundError exception if true for os.remove()? Something similar
> to exist_ok for os.makedirs().

You have two options (and it's too much in my opinion):

try:
os.remove(filename)
except FileNotFoundError:
pass

with contextlib.suppress(FileNotFoundError):
os.remove(filename)
___
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/TFNKPSBCEWTT4IXOQRNT4TFDI66TAHKH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Unpack operator "**" and Mapping

[Serhiy Storchaka]

26.12.20 13:23, Anton Abrosimov пише:
> I am trying to release comfortable dataclass unpacking using `**` operator. 
> Now I have 5 different ways to do it.
> But not a single good one. Confused by the implementation of the unpacking 
> operator.
> 
> So when I try to unpack any custom class, I get the error:
> 
> `type object argument after ** must be a mapping, not MyClass`
> 
> Ok, nothing special. I need to use `collections.abc.Mapping` right?
> Now I need to implement: `__getitem__`, `__iter__`, `__len__`. Not a problem.
> But additionally I get: `keys`, `items`, `values`.
> Hey, I don't need them. I don't need the full mapping functionality. I only 
> need the double asterisk to work.
> 
> Right, we have a duck typing!
> We throw out `abc.Mapping`. What do we need to implement?
> It's `__getitem__` and `keys`. Wtf `keys`?
> 
> I am looking at Python Data model: 
> https://docs.python.org/3/reference/datamodel.html
> There many operators, and they depend on special double underscore methods.
> Hmm, I don't see unpack operators there, it's strange.
> But why it's `keys`? Because the historical is `dict`?
> I think a dependency on `__iter__` is more preferable and expectable over a 
> userspace named `keys`.
> Actually, `items()` is more predictable.

See thread "Add __keys__ or __items__ protocol".
https://mail.python.org/archives/list/python-ideas@python.org/thread/A3CK7Y2ICIIVYKMAXSCUVYLK7IC7CH6G/#LCWMA6WMFLLSWXPKYC6FEUDHZBR3MYPE

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

[Python-ideas] Re: Standalone bool?

[Serhiy Storchaka]

22.12.20 03:18, David Mertz пише:
> Indeed.  The discussion around this was quite specifically that many
> people defined:
> 
> True = 1
> False = 0
> 
> At the top of their code, and used that.  This was the main reason they
> were built-ins rather than keywords, so as not to break that large body
> of existing code.

I think that it was rather to allow writing the code

try:
True, False
except NameError:
True = 1
False = 0

which would work with new and old Python versions.

People that defined they own constants before adding bool would likely
used "true" or "TRUE".
___
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/EFSVOKC4RQ3UIYV6ESADHNDZZDWHIVN5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Standalone bool?

[Serhiy Storchaka]

21.12.20 10:11, Paul Bryan пише:
> Wouldn't that still work if bool's __int__ returns 1?

Implementing `__index__` would solve 90% of all problems with non-int
booleans. But not the example provided by David (it requires `__add__`).
And there may be more specific cases when you need to make arithmetic or
bit operations with booleans or sort them. In result you would need to
implement all method inherited from int in new bool. And what is the
difference?
___
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/GITIXGDTGHUZ4SI56GEKT2ZWOINS3KVJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Standalone bool?

[Serhiy Storchaka]

21.12.20 10:09, David Mertz пише:
> I sure hope this never happens! It would break millions of working lines
> and kill a common useful pattern.
> 
> ntrue = sum(this == that for this, that in items)

It is too, but the main reason is that the C code parses boolean
parameters as integers (using PyArg_Parse("i") or similar).
___
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/A7URS3JFHUFERQAGAR73BQJUFD7ID5BU/
Code of Conduct: http://python.org/psf/codeofconduct/