[Python-ideas] Re: Experimenting with dict performance, and an immutable dict

[Inada Naoki]

On Wed, Jul 22, 2020 at 7:31 AM Marco Sulla
 wrote:
>
> For benchmarks, I used simply timeit, with autorange and repeat and, as 
> suggested in the module documentation, I got the minimum of the results. Here 
> is the code:
>
> https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.py
>

I strongly recommend to use pyperf for benchmarking.
Otherwise, you will see random performance changes caused by random
reasons including ASLR.

https://pypi.org/project/pyperf/
https://pyperf.readthedocs.io/en/latest/

Regards,
-- 
Inada Naoki  
___
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/HJJFTU42RMB5QTZ5HL7H2J73XMNT2BNW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Experimenting with dict performance, and an immutable dict

[Marco Sulla]

Yes. Values can be mutable, as tuple. A "pure" immutable dict is a
frozendict with only immutable values (strings, tuples of numbers etc). In
this case you also have a hash.

frozendict apart, I think some of my "tricks" could be applied to dict, if
the implementation sounds and there's a real benefit. I'm not a C expert
and my knowledge of the Python C API is very limited. But, if you core devs
think it's worth it, I could try to submit some patch in CPython trunk.

> one problem with frozen dicts in the past is deciding exactly what is
mutable and what is immutable.

Well, I had the same problem... Indeed it seems there's no way to use the
duck typing to understand if a type is mutable or not. I suppose this can
only be done using a convention, or a contract. If we know that an object
is immutable, you can adopt some cache and speedup strategies.

On Wed, 22 Jul 2020 at 06:53, Guido van Rossum  wrote:

> That seems pretty clear — presumably it follows the lead of frozenset and
> tuple.
>
> On Tue, Jul 21, 2020 at 21:45 Todd  wrote:
>
>> What, exactly, is frozen?  My understanding is that one problem with
>> frozen dicts in the past is deciding exactly what is mutable and what is
>> immutable.  Can you change what object a key maps to so long as the set of
>> keys stay the same?  Can you modify the contents of mutable object that is
>> a value?
>>
>> On Tue, Jul 21, 2020 at 6:30 PM Marco Sulla 
>> wrote:
>>
>>> Let me first say that the code and discussion, as per title, is also
>>> about possible performance improvements to the dict base type.
>>>
>>> TL;DR I implemented a frozendict using CPython 3.9 code. It seems that
>>> an immutable dict *could* be faster than dict in some cases. Furthermore,
>>> some optimization could be applied to dict too.
>>>
>>> Long explaining:
>>>
>>> Since now I have some time, I decided to experiment a little with the
>>> creation of an immutable dict in Python.
>>>
>>> Unluckily, I started this experiment many months ago, so the CPython
>>> code I used is old. Maybe some or all of my considerations are outdated.
>>>
>>> Initially, I wrote a quick and dirty implementation:
>>>
>>> https://github.com/Marco-Sulla/cpython/commit/fde4e6d236b19636063f8afedea8c50278205334
>>>
>>> The code was very simple, and the performance was identical to dict. So
>>> in theory, adding a frozendict to CPython is not hard. But there's more.
>>>
>>> After the first implementation, I started to try to improve the
>>> performance of frozendict. The result of the improvements are here:
>>>
>>>
>>> https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.txt
>>>
>>> For benchmarks, I used simply timeit, with autorange and repeat and, as
>>> suggested in the module documentation, I got the minimum of the results.
>>> Here is the code:
>>>
>>>
>>> https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.py
>>>
>>> I have not tested with an optimized build, since optimization data is
>>> collected using the unit tests, and I didn't write tests for frozendict in
>>> the official CPython test framework.
>>>
>>> The tests and benchmarks were done using CPython 3.9a0. CPU and other pc
>>> resources were not restricted using pyperf or similar tools, to see the
>>> "real" speed. CPython was compiled using gcc and g++.
>>>
>>> In benchmarks, I compared methods and operators using dict and
>>> frozendict. The benchmark uses dicts with all integers and dicts with all
>>> strings. Furthermore, I tested dicts with size 8 (the most optimized size
>>> in CPython) and 1000 elements (maybe too much, but I wanted to see how they
>>> perform with a high number of elements).
>>>
>>> Every benchmark has a line in the output. The Name describes the
>>> benchmarked method, operator or code snippet. Size is the size of the dict,
>>> 8 or 1000. Keys are the keys type, str or int. Type is the dictionary type,
>>> dict or frozendict.
>>>
>>> In Name, the "o" represents the object itself (dict or frozendict). "d",
>>> in benchmark with dict, is "o"; in benchmarks with frozendict is an
>>> equivalent instance of type dict.
>>>
>>> Some consideration:
>>>
>>> 1. frozendict is very fast, as expected, at copying. But it's also
>>> faster at creation, using a (not frozen) dict, kwargs or a sequence2.
>>> Speedups range from 20% to 45%.
>>> 2. frozendict is also a bit faster when you iterate over it, especially
>>> over values, where is ~15% faster
>>> 3. hash seems really fast, but this is because it's cached the first
>>> time hash() is invoked
>>> 4. where frozendict is slower is when you unpickle it and with fromkeys
>>> and repr. This is because I wrote a very naif implementation of these
>>> methods, without optimizing them. The other methods have a comparable speed.
>>>
>>> Here is the code:
>>> https://github.com/Marco-Sulla/cpython
>>>
>>> Here is the diff between the CPython code and my commits:
>>> https://github.com/python/cpython/compare/master...Marco-Sulla:master
>>>
>>> About code
>>>

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Wes Turner]

On Mon, Jul 13, 2020, 3:04 PM Christopher Barker 
wrote:

> Is there ANY chance of setting the default reply-to to the list? I know
> everyone else thinks that's a bid idea, but I doubt this was actually
> intended just for me.
>
> If it was, I apologize for bringing it back on the list.
>
> On Sun, Jul 12, 2020 at 10:12 PM Inada Naoki 
> wrote:
>
>> On Mon, Jul 13, 2020 at 1:51 PM Christopher Barker 
>> wrote:
>> As I and Eric already said several times, we can do it in C already --
>> itertools.islice.
>>
>> ...
>
> itertools.islice is implemented in C too. No need to call next() from
>> Python stack.
>>
>
> Ahh -- thanks! I had no idea islice() was in C -- yes, then, there
> probably is little to gain from a C implementation.
>
> I'd still be interested in the performance comparison, but not enough to
> try to write a direct-access-to-the-internals-of-dict C version myself :-)
>
> I still like the idea of indexing the order-preserving dict, but we do
> seem to not have any compelling use cases.
>

Some ideas for optimizing lookup of ordered indexed structures:

https://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html :

> loc, .iloc, and also [] indexing can accept a callable as indexer. See
more at Selection By Callable.

Pandas > Enhancing performance > Numba > Vectorize
https://pandas.pydata.org/pandas-docs/stable/user_guide/enhancingperf.html#vectorize

(
https://scikit-learn.org/stable/modules/generated/sklearn.feature_extraction.DictVectorizer.html
)

https://docs.rapids.ai/api/cudf/stable/guide-to-udfs.html#Numba-Kernels-on-CuPy-Arrays

https://arrow.apache.org/docs/python/pandas.html#handling-pandas-indexes

> Methods like pyarrow.Table.from_pandas() have a preserve_index option
which defines how to preserve (store) or not to preserve (to not store) the
data in the index member of the corresponding pandas object. This data is
tracked using schema-level metadata in the internal arrow::Schema object.

... Type signatures are particularly helpful for indexes.


> Particularly if someone does get a reservoir sampling implementation in
> the stdlib. (see another thread for that)
>
> -CHB
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> 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/ZL2VYGVO7MB63TAJKDL4YKSB64X5YP55/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RHTALEYSBRERRVW7WHDU2EEJZOAVW3U7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Experimenting with dict performance, and an immutable dict

[Guido van Rossum]

That seems pretty clear — presumably it follows the lead of frozenset and
tuple.

On Tue, Jul 21, 2020 at 21:45 Todd  wrote:

> What, exactly, is frozen?  My understanding is that one problem with
> frozen dicts in the past is deciding exactly what is mutable and what is
> immutable.  Can you change what object a key maps to so long as the set of
> keys stay the same?  Can you modify the contents of mutable object that is
> a value?
>
> On Tue, Jul 21, 2020 at 6:30 PM Marco Sulla 
> wrote:
>
>> Let me first say that the code and discussion, as per title, is also
>> about possible performance improvements to the dict base type.
>>
>> TL;DR I implemented a frozendict using CPython 3.9 code. It seems that an
>> immutable dict *could* be faster than dict in some cases. Furthermore, some
>> optimization could be applied to dict too.
>>
>> Long explaining:
>>
>> Since now I have some time, I decided to experiment a little with the
>> creation of an immutable dict in Python.
>>
>> Unluckily, I started this experiment many months ago, so the CPython code
>> I used is old. Maybe some or all of my considerations are outdated.
>>
>> Initially, I wrote a quick and dirty implementation:
>>
>> https://github.com/Marco-Sulla/cpython/commit/fde4e6d236b19636063f8afedea8c50278205334
>>
>> The code was very simple, and the performance was identical to dict. So
>> in theory, adding a frozendict to CPython is not hard. But there's more.
>>
>> After the first implementation, I started to try to improve the
>> performance of frozendict. The result of the improvements are here:
>>
>>
>> https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.txt
>>
>> For benchmarks, I used simply timeit, with autorange and repeat and, as
>> suggested in the module documentation, I got the minimum of the results.
>> Here is the code:
>>
>>
>> https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.py
>>
>> I have not tested with an optimized build, since optimization data is
>> collected using the unit tests, and I didn't write tests for frozendict in
>> the official CPython test framework.
>>
>> The tests and benchmarks were done using CPython 3.9a0. CPU and other pc
>> resources were not restricted using pyperf or similar tools, to see the
>> "real" speed. CPython was compiled using gcc and g++.
>>
>> In benchmarks, I compared methods and operators using dict and
>> frozendict. The benchmark uses dicts with all integers and dicts with all
>> strings. Furthermore, I tested dicts with size 8 (the most optimized size
>> in CPython) and 1000 elements (maybe too much, but I wanted to see how they
>> perform with a high number of elements).
>>
>> Every benchmark has a line in the output. The Name describes the
>> benchmarked method, operator or code snippet. Size is the size of the dict,
>> 8 or 1000. Keys are the keys type, str or int. Type is the dictionary type,
>> dict or frozendict.
>>
>> In Name, the "o" represents the object itself (dict or frozendict). "d",
>> in benchmark with dict, is "o"; in benchmarks with frozendict is an
>> equivalent instance of type dict.
>>
>> Some consideration:
>>
>> 1. frozendict is very fast, as expected, at copying. But it's also faster
>> at creation, using a (not frozen) dict, kwargs or a sequence2. Speedups
>> range from 20% to 45%.
>> 2. frozendict is also a bit faster when you iterate over it, especially
>> over values, where is ~15% faster
>> 3. hash seems really fast, but this is because it's cached the first time
>> hash() is invoked
>> 4. where frozendict is slower is when you unpickle it and with fromkeys
>> and repr. This is because I wrote a very naif implementation of these
>> methods, without optimizing them. The other methods have a comparable speed.
>>
>> Here is the code:
>> https://github.com/Marco-Sulla/cpython
>>
>> Here is the diff between the CPython code and my commits:
>> https://github.com/python/cpython/compare/master...Marco-Sulla:master
>>
>> About code
>>
>> I coded the implementation doing a simple copy/paste of the existing dict
>> functions, modifying their code and renaming them. This way I'm sure dict
>> continues to work as before, and I can compare the speed gain.
>>
>> Some of the optimization I adopted can be implemented in `dict` too. For
>> example, instead of creating an empty dict and resizing it, I create it
>> with the "maximum" size and I fill it. It seems to work, even if I did not
>> explore the possibility that a mutable object can change while a frozendict
>> creation is in progress.
>>
>> Some problems with optimizing dict and maintaining a frozendict:
>>
>> 1. duplication of code. To gain a significant boost, I had to copy and
>> paste a lot of code. Functions can be remerged again, but maybe the speedup
>> will be reduced.
>> 2. split vs combined dicts. As I wrote, split dicts seem to be faster in
>> reading than combined dicts. For example, iterating over values is faster
>> with a split dict, as expected.
>> But writing was 

[Python-ideas] Re: Experimenting with dict performance, and an immutable dict

[Todd]

What, exactly, is frozen?  My understanding is that one problem with frozen
dicts in the past is deciding exactly what is mutable and what is
immutable.  Can you change what object a key maps to so long as the set of
keys stay the same?  Can you modify the contents of mutable object that is
a value?

On Tue, Jul 21, 2020 at 6:30 PM Marco Sulla 
wrote:

> Let me first say that the code and discussion, as per title, is also about
> possible performance improvements to the dict base type.
>
> TL;DR I implemented a frozendict using CPython 3.9 code. It seems that an
> immutable dict *could* be faster than dict in some cases. Furthermore, some
> optimization could be applied to dict too.
>
> Long explaining:
>
> Since now I have some time, I decided to experiment a little with the
> creation of an immutable dict in Python.
>
> Unluckily, I started this experiment many months ago, so the CPython code
> I used is old. Maybe some or all of my considerations are outdated.
>
> Initially, I wrote a quick and dirty implementation:
>
> https://github.com/Marco-Sulla/cpython/commit/fde4e6d236b19636063f8afedea8c50278205334
>
> The code was very simple, and the performance was identical to dict. So in
> theory, adding a frozendict to CPython is not hard. But there's more.
>
> After the first implementation, I started to try to improve the
> performance of frozendict. The result of the improvements are here:
>
>
> https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.txt
>
> For benchmarks, I used simply timeit, with autorange and repeat and, as
> suggested in the module documentation, I got the minimum of the results.
> Here is the code:
>
> https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.py
>
> I have not tested with an optimized build, since optimization data is
> collected using the unit tests, and I didn't write tests for frozendict in
> the official CPython test framework.
>
> The tests and benchmarks were done using CPython 3.9a0. CPU and other pc
> resources were not restricted using pyperf or similar tools, to see the
> "real" speed. CPython was compiled using gcc and g++.
>
> In benchmarks, I compared methods and operators using dict and frozendict.
> The benchmark uses dicts with all integers and dicts with all strings.
> Furthermore, I tested dicts with size 8 (the most optimized size in
> CPython) and 1000 elements (maybe too much, but I wanted to see how they
> perform with a high number of elements).
>
> Every benchmark has a line in the output. The Name describes the
> benchmarked method, operator or code snippet. Size is the size of the dict,
> 8 or 1000. Keys are the keys type, str or int. Type is the dictionary type,
> dict or frozendict.
>
> In Name, the "o" represents the object itself (dict or frozendict). "d",
> in benchmark with dict, is "o"; in benchmarks with frozendict is an
> equivalent instance of type dict.
>
> Some consideration:
>
> 1. frozendict is very fast, as expected, at copying. But it's also faster
> at creation, using a (not frozen) dict, kwargs or a sequence2. Speedups
> range from 20% to 45%.
> 2. frozendict is also a bit faster when you iterate over it, especially
> over values, where is ~15% faster
> 3. hash seems really fast, but this is because it's cached the first time
> hash() is invoked
> 4. where frozendict is slower is when you unpickle it and with fromkeys
> and repr. This is because I wrote a very naif implementation of these
> methods, without optimizing them. The other methods have a comparable speed.
>
> Here is the code:
> https://github.com/Marco-Sulla/cpython
>
> Here is the diff between the CPython code and my commits:
> https://github.com/python/cpython/compare/master...Marco-Sulla:master
>
> About code
>
> I coded the implementation doing a simple copy/paste of the existing dict
> functions, modifying their code and renaming them. This way I'm sure dict
> continues to work as before, and I can compare the speed gain.
>
> Some of the optimization I adopted can be implemented in `dict` too. For
> example, instead of creating an empty dict and resizing it, I create it
> with the "maximum" size and I fill it. It seems to work, even if I did not
> explore the possibility that a mutable object can change while a frozendict
> creation is in progress.
>
> Some problems with optimizing dict and maintaining a frozendict:
>
> 1. duplication of code. To gain a significant boost, I had to copy and
> paste a lot of code. Functions can be remerged again, but maybe the speedup
> will be reduced.
> 2. split vs combined dicts. As I wrote, split dicts seem to be faster in
> reading than combined dicts. For example, iterating over values is faster
> with a split dict, as expected.
> But writing was not tested; furthermore, some of the optimizations can be
> adopted for dicts too, so the convenience of a split table can be lowered.
> dict continues to maintain both split and combined tables, so this could
> be not a problem. But the code 

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Todd]

On Tue, Jul 21, 2020 at 2:05 PM David Mertz  wrote:

> On Tue, Jul 21, 2020, 12:14 PM Sebastian Berg
>
>> First, using it for named dimensions, means you don't actually need to
>> mix it with normal tuple indexing, mixing both seems rather confusing?
>>
>> temperature.loc(method="nearest")[longitude=longs, latitude=lats]
>>
>
> [*] In my opinion, passing the keyword argument using anything other than
> the standard **kws style sounds crazy. We have perfectly good ways to do
> that for every other function or method. Don't invent something new and
> different that only works with .__getitem__().
>

 It would also be possible to pass __getitem__ exactly one other argument,
a dict with all the named arguments.

So instead of __getitem__(inds, **kwargs) simply __getitem__(inds, kwargs)

"kwargs" would be the same in both cases, a dict with the key/value pairs.
In most cases a dict is what people are going to want anyway.  It avoids
having to unpack then repack the dict.  But it would make it slightly
harder for adding parameters to indexing, although I am skeptical of that
use-case to begin with.  It would also make it feasible to use labels that
aren't valid variable names, although it may not be desirable to support
that.
___
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/WUS2RRY73GOZVUC4BUP7WF6WAXERDDAS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Todd]

On Sat, Jul 18, 2020, 00:21 Ricky Teachey  wrote:

>
> This raises a question that needs to be answered, then: what would be the
> utility of mixing together positional and kwd arguments in this way?
>
> Even the xarray examples given so far don't seem to make use of this
> mixture. From my knowledge of pandas I am not sure what the meaning of
> this would be, either.
>

For xarray an index can have a position, a label, or both.  So being able
to mix positional and label-based indexing is important.  I just didn't
include that in the examples because I was focusing on the advantage of
label-based indexing.

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

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Paul Sokolovsky]

Hello,

On Tue, 21 Jul 2020 17:48:35 -0700
Christopher Barker  wrote:

> how about:
> 
> for something in some_iterable:
> some_stuff_with_maybe_a_break
> else if not break:
> something_more
> 
> No new keywords :-)
> 
> or:
> 
> for something in some_iterable:
> some_stuff_with_maybe_a_break
> else:  # if not break:
> something_more

This is the most genius solution posted to this thread.

And if the thread didn't die after van Rossum's post, I don't cheer
hopes it would die now, but let me sprinkle in another "fresh"
thought. First let me remind how this thread started:

> ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause
> instead   

Then various people started to throw in variants of even more unclear
and confusing syntax (like "if" after "for"), with some percentage of
those people demonstrating not understanding how the original "else"
works.

But consider following idea: if it's confusing, DO NOT USE it. You
don't hear that often, but: treat Python as a generic programming
language, not as a bag of tricks. The fact that most other languages
don't have extra clause after "for" is enough of a reason to not use it
in Python either.


So why it exists at all then? It's there for people who don't find it
confusing, for very responsible use. As a random example, after
studying 2 (bytecode) Python compilers and having written my own (so I
know what code is generated from for-else), I no longer find it
confusing. I actually found 2 intuitive ways to use that construct, in
the very compiler mentioned - after all, if you eyeball a Python
compiler, you either know, or ready to learn, how all language
constructs work.

For anything else - clear ban. Everyone should consider that too. (But
please leave the language syntax alone (backwards compatibility, etc.),
at least that's a suggestion which comes out from van Rossum's post).

> As for the "loop didn't run at all" case: Does anyone find a need for
> that? Personally, I've found that everytime I do some kind of check
> for an empty iterable before a loop, it was totally unnecessary.

I find the need for that regularly. And I use the obvious syntax which
everyone else uses:

if not seq:
print("This page is intentionally left blank")
else:
for i in seq:
...

Any adhoc, confusing syntax someone may imagine to add, would go to the
same "DO NOT USE" category. So, I pray to van Rossum's answer that
something like that will never be added to the language. (Which is
hard to hang hopes on, given all the mess added recently.)

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/GMSZRJP2VQDHK4C2ITWL2DZO7P6JMVY3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Paul Sokolovsky]

Hello,

On Wed, 22 Jul 2020 09:45:31 +1000
Steven D'Aprano  wrote:

> On Tue, Jul 21, 2020 at 10:07:47PM +0100, Barry wrote:
> 
> > 1. Because that not what else mean today. Its elif never looped.  
> 
> 
> py> for x in [1,2]:  
> ... print("inside loop")
> ... else:
> ... print("elif never looped")
> ... 
> inside loop
> inside loop
> elif never looped
> 
> 
> This is why I have long-argued that the keyword here should be *then* 
> not else. The semantics are that the loop executes, *then* the
> following "else" block executes, 

But no, loop executes, *or else* the following "else" block
executes ;-). That's the logic of founding fathers. After one grasped
that logic, one comes to appreciate a weird beauty of it. The verdict
remains the same though: "Do Not Use".

> unless we have transferred control
> elsewhere by jumping out of the loop with return, raise, or break.
> 
> Mistaking the semantics for "if never looped" is a very common
> mistake. Welcome to the club :-)
> 
> 
> -- 
> Steven

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/ZQLNLIHMYY6THKHWVDAOPI6M5YV5OPCJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Christopher Barker]

how about:

for something in some_iterable:
some_stuff_with_maybe_a_break
else if not break:
something_more

No new keywords :-)

or:

for something in some_iterable:
some_stuff_with_maybe_a_break
else:  # if not break:
something_more

and no changes needed to Python!

I may actually start doing that myself ...

As for the "loop didn't run at all" case: Does anyone find a need for that?
Personally, I've found that everytime I do some kind of check for an empty
iterable before a loop, it was totally unnecessary.

A for loop means: "Do this stuff to all the items in this iterable."

Most of the time, if there's nothing there, you don't need to do the stuff,
and that's that.

-CHB






On Tue, Jul 21, 2020 at 5:28 PM Ethan Furman  wrote:

> On 7/20/20 7:34 AM, Barry Scott wrote:
>
> > To avoid the ambiguity of `if` after `for` why not follow `for` with
> `elif`?
> >
> > for x in ...:
> > ...
> >
> > elif break:
> > # break was called
> > elif not break:
> > # looped at least once and break not used
> > elif pass:
> > # same as else today
> > # loop'ed no times
> >
> > (I always have to think what else means after a for).
>
> Keep thinking... ;)
>
> `else` today /does not/ mean "loop'ed no times".  To copy Steven
> D'Aprano's example:
>
> > py> for x in [1,2]:
> > ... print("inside loop")
> > ... else:
> > ... print("elif never looped")
> > ...
> > inside loop
> > inside loop
> > elif never looped
>
> > Mistaking the semantics for "if never looped" is a very common mistake.
> > Welcome to the club :-)
>
> --
> ~Ethan~
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UZFPLNUXQHUAGMCSBSB4RQPSJ7TBH36Z/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/F64OSLOXV35CEKJ2X5AX37P4L4G2GHWO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Eric V. Smith]

On 7/21/2020 7:36 PM, Rob Cliffe wrote:



On 21/07/2020 21:00, Eric V. Smith wrote:

f-strings call PyObject_Repr directly, without going through builtins.

If we added !p as described here, we'd need to call import every time 
we execute !p, because we don't know if it's been imported yet. At 
runtime, we'd call "pformat()" via sys.modules['pprint'] after the 
import. That could of course be monkey patched.


But I'm still not sure this is a good idea. I can't find the issue on 
bpo where this was mentioned, but some of the issues that spring to 
mind are:


- Most pprint output is multi-line. Is that a good thing with f-strings?
Why not?  f-strings (as of course you know) can already contain 
multiple lines, even if the usage is not frequent.  ISTM this 
objection has no substance.
But with pprint, it's not unusual, it's common. That feels qualitatively 
different to me.


- How to handle parameters to pprint.pformat()?
This doesn't seem insurmountable.  IIUC the relevant parameters are 
indent, width, depth, compact, sort_dicts.  They could be added after 
`!p` separated by some separator - let's say comma for the sake of 
argument - with absent parameters taking the default values.  So e.g.

    !p2        # means indent=2
    !p,60    # means width=60.  Etc.
If the pformat API were ever changed, adding extra parameters would 
not cause backward incompatibility.  Removing parameters or changing 
their order would, but both seem extremely unlikely to me (YMMV) and I 
expect users of !p could live with that.


I can't support embedding all of these params in the format string. 
Format strings are hard enough to understand as it is.


At this point, you'd be better off with calling pprint.pformat() 
explicitely.


f'value={pprint.pformat(value, indent=2, width=60)}'

I might be able to get behind sort of a "pprint context", like a decimal 
context, with a context manager to specify it.




- Is pprint.pformat() extensible enough? Can an object control how it 
is pretty printed?
I'm not sure if I fully understand this objection.  It seems to be 
suggesting a deficiency in the current pprint.pformat.  The proposal 
would not change anything here.
I'm not super familiar with pprint, but IIRC an object can't specify its 
own formatting, can it? If I wrote a dict-like object, not inheriting 
from dict, and I wanted to control how it's pprint'ed, can I do that?


I'm sure there are others.

Could you specify.?

I'll try and find the issues to see what else Raymond and I already wrote.


I'm not saying I'm +1 on the proposal.  Just that there don't seem to 
be any insurmountable obstacles to it.  My greatest unease is an 
implicit import.  Are there other areas of Python where this happens?


I'm not sure. But this part doesn't really bother me. Maybe it should, 
and it would be another reason not to move forward!


Eric

As I've said before, I'd prefer a revamped "pretty formatting" 
library, probably using singledispatch for extensibility. But even 
with that, issues like parameterizing the output remain.


Eric



On Tue, Jul 21, 2020 at 8:04 PM Rob Cliffe via Python-ideas 
mailto:python-ideas@python.org>> wrote:


That seems like a nice idea, but what would happen if pprint had
not
been imported?  NameError?
Rob Cliffe

On 16/07/2020 05:34, Charles Machalow wrote:
> Right now in str.format(), we have !s, !r, and !a to allow us
to call str(), repr(), and ascii() respectively on the given
expression.
>
> I'm proposing that we add a !p conversion to have
pprint.pformat() be called to convert the given expression to a
'pretty' string.
>
> Calling
> ```
> print(f"My dict: {d!p}")
> ```
>
> is a lot more concise than:
>
> ```
> import pprint
> print(f"My dict: {pprint.pformat(d)}")
> ```
>
> We may even be able to have a static attribute stored to
change the various default kwargs of pprint.pformat().


___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/UUZLIVS67PU552IMRNP6JBNC5LHACVQ2/
Code of Conduct:http://python.org/psf/codeofconduct/


___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/I5PLO5FUYMX45EXEENZF56PAPYJBC7QM/
Code of Conduct:http://python.org/psf/codeofconduct/


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Ethan Furman]

On 7/20/20 7:34 AM, Barry Scott wrote:


To avoid the ambiguity of `if` after `for` why not follow `for` with `elif`?

for x in ...:
...

elif break:
# break was called
elif not break:
# looped at least once and break not used
elif pass:
# same as else today
# loop'ed no times

(I always have to think what else means after a for).


Keep thinking... ;)

`else` today /does not/ mean "loop'ed no times".  To copy Steven 
D'Aprano's example:



py> for x in [1,2]:
... print("inside loop")
... else:
... print("elif never looped")
... 
inside loop

inside loop
elif never looped


Mistaking the semantics for "if never looped" is a very common mistake. 
Welcome to the club :-)


--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UZFPLNUXQHUAGMCSBSB4RQPSJ7TBH36Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Guido van Rossum]

A philosophical problem with this is proposal is that it takes a notation
that is processed by the bytecode compiler and makes it dependent on user
code to be imported from the stdlib. We only do that in rare cases — IIRC
the only other case is ‘import’ calling ‘__import__()’. This reversal of
dependency is problematic because it means that core, built-in
functionality could be broken by something a user could inadvertently
change in the file system.

Another problem I have is that pprint is kind of a second-class citizen.
It’s not all that much cared for by core devs I believe, and you can’t
extend it by adding a special method to a class — you have to subclass the
PrettyPrinter class.

All in all I don’t think this is a direction we should take.

— Guido
-- 
--Guido (mobile)
___
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/ULY3VUSNDLOAUU7DASM7ILXD5ZZNZH6T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Rob Cliffe via Python-ideas]

On 22/07/2020 00:29, MRAB wrote:

On 2020-07-22 00:02, Rob Cliffe via Python-ideas wrote:

On 21/07/2020 22:07, Barry wrote:
On 21 Jul 2020, at 18:47, Rob Cliffe via Python-ideas 
 wrote:


On Mon, Jul 20, 2020 at 03:22 Jonathan Fine > wrote:


    This is a continuation of my previous post to this thread.

    Python's FOR ... ELSE ... , Raymond Hettinger has told us, has
    origins in some ideas of Don Knuth.


That’s news to me (both that it’s due to Knuth and that Raymond 
said so). I invented it without awareness of prior art, by 
reasoning about the similarity between IF and WHILE (FOR followed 
from WHILE).


—Guido

See Raymond's video "Transforming Code into Beautiful, Idiomatic 
Python" at

https://www.youtube.com/watch?v=OSGv2VnC0go
from 15 min 50 sec to 18 min 57 sec.

On 20/07/2020 15:42, Guido van Rossum wrote:
Also, let me be clear that this feature will never be added to the 
language.


With respect, that seems pretty dogmatic, given that for...else is 
one of the most confusing features of Python.
What would be so terrible about allowing, at minimum, `if not 
break:' as a synonym for 'else:'?


1. Because that not what else mean today. Its elif never looped.
2. Because if after for is confusing. I can get behind elif as after 
for it  pull work.
I'm sorry, of the above two points I don't understand 1. at all, and 
I only half understand 2.  Please could you rephrase more clearly for 
an idiot like me.:-)
But as to `if` after `for` being confusing, are you seriously saying 
that `else` after `for` is *less* confusing?


'if' introduces a statement structure, 'else' doesn't. Having 'if' 
sometimes continue a statement structure (a loop) would be more 
confusing.


The current rule: 'else' continues the 'if' or loop structure.

The new rule: 'if' continues a preceding loop structure if it's 
followed by 'break', else it's the start of an 'if' structure.


Which rule is simpler?

"Simpler" doesn't always equate to "easier to understand".
Which is more *intuitive*, for...else or for...if [not] break?
And if we allowed for...if [not] break... else   - now there's an 
example of 'else' after 'for' that anyone could grok.

___
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/OCYFEFFPVEQVP7LKY6DMB3KEDRKCJJ7M/

Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QU3UPVXQUAYWASTRAFTFVGLGBSI3QZQD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Steven D'Aprano]

On Tue, Jul 21, 2020 at 10:07:47PM +0100, Barry wrote:

> 1. Because that not what else mean today. Its elif never looped.


py> for x in [1,2]:
... print("inside loop")
... else:
... print("elif never looped")
... 
inside loop
inside loop
elif never looped


This is why I have long-argued that the keyword here should be *then* 
not else. The semantics are that the loop executes, *then* the following 
"else" block executes, unless we have transferred control elsewhere by 
jumping out of the loop with return, raise, or break.

Mistaking the semantics for "if never looped" is a very common mistake. 
Welcome to the club :-)


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/J57G33FOMK77FJX275JUT4U2A54N43Y5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Steven D'Aprano]

Relevant to Jonathan's suggestion for a "key-object", Marco has been 
performing some experiments on an immutable dict:

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


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HWX7WMO2F5JL25K2D47BF5OMCUPIV2YP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Rob Cliffe via Python-ideas]

On 21/07/2020 21:00, Eric V. Smith wrote:

On 7/21/2020 2:54 PM, Alex Hall wrote:

It should do the import for you. As was proposed:

```
print(f"My dict: {d!p}")
```

should be equivalent to

```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```

The import should happen in the same scope. Modifying the global 
namespace could be confusing.


A quick test shows that adding `import pprint` to 
`pprint.pformat({1:2})` slows things down by about 4% on my machine, 
which I don't think is worth being concerned about. If the dict has 
100 elements, the difference becomes too small to measure.
My first instinct is that monkeypatching the pprint module should 
affect !p, but I see that monkeypatching builtins.repr doesn't affect 
!r, so I'm not sure.

f-strings call PyObject_Repr directly, without going through builtins.

If we added !p as described here, we'd need to call import every time 
we execute !p, because we don't know if it's been imported yet. At 
runtime, we'd call "pformat()" via sys.modules['pprint'] after the 
import. That could of course be monkey patched.


But I'm still not sure this is a good idea. I can't find the issue on 
bpo where this was mentioned, but some of the issues that spring to 
mind are:


- Most pprint output is multi-line. Is that a good thing with f-strings?
Why not?  f-strings (as of course you know) can already contain multiple 
lines, even if the usage is not frequent.  ISTM this objection has no 
substance.


- How to handle parameters to pprint.pformat()?
This doesn't seem insurmountable.  IIUC the relevant parameters are 
indent, width, depth, compact, sort_dicts.  They could be added after 
`!p` separated by some separator - let's say comma for the sake of 
argument - with absent parameters taking the default values.  So e.g.

    !p2        # means indent=2
    !p,60    # means width=60.  Etc.
If the pformat API were ever changed, adding extra parameters would not 
cause backward incompatibility.  Removing parameters or changing their 
order would, but both seem extremely unlikely to me (YMMV) and I expect 
users of !p could live with that.


- Is pprint.pformat() extensible enough? Can an object control how it 
is pretty printed?
I'm not sure if I fully understand this objection.  It seems to be 
suggesting a deficiency in the current pprint.pformat.  The proposal 
would not change anything here.


I'm sure there are others.

Could you specify.?

I'm not saying I'm +1 on the proposal.  Just that there don't seem to be 
any insurmountable obstacles to it.  My greatest unease is an implicit 
import.  Are there other areas of Python where this happens?
As I've said before, I'd prefer a revamped "pretty formatting" 
library, probably using singledispatch for extensibility. But even 
with that, issues like parameterizing the output remain.


Eric



On Tue, Jul 21, 2020 at 8:04 PM Rob Cliffe via Python-ideas 
mailto:python-ideas@python.org>> wrote:


That seems like a nice idea, but what would happen if pprint had not
been imported?  NameError?
Rob Cliffe

On 16/07/2020 05:34, Charles Machalow wrote:
> Right now in str.format(), we have !s, !r, and !a to allow us
to call str(), repr(), and ascii() respectively on the given
expression.
>
> I'm proposing that we add a !p conversion to have
pprint.pformat() be called to convert the given expression to a
'pretty' string.
>
> Calling
> ```
> print(f"My dict: {d!p}")
> ```
>
> is a lot more concise than:
>
> ```
> import pprint
> print(f"My dict: {pprint.pformat(d)}")
> ```
>
> We may even be able to have a static attribute stored to change
the various default kwargs of pprint.pformat().


___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/UUZLIVS67PU552IMRNP6JBNC5LHACVQ2/
Code of Conduct:http://python.org/psf/codeofconduct/


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I5PLO5FUYMX45EXEENZF56PAPYJBC7QM/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R6RELE3VBBNWW7CN3H6CFFDXIITUQINJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[MRAB]

On 2020-07-22 00:02, Rob Cliffe via Python-ideas wrote:

On 21/07/2020 22:07, Barry wrote:
On 21 Jul 2020, at 18:47, Rob Cliffe via Python-ideas 
 wrote:


On Mon, Jul 20, 2020 at 03:22 Jonathan Fine > wrote:


This is a continuation of my previous post to this thread.

Python's FOR ... ELSE ... , Raymond Hettinger has told us, has
origins in some ideas of Don Knuth.


That’s news to me (both that it’s due to Knuth and that Raymond said 
so). I invented it without awareness of prior art, by reasoning about 
the similarity between IF and WHILE (FOR followed from WHILE).


—Guido

See Raymond's video "Transforming Code into Beautiful, Idiomatic 
Python" at

https://www.youtube.com/watch?v=OSGv2VnC0go
from 15 min 50 sec to 18 min 57 sec.

On 20/07/2020 15:42, Guido van Rossum wrote:
Also, let me be clear that this feature will never be added to the 
language.


With respect, that seems pretty dogmatic, given that for...else is 
one of the most confusing features of Python.
What would be so terrible about allowing, at minimum, `if not break:' 
as a synonym for 'else:'?


1. Because that not what else mean today. Its elif never looped.
2. Because if after for is confusing. I can get behind elif as after 
for it  pull work.
I'm sorry, of the above two points I don't understand 1. at all, and I 
only half understand 2.  Please could you rephrase more clearly for an 
idiot like me.:-)
But as to `if` after `for` being confusing, are you seriously saying 
that `else` after `for` is *less* confusing?


'if' introduces a statement structure, 'else' doesn't. Having 'if' 
sometimes continue a statement structure (a loop) would be more confusing.


The current rule: 'else' continues the 'if' or loop structure.

The new rule: 'if' continues a preceding loop structure if it's followed 
by 'break', else it's the start of an 'if' structure.


Which rule is simpler?
___
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/OCYFEFFPVEQVP7LKY6DMB3KEDRKCJJ7M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Rob Cliffe via Python-ideas]

On 21/07/2020 22:07, Barry wrote:



On 21 Jul 2020, at 18:47, Rob Cliffe via Python-ideas 
 wrote:



On Mon, Jul 20, 2020 at 03:22 Jonathan Fine > wrote:


This is a continuation of my previous post to this thread.

Python's FOR ... ELSE ... , Raymond Hettinger has told us, has
origins in some ideas of Don Knuth.


That’s news to me (both that it’s due to Knuth and that Raymond said 
so). I invented it without awareness of prior art, by reasoning about 
the similarity between IF and WHILE (FOR followed from WHILE).


—Guido

See Raymond's video "Transforming Code into Beautiful, Idiomatic 
Python" at

https://www.youtube.com/watch?v=OSGv2VnC0go
from 15 min 50 sec to 18 min 57 sec.

On 20/07/2020 15:42, Guido van Rossum wrote:
Also, let me be clear that this feature will never be added to the 
language.


With respect, that seems pretty dogmatic, given that for...else is 
one of the most confusing features of Python.
What would be so terrible about allowing, at minimum, `if not break:' 
as a synonym for 'else:'?


1. Because that not what else mean today. Its elif never looped.
2. Because if after for is confusing. I can get behind elif as after 
for it  pull work.
I'm sorry, of the above two points I don't understand 1. at all, and I 
only half understand 2.  Please could you rephrase more clearly for an 
idiot like me.:-)
But as to `if` after `for` being confusing, are you seriously saying 
that `else` after `for` is *less* confusing?


Barry



Best wishes
Rob Cliffe
___
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/4H5SMUSIHBOWJUIAS7WO2BHEHJ5WYQKA/

Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LKVT55WSEVH2EINWGKQUKHYAE5JQGQ2H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Eric V. Smith]

On 7/21/2020 4:59 PM, Rob Cliffe via Python-ideas wrote:



On 21/07/2020 19:54, Alex Hall wrote:

It should do the import for you. As was proposed:

```
print(f"My dict: {d!p}")
```

should be equivalent to

```
import pprint
print(f"My dict: {pprint.pformat(d)}")

You're right, I didn't read it carefully enough.

```

The import should happen in the same scope. Modifying the global 
namespace could be confusing.

You're right again.  It could still break code like this:

from pprint import pprint
...
def myfunc():
    # Code modified to use !p here
    pprint(something) # Oops, pprint is now a module, not a function

unless the import could actually be local to the f-string itself, not 
the surrounding scope
(perhaps similar to the way a list comprehension is implemented as a 
function with its own scope).


I don't totally understand these matters, so I may have got something 
wrong.


You don't need to go through globals, locals, etc. You can do the 
equivalent of:


>>> import pprint
>>> import sys
>>> pprint = 3
>>> sys.modules['pprint'].pprint('hello')
'hello'

Except that "sys" wouldn't be a local/global, either. But of course you 
could still monkeypatch pprint and break this code. There are a million 
ways to break code, I wouldn't worry about how the interpreter would get 
access to the pprint module. Instead, I'd worry about the more troubling 
issues which I raised in an earlier email. Those are the ones that are 
likely to stop this proposal.


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

[Python-ideas] Experimenting with dict performance, and an immutable dict

[Marco Sulla]

Let me first say that the code and discussion, as per title, is also about
possible performance improvements to the dict base type.

TL;DR I implemented a frozendict using CPython 3.9 code. It seems that an
immutable dict *could* be faster than dict in some cases. Furthermore, some
optimization could be applied to dict too.

Long explaining:

Since now I have some time, I decided to experiment a little with the
creation of an immutable dict in Python.

Unluckily, I started this experiment many months ago, so the CPython code I
used is old. Maybe some or all of my considerations are outdated.

Initially, I wrote a quick and dirty implementation:
https://github.com/Marco-Sulla/cpython/commit/fde4e6d236b19636063f8afedea8c50278205334

The code was very simple, and the performance was identical to dict. So in
theory, adding a frozendict to CPython is not hard. But there's more.

After the first implementation, I started to try to improve the performance
of frozendict. The result of the improvements are here:

https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.txt

For benchmarks, I used simply timeit, with autorange and repeat and, as
suggested in the module documentation, I got the minimum of the results.
Here is the code:

https://github.com/Marco-Sulla/cpython/blob/master/frozendict/test/bench.py

I have not tested with an optimized build, since optimization data is
collected using the unit tests, and I didn't write tests for frozendict in
the official CPython test framework.

The tests and benchmarks were done using CPython 3.9a0. CPU and other pc
resources were not restricted using pyperf or similar tools, to see the
"real" speed. CPython was compiled using gcc and g++.

In benchmarks, I compared methods and operators using dict and frozendict.
The benchmark uses dicts with all integers and dicts with all strings.
Furthermore, I tested dicts with size 8 (the most optimized size in
CPython) and 1000 elements (maybe too much, but I wanted to see how they
perform with a high number of elements).

Every benchmark has a line in the output. The Name describes the
benchmarked method, operator or code snippet. Size is the size of the dict,
8 or 1000. Keys are the keys type, str or int. Type is the dictionary type,
dict or frozendict.

In Name, the "o" represents the object itself (dict or frozendict). "d", in
benchmark with dict, is "o"; in benchmarks with frozendict is an equivalent
instance of type dict.

Some consideration:

1. frozendict is very fast, as expected, at copying. But it's also faster
at creation, using a (not frozen) dict, kwargs or a sequence2. Speedups
range from 20% to 45%.
2. frozendict is also a bit faster when you iterate over it, especially
over values, where is ~15% faster
3. hash seems really fast, but this is because it's cached the first time
hash() is invoked
4. where frozendict is slower is when you unpickle it and with fromkeys and
repr. This is because I wrote a very naif implementation of these methods,
without optimizing them. The other methods have a comparable speed.

Here is the code:
https://github.com/Marco-Sulla/cpython

Here is the diff between the CPython code and my commits:
https://github.com/python/cpython/compare/master...Marco-Sulla:master

About code

I coded the implementation doing a simple copy/paste of the existing dict
functions, modifying their code and renaming them. This way I'm sure dict
continues to work as before, and I can compare the speed gain.

Some of the optimization I adopted can be implemented in `dict` too. For
example, instead of creating an empty dict and resizing it, I create it
with the "maximum" size and I fill it. It seems to work, even if I did not
explore the possibility that a mutable object can change while a frozendict
creation is in progress.

Some problems with optimizing dict and maintaining a frozendict:

1. duplication of code. To gain a significant boost, I had to copy and
paste a lot of code. Functions can be remerged again, but maybe the speedup
will be reduced.
2. split vs combined dicts. As I wrote, split dicts seem to be faster in
reading than combined dicts. For example, iterating over values is faster
with a split dict, as expected.
But writing was not tested; furthermore, some of the optimizations can be
adopted for dicts too, so the convenience of a split table can be lowered.
dict continues to maintain both split and combined tables, so this could be
not a problem. But the code could be less and more fast if only a table
layout is supported
3. the CPython code I used is old, so some of the improvements I adopted
could be already implemented

About frozendict

Apart the considerations done in the [PEP 416](
https://www.python.org/dev/peps/pep-0416/), that was rejected since there
was little gain from its implementation, I think that frozendict can be
useful as a substitute of MappingProxyType, that is really slow.
MappingProxyType is not much used, but it's present in critical parts of
CPython code, 

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Rob Cliffe via Python-ideas]

On 21/07/2020 19:54, Alex Hall wrote:

It should do the import for you. As was proposed:

```
print(f"My dict: {d!p}")
```

should be equivalent to

```
import pprint
print(f"My dict: {pprint.pformat(d)}")

You're right, I didn't read it carefully enough.

```

The import should happen in the same scope. Modifying the global 
namespace could be confusing.

You're right again.  It could still break code like this:

from pprint import pprint
...
def myfunc():
    # Code modified to use !p here
    pprint(something) # Oops, pprint is now a module, not a function

unless the import could actually be local to the f-string itself, not 
the surrounding scope
(perhaps similar to the way a list comprehension is implemented as a 
function with its own scope).


I don't totally understand these matters, so I may have got something wrong.
___
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/44CJYSVFRU4K5XG54T2TMDCMVBHEJRCQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Barry]

> On 21 Jul 2020, at 18:47, Rob Cliffe via Python-ideas 
>  wrote:
> 
> 
> On Mon, Jul 20, 2020 at 03:22 Jonathan Fine  wrote:
>> This is a continuation of my previous post to this thread.
>> 
>> Python's FOR ... ELSE ... , Raymond Hettinger has told us, has origins in 
>> some ideas of Don Knuth. 
> 
> That’s news to me (both that it’s due to Knuth and that Raymond said so). I 
> invented it without awareness of prior art, by reasoning about the similarity 
> between IF and WHILE (FOR followed from WHILE).
> 
> —Guido
> 
> See Raymond's video "Transforming Code into Beautiful, Idiomatic Python" at
> https://www.youtube.com/watch?v=OSGv2VnC0go
> from 15 min 50 sec to 18 min 57 sec.
> 
> On 20/07/2020 15:42, Guido van Rossum wrote:
>> Also, let me be clear that this feature will never be added to the language.
>> 
> With respect, that seems pretty dogmatic, given that for...else is one of the 
> most confusing features of Python.
> What would be so terrible about allowing, at minimum, `if not break:' as a 
> synonym for 'else:'?

1. Because that not what else mean today. Its elif never looped.
2. Because if after for is confusing. I can get behind elif as after for it  
pull work.

Barry

> 
> Best wishes
> Rob Cliffe
> ___
> 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/4H5SMUSIHBOWJUIAS7WO2BHEHJ5WYQKA/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HAM3ESIGTLEN4P4A7RCYBQAICV73P7H3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Eric V. Smith]

On 7/21/2020 2:54 PM, Alex Hall wrote:

It should do the import for you. As was proposed:

```
print(f"My dict: {d!p}")
```

should be equivalent to

```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```

The import should happen in the same scope. Modifying the global 
namespace could be confusing.


A quick test shows that adding `import pprint` to 
`pprint.pformat({1:2})` slows things down by about 4% on my machine, 
which I don't think is worth being concerned about. If the dict has 
100 elements, the difference becomes too small to measure.
My first instinct is that monkeypatching the pprint module should 
affect !p, but I see that monkeypatching builtins.repr doesn't affect 
!r, so I'm not sure.

f-strings call PyObject_Repr directly, without going through builtins.

If we added !p as described here, we'd need to call import every time we 
execute !p, because we don't know if it's been imported yet. At runtime, 
we'd call "pformat()" via sys.modules['pprint'] after the import. That 
could of course be monkey patched.


But I'm still not sure this is a good idea. I can't find the issue on 
bpo where this was mentioned, but some of the issues that spring to mind 
are:


- Most pprint output is multi-line. Is that a good thing with f-strings?

- How to handle parameters to pprint.pformat()?

- Is pprint.pformat() extensible enough? Can an object control how it is 
pretty printed?


I'm sure there are others. As I've said before, I'd prefer a revamped 
"pretty formatting" library, probably using singledispatch for 
extensibility. But even with that, issues like parameterizing the output 
remain.


Eric



On Tue, Jul 21, 2020 at 8:04 PM Rob Cliffe via Python-ideas 
mailto:python-ideas@python.org>> wrote:


That seems like a nice idea, but what would happen if pprint had not
been imported?  NameError?
Rob Cliffe

On 16/07/2020 05:34, Charles Machalow wrote:
> Right now in str.format(), we have !s, !r, and !a to allow us to
call str(), repr(), and ascii() respectively on the given expression.
>
> I'm proposing that we add a !p conversion to have
pprint.pformat() be called to convert the given expression to a
'pretty' string.
>
> Calling
> ```
> print(f"My dict: {d!p}")
> ```
>
> is a lot more concise than:
>
> ```
> import pprint
> print(f"My dict: {pprint.pformat(d)}")
> ```
>
> We may even be able to have a static attribute stored to change
the various default kwargs of pprint.pformat().


___
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/UUZLIVS67PU552IMRNP6JBNC5LHACVQ2/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I5PLO5FUYMX45EXEENZF56PAPYJBC7QM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Alex Hall]

It should do the import for you. As was proposed:

```
print(f"My dict: {d!p}")
```

should be equivalent to

```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```

The import should happen in the same scope. Modifying the global namespace
could be confusing.

A quick test shows that adding `import pprint` to `pprint.pformat({1:2})`
slows things down by about 4% on my machine, which I don't think is worth
being concerned about. If the dict has 100 elements, the difference becomes
too small to measure.

My first instinct is that monkeypatching the pprint module should affect
!p, but I see that monkeypatching builtins.repr doesn't affect !r, so I'm
not sure.

On Tue, Jul 21, 2020 at 8:04 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

> That seems like a nice idea, but what would happen if pprint had not
> been imported?  NameError?
> Rob Cliffe
>
> On 16/07/2020 05:34, Charles Machalow wrote:
> > Right now in str.format(), we have !s, !r, and !a to allow us to call
> str(), repr(), and ascii() respectively on the given expression.
> >
> > I'm proposing that we add a !p conversion to have pprint.pformat() be
> called to convert the given expression to a 'pretty' string.
> >
> > Calling
> > ```
> > print(f"My dict: {d!p}")
> > ```
> >
> > is a lot more concise than:
> >
> > ```
> > import pprint
> > print(f"My dict: {pprint.pformat(d)}")
> > ```
> >
> > We may even be able to have a static attribute stored to change the
> various default kwargs of pprint.pformat().
>
___
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/UUZLIVS67PU552IMRNP6JBNC5LHACVQ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Stephan Hoyer]

On Tue, Jul 21, 2020 at 9:15 AM Sebastian Berg 
wrote:

> On Mon, 2020-07-20 at 22:27 -0700, Christopher Barker wrote:
> > On Mon, Jul 20, 2020 at 3:17 AM Rhodri James 
> > wrote:
> >
> > > Ironically that example pushes me back to -1.  It may look a lot
> > > like
> > > xarray and pandas working, but that just means it should be in
> > > xarray
> > > and/or pandas.
> >
> > after following most of this discussion, I'm still not sure what we'd
> > get
> > with keywords in indexing.
> >
> > But I do think it would be nice of we could use slice syntax in other
> > places. That would allow things like xarray and pandas to use slices
> > in
> > regular function calls. here's an example from the xarray docs:
> >
> >  da.isel(space=0, time=slice(None, 2))
> >
> > wouldn't that be nice as:
> >
> > da.isel(space=0, time=:2)
> >
> > or:
> >
> > da.sel(time=slice("2000-01-01", "2000-01-02"))
> >
> > could be:
> >
> > da.sel(time="2000-01-01":"2000-01-02")
> >
> > As far as I can tell, slicing syntax is currently a syntax error in
> > these
> > cases, and any others I thought to test.
> >
> > Is there a reason to not allow syntax for creating a slice object to
> > be
> > used anywhere (Or more places, anyway)?
> >
> > By the way, I just noticed this note in the xarray docs:
> >
> > """Note: We would love to be able to do indexing with labeled
> > dimension
> > names inside brackets, but unfortunately, Python does yet not support
> > indexing with keyword arguments like da[space=0]
> > """
>
> This would be the thing I would think of first when indexing with
> keywords.  But, there are a few points about named dimensions:
>
> First, using it for named dimensions, means you don't actually need to
> mix it with normal tuple indexing, mixing both seems rather confusing?
> (I cannot think of how to interpret it)
>
> Second,  using keyword arguments for indexing `mode=` or `method=`
> switches as Stephan Hoyer mentioned as well seems neat.  But I am
> worried that the two potential uses clash way too much and my gut
> feeling is to prefer the labeled use (which is why I would be extremely
> hesitant to add mode-switching things to NumPy or pandas).  I might
> rather prefer mode switching to be spelled as::
>
> temperature.loc(method="nearest")[longitude=longs, latitude=lats]
>
> even if that has to create an intermediate indexer object (twice, since
> `.loc` here is also an index helper object).
> (This means axis labels must be strings, that is likely no issue, but
> should maybe be mentioned.)
>
> Thus, for most containers, my knee jerk reaction would be to discourage
> the use of keywords in indexing for mode switching.  But some of the
> use-cases seemed more like class factories, for which there is no clash
> of these two concepts/applications.
>
> That said, labeled dimensions/axis do seem like nice syntax with quite
> a bit of potential to me, even with 3 dimensions, remembering whether
> your coordinate order was x,y,z or z,x,y or z,y,x can be annoying
> (especially if you mix in a 1-D dataset with only a z axis).
>

For what it's worth, I (as the original author of xarray) totally agree
with both Sebastian and Christopher. For indexing labeled arrays, the most
compelling use-case is cleaner syntax for creating slice() objects along
with keyword arguments for dimension names.

I don't particularly care whether that's spelled with [] or (), e.g.,
da.sel(time="2000-01-01":"2000-01-02")
or
da.loc[time="2000-01-01":"2000-01-02"]
neither of which is currently valid syntax.

The further advantages of supporting keyword arguments in
__getitem__/__setitem__ would be:
1. We wouldn't need separate methods for positional vs keyword argument
indexing. Currently, xarray has both .loc[] and .sel().
2. We could support matching syntax with keyword arguments in assignment.
This is mostly relevant for inexperienced Python users, who will try
something like "da.sel(x=0) = value" and encounter a SyntaxError. (This
does come up with some regularity, because xarray's target audience
includes scientists who often aren't experienced programmers.
___
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/P3OYHPIML7EO7JTE4T4MQ6QF36F4VA36/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[David Mertz]

On Tue, Jul 21, 2020, 12:14 PM Sebastian Berg

> First, using it for named dimensions, means you don't actually need to
> mix it with normal tuple indexing, mixing both seems rather confusing?
>
> temperature.loc(method="nearest")[longitude=longs, latitude=lats]
>

I probably don't disagree on the API for xarray or similar library. But
that choice would be up to the library, not Python developers. Whatever the
way keyword argument are passed to .__getitem__()[*], they are available
for the class to do whatever it likes with them.

[*] In my opinion, passing the keyword argument using anything other than
the standard **kws style sounds crazy. We have perfectly good ways to do
that for every other function or method. Don't invent something new and
different that only works with .__getitem__().
___
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/SA5FXO3R5LC52EKKABFH7PBXZEKP53CD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Rob Cliffe via Python-ideas]

That seems like a nice idea, but what would happen if pprint had not 
been imported?  NameError?

Rob Cliffe

On 16/07/2020 05:34, Charles Machalow wrote:

Right now in str.format(), we have !s, !r, and !a to allow us to call str(), 
repr(), and ascii() respectively on the given expression.

I'm proposing that we add a !p conversion to have pprint.pformat() be called to 
convert the given expression to a 'pretty' string.

Calling
```
print(f"My dict: {d!p}")
```

is a lot more concise than:

```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```

We may even be able to have a static attribute stored to change the various 
default kwargs of pprint.pformat().
___
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/LNQEA6IYBS5B7NMGC3P4JFPCSR33W4C6/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YWGNW5LVGUIN5ZGAQNKR325VOEYD454L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Rob Cliffe via Python-ideas]

On Mon, Jul 20, 2020 at 03:22 Jonathan Fine > wrote:


   This is a continuation of my previous post to this thread.

   Python's FOR ... ELSE ... , Raymond Hettinger has told us, has
   origins in some ideas of Don Knuth.


That’s news to me (both that it’s due to Knuth and that Raymond said 
so). I invented it without awareness of prior art, by reasoning about 
the similarity between IF and WHILE (FOR followed from WHILE).


—Guido

See Raymond's video "Transforming Code into Beautiful, Idiomatic Python" at
https://www.youtube.com/watch?v=OSGv2VnC0go
from 15 min 50 sec to 18 min 57 sec.

On 20/07/2020 15:42, Guido van Rossum wrote:
Also, let me be clear that this feature will never be added to the 
language.


With respect, that seems pretty dogmatic, given that for...else is one 
of the most confusing features of Python.
What would be so terrible about allowing, at minimum, `if not break:' as 
a synonym for 'else:'?


Best wishes
Rob Cliffe
___
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/4H5SMUSIHBOWJUIAS7WO2BHEHJ5WYQKA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Rob Cliffe via Python-ideas]

On 20/07/2020 09:56, Alex Hall wrote:
On Mon, Jul 20, 2020 at 10:36 AM Rob Cliffe via Python-ideas 
mailto:python-ideas@python.org>> wrote:


May I repeat:  Spelling 'if break:' and 'if not break:' rather
than say
'on_break:' etc. would avoid adding new keywords.

I don't know what to do about the zero iterations case, though.


It could be that if `break` appears somewhere that an expression is 
expected, it becomes an expression with the value 0 or 1 (or False or 
True) to indicate the number of breaks that happened in the previous 
loop, and similarly some other bit of code involving keywords can 
become the number of iterations of the previous loop. This could be 
represented by `for`, `len(for)`, `pass`, etc. So one might write:


```
for x in ...:
    ...
if not pass:
    ...
elif pass == 1:
    ...
else:
    ...
```

`break' becoming an expression is fine by me.

But detecting the number of iterations (however it's spelt) might be tricky.
Always counting the number of iterations would slow down *every* 
for/while loop - surely unacceptable.
So the compilation process must only incorporate this loop-counting when 
the loop is followed (after 100 lines of code??) by a reference to the 
loop count.


Another way would be for the first iteration (i.e. the first call of 
`next') to be coded separately (in the bytecode).  If the first call 
does not raise StopIteration, it could set a flag meaning "at least 1 
iteration occurred",  But this would bloat the code, and again doesn't 
seem like a great idea if it applies to *every* for/while loop.


Therefore: I suggest that the proposal should be modified to just detect 
break or no break.  That's already progress.  And if in future someone 
thinks of a brilliant way of detecting zero (or N) iterations,  that can 
be added later.
___
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/VGHR46K4Y4DC4RN6W32ZRNBAP7ND7PO2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Rob Cliffe via Python-ideas]

On 14/07/2020 04:56, Random832 wrote:

On 11/07/2020 06:22, Олег Комлев wrote:

ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead:

if COND:
   ...
[elif COND:
   ...]
[else:
   ...]

This IF-clause like must be immediately after FOR- or WHILE-cycle (only
comment allowed between). It looks like a regular IF, but COND is
special.

On Sun, Jul 12, 2020, at 00:16, Rob Cliffe via Python-ideas wrote:

  Something to consider: Would it be legal to mix these CONDs with other
conditions in the 'elif' chain? E.g.
  if break:
  ...
  elif x > 0:
  ...
  elif finally:


What if "instead of a special kind of if clause that can only be placed after a 
loop", we simply defined these three special expressions [usable in any if/elif 
statement] to reference special boolean flags that are set after exiting any loop?

The problem is: how long would these "special boolean flags" be retained?
Could they still be tested
    100 lines of code later (assuming no other loops were executed)?
    After returning from a function?
    Inside a new function call?
        etc.
This would violate the principle of ... I can't remember the computer 
science name for it, but let's call it ... local transparency.

Rob Cliffe

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

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NQCLDAZV3256FMXTPGCHRVNUSVXN7ZFT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Sebastian Berg]

On Mon, 2020-07-20 at 22:27 -0700, Christopher Barker wrote:
> On Mon, Jul 20, 2020 at 3:17 AM Rhodri James 
> wrote:
> 
> > Ironically that example pushes me back to -1.  It may look a lot
> > like
> > xarray and pandas working, but that just means it should be in
> > xarray
> > and/or pandas.
> 
> after following most of this discussion, I'm still not sure what we'd
> get
> with keywords in indexing.
> 
> But I do think it would be nice of we could use slice syntax in other
> places. That would allow things like xarray and pandas to use slices
> in
> regular function calls. here's an example from the xarray docs:
> 
>  da.isel(space=0, time=slice(None, 2))
> 
> wouldn't that be nice as:
> 
> da.isel(space=0, time=:2)
> 
> or:
> 
> da.sel(time=slice("2000-01-01", "2000-01-02"))
> 
> could be:
> 
> da.sel(time="2000-01-01":"2000-01-02")
> 
> As far as I can tell, slicing syntax is currently a syntax error in
> these
> cases, and any others I thought to test.
> 
> Is there a reason to not allow syntax for creating a slice object to
> be
> used anywhere (Or more places, anyway)?
> 
> By the way, I just noticed this note in the xarray docs:
> 
> """Note: We would love to be able to do indexing with labeled
> dimension
> names inside brackets, but unfortunately, Python does yet not support
> indexing with keyword arguments like da[space=0]
> """

This would be the thing I would think of first when indexing with
keywords.  But, there are a few points about named dimensions:

First, using it for named dimensions, means you don't actually need to
mix it with normal tuple indexing, mixing both seems rather confusing?
(I cannot think of how to interpret it)

Second,  using keyword arguments for indexing `mode=` or `method=`
switches as Stephan Hoyer mentioned as well seems neat.  But I am
worried that the two potential uses clash way too much and my gut
feeling is to prefer the labeled use (which is why I would be extremely
hesitant to add mode-switching things to NumPy or pandas).  I might
rather prefer mode switching to be spelled as::

temperature.loc(method="nearest")[longitude=longs, latitude=lats]

even if that has to create an intermediate indexer object (twice, since
`.loc` here is also an index helper object).
(This means axis labels must be strings, that is likely no issue, but
should maybe be mentioned.)

Thus, for most containers, my knee jerk reaction would be to discourage
the use of keywords in indexing for mode switching.  But some of the
use-cases seemed more like class factories, for which there is no clash
of these two concepts/applications.

That said, labeled dimensions/axis do seem like nice syntax with quite
a bit of potential to me, even with 3 dimensions, remembering whether
your coordinate order was x,y,z or z,x,y or z,y,x can be annoying
(especially if you mix in a 1-D dataset with only a z axis).

Cheers,

Sebastian


> So they would like it :-)
> 
> -CHB
> 
> 
> 
> ___
> 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/VSQO7A6K2SA7KI25U25CHROPEHCZFEG2/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: This is a digitally signed message part
___
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/QNEFKJPSAIXE2D467MJCYKSHIR7H6TQ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Simplifying functions syntax

[MRAB]

@CHB: Can you be a bit more careful with your trimming. You've removed 
the attribution of the poster. What I wrote was just the reply starting 
from the "-1" line.


On 2020-07-21 16:37, Christopher Barker wrote:

I'm not sure why I'm bothering to engage, but:

On Tue, Jul 21, 2020 at 2:31 AM MRAB > wrote:


terms of simplification would be not creating `fun` as a keyword
and allowing developers to create functions in Python without a
keyword (like in C-family). That way, a new proposal would be
changing:
 x(method: fun[int, dict] -> None) -> None:


one trick is that x(some, stuff) is currently a valid expression.

One real difference between C and Python is that C has "declarations", 
and not just of functions. Python does not, hence the keyword.


As you pointed out in your initial post -- many languages use a 
keyword to declare a function -- I can't see the gain from getting rid 
of that -- even if it were a new language, and we didn't have backward 
compatibility to worry about.


I haven't written a whole lot of C, but I always found the function 
declaration syntax kind of confusing.


-CHB







> ... pass
> ...
 type(x)
> 
>
> What do you think?
>
-1

It's clearer if you say upfront that you're defining a function,
which
is that 'def' does.



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

[Python-ideas] Re: Simplifying functions syntax

[Christopher Barker]

I'm not sure why I'm bothering to engage, but:

On Tue, Jul 21, 2020 at 2:31 AM MRAB  wrote:

> terms of simplification would be not creating `fun` as a keyword and
> allowing developers to create functions in Python without a keyword (like
> in C-family). That way, a new proposal would be changing:
>  x(method: fun[int, dict] -> None) -> None:
>

one trick is that x(some, stuff) is currently a valid expression.

One real difference between C and Python is that C has "declarations", and
not just of functions. Python does not, hence the keyword.

As you pointed out in your initial post -- many languages use a keyword to
declare a function -- I can't see the gain from getting rid of that -- even
if it were a new language, and we didn't have backward compatibility to
worry about.

I haven't written a whole lot of C, but I always found the function
declaration syntax kind of confusing.

-CHB









> > ... pass
> > ...
>  type(x)
> > 
> >
> > What do you think?
> >
> -1
>
> It's clearer if you say upfront that you're defining a function, which
> is that 'def' does.
> ___
> 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/HGJ6VR5SZYE56ZZ7OJNP6QVJUFBVJYBC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/FPIJHQECMWM5LNKQ4MAV66PLUD3L25J5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Guido van Rossum]

I think this cannot just be considered a bug fix, and it seems somewhat
fundamental (catching arbitrary exceptions is controversial), so I
recommend finding a core dev to sponsor a PEP. (Or finding one who thinks
it is obviously a bug and will approve a PR.)

On Tue, Jul 21, 2020 at 04:43 Dominik Vilsmeier 
wrote:

> On 07.07.20 19:41, Stephen J. Turnbull wrote:
>
> > Dominik Vilsmeier writes:
> >
> >   > So if you're dealing with items views and want to compare them to a
> set
> >   > representing dict items, then you need an extra `try/except` in
> order to
> >   > handle non-hashable values in the items view.
> >
> > Sounds like you have a change to propose here, then.  Put the
> > try/except in the __eq__ for the items view class when comparing
> > against a set.  I would expect it to be accepted, as comparing items
> > views is pretty expensive so the slight additional overhead would
> > likely be acceptable, and if you get the exception, you know the
> > equality comparison against a set is false since a set cannot contain
> > that element, so this possibility can't affect worst-case performance
> > by much, if at all.
>
> So it seems there is a consensus on the fact that this is undesirable
> behavior and it can be fixed relatively easy.
>
> What's the next step then? Should this be discussed further on the
> mailing list? Should I open an issue at bpo?
> ___
> 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/G7N7WV5C6JKLIFAA5NGUXW7VEH4CMRKT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/RLJCH2ENXOLCTU4JTK7TCF4NBRC3RUUH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Guido van Rossum]

You have to find a core dev who is willing to act as a Sponsor. I recommend
asking Steven d’Aprano (but I do not know if he’s interested). Until then,
hash out the precise spec for the idea here. Coming up with a solid
motivation is also important.

On Tue, Jul 21, 2020 at 01:15 Stefano Borini 
wrote:

> I am unsure of the process if there's interest. Should I revise the
> PEP and create a new one?
>
> On Tue, 21 Jul 2020 at 06:29, Christopher Barker 
> wrote:
> >
> > On Mon, Jul 20, 2020 at 3:17 AM Rhodri James 
> wrote:
> >>
> >> Ironically that example pushes me back to -1.  It may look a lot like
> >> xarray and pandas working, but that just means it should be in xarray
> >> and/or pandas.
> >
> >
> > after following most of this discussion, I'm still not sure what we'd
> get with keywords in indexing.
> >
> > But I do think it would be nice of we could use slice syntax in other
> places. That would allow things like xarray and pandas to use slices in
> regular function calls. here's an example from the xarray docs:
> >
> >  da.isel(space=0, time=slice(None, 2))
> >
> > wouldn't that be nice as:
> >
> > da.isel(space=0, time=:2)
> >
> > or:
> >
> > da.sel(time=slice("2000-01-01", "2000-01-02"))
> >
> > could be:
> >
> > da.sel(time="2000-01-01":"2000-01-02")
> >
> > As far as I can tell, slicing syntax is currently a syntax error in
> these cases, and any others I thought to test.
> >
> > Is there a reason to not allow syntax for creating a slice object to be
> used anywhere (Or more places, anyway)?
> >
> > By the way, I just noticed this note in the xarray docs:
> >
> > """Note: We would love to be able to do indexing with labeled dimension
> names inside brackets, but unfortunately, Python does yet not support
> indexing with keyword arguments like da[space=0]
> > """
> > So they would like it :-)
> >
> > -CHB
> >
> >
> >
> > --
> > Christopher Barker, PhD
> >
> > Python Language Consulting
> >   - Teaching
> >   - Scientific Software Development
> >   - Desktop GUI and Web Development
> >   - wxPython, numpy, scipy, Cython
> > ___
> > 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/VSQO7A6K2SA7KI25U25CHROPEHCZFEG2/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> 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/FVBXHEKTOTRXBBQ2AVUHTF72YFD4HCCH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/URJK4PLF7XCMRD7PGRKP7BSVGQAVSEZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Ricky Teachey]

On Tue, Jul 21, 2020, 5:48 AM Gerrit Holl  wrote:

> On Sat, 18 Jul 2020 at 18:31, MRAB  wrote:
> > [snip]
> > I haven't followed this thread for a while, but, to me, it seems that
> > the simplest option would be to pass the keyword arguments as a dict:
> >
> >  obj[a, b:c, x=1] does obj.__getitem__((a, slice(b, c)), dict(x=1))
> >
> > If there are no keyword arguments, then there's no dict.
>
> Could the entire argument be turned into a namedtuple?
>

The original rejected PEP had some good reasons for not going with a
namedtuple. I haven't read it in a while but I suggest considering them.
The biggest one being, a new class would have to be created and
instantiated for every indexing 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/K25KTQ73HFTBCWJF6WOB7OTWCEOVP2UE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Gerrit Holl]

On Sat, 18 Jul 2020 at 18:31, MRAB  wrote:
> [snip]
> I haven't followed this thread for a while, but, to me, it seems that
> the simplest option would be to pass the keyword arguments as a dict:
>
>  obj[a, b:c, x=1] does obj.__getitem__((a, slice(b, c)), dict(x=1))
>
> If there are no keyword arguments, then there's no dict.

Could the entire argument be turned into a namedtuple?

obj[a, b:c] does obj.__getitem__((a, slice(b, c)) or
obj.__getitem__(namedtuple(_0=a, _1=slice(b, c)))

obj[a, b:c, d=e:f] does obj.__getitem__(namedtuple(_0=a, _1=slice(b,
c), d=slice(e:f)))

it would seem a namedtuple is a more natural extension of the current
tuple, fully backward compatible (for sane code), while allowing for
keywords that are valid identifiers (which should be an acceptable
limitation).  The other restriction would be that the keyword-indexing
cannot use all-numeric identifiers prepended by an underscore.

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

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Gerrit Holl]

On Mon, 20 Jul 2020 at 04:27, Jonathan Goble  wrote:
>> One use case that comes up in xarray and pandas is support for indicating 
>> indexing "modes". For example, when indexing with floating point numbers 
>> it's convenient to be able to opt-in to approximate indexing, e.g., 
>> something like:
>> array.loc[longitude, latitude, method='nearest', tolerance=0.001]
>
> I had to stare at this for a good 30 seconds before I realized that this 
> wasn't a function/method call. Except for the square brackets instead of 
> parentheses, it would be.
>
> Honestly, this whole idea smells to me like just wanting another type of 
> function call with different semantics.
>
> IMHO the above example would be better spelled as:
>
> array.loc.get(longitude, latitude, method='nearest', tolerance=0.001)
>
> Pros: Much more obvious, perfectly legal today, zero backward compatibility 
> issues, probably the way many libraries with such functionality are doing it 
> now.
> Cons: A few extra characters (depending on the method name; here it's only 
> four) and a couple of taps on the Shift key (but you're already used to that).

Cons

- cannot assign to method call
- cannot use slicing syntax

With PEP:

array[lon=0:10, lat=0:10, method="nearest", tolerance=0.001] = 42

Without PEP (syntactically valid, although not valid xarray API):

array[K(lon=slice(0, 10), lat=slice(0, 10), method="nearest",
tolerance=0.001)] = 42

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

[Python-ideas] Re: Simplifying functions syntax

[MRAB]

On 2020-07-21 01:25, Thiago Carvalho D'Ávila wrote:

Chris Angelico, you have a good point. An alternative solution that would 
achieve similar or even better results in terms of simplification would be not 
creating `fun` as a keyword and allowing developers to create functions in 
Python without a keyword (like in C-family). That way, a new proposal would be 
changing:


from typing import Callable
def x(method: Callable[[int, dict], None]) -> None:

... pass
...

type(x)



Into this:


x(method: fun[int, dict] -> None) -> None:

... pass
...

type(x)



What do you think?


-1

It's clearer if you say upfront that you're defining a function, which 
is that 'def' does.

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

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

[Stefano Borini]

I am unsure of the process if there's interest. Should I revise the
PEP and create a new one?

On Tue, 21 Jul 2020 at 06:29, Christopher Barker  wrote:
>
> On Mon, Jul 20, 2020 at 3:17 AM Rhodri James  wrote:
>>
>> Ironically that example pushes me back to -1.  It may look a lot like
>> xarray and pandas working, but that just means it should be in xarray
>> and/or pandas.
>
>
> after following most of this discussion, I'm still not sure what we'd get 
> with keywords in indexing.
>
> But I do think it would be nice of we could use slice syntax in other places. 
> That would allow things like xarray and pandas to use slices in regular 
> function calls. here's an example from the xarray docs:
>
>  da.isel(space=0, time=slice(None, 2))
>
> wouldn't that be nice as:
>
> da.isel(space=0, time=:2)
>
> or:
>
> da.sel(time=slice("2000-01-01", "2000-01-02"))
>
> could be:
>
> da.sel(time="2000-01-01":"2000-01-02")
>
> As far as I can tell, slicing syntax is currently a syntax error in these 
> cases, and any others I thought to test.
>
> Is there a reason to not allow syntax for creating a slice object to be used 
> anywhere (Or more places, anyway)?
>
> By the way, I just noticed this note in the xarray docs:
>
> """Note: We would love to be able to do indexing with labeled dimension names 
> inside brackets, but unfortunately, Python does yet not support indexing with 
> keyword arguments like da[space=0]
> """
> So they would like it :-)
>
> -CHB
>
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> 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/VSQO7A6K2SA7KI25U25CHROPEHCZFEG2/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Kind regards,

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

[Python-ideas] Re: Simplifying functions syntax

[Chris Angelico]

On Tue, Jul 21, 2020 at 10:34 AM Thiago Carvalho D'Ávila
 wrote:
>
> Chris Angelico, you have a good point. An alternative solution that would 
> achieve similar or even better results in terms of simplification would be 
> not creating `fun` as a keyword and allowing developers to create functions 
> in Python without a keyword (like in C-family). That way, a new proposal 
> would be changing:
>
> >>> from typing import Callable
> >>> def x(method: Callable[[int, dict], None]) -> None:
> ... pass
> ...
> >>> type(x)
> 
>
> Into this:
>
> >>> x(method: fun[int, dict] -> None) -> None:
> ... pass
> ...
> >>> type(x)
> 
>
> What do you think?

Exactly the same thing: that you would do better to create a
transpiler that converts your proposed syntax into legal syntax. That
way, you get to try things out and see how it actually feels, and the
process of creating the transpiler will reveal ambiguities to you :)

(If you want me to be a little more direct about it: I am strongly
against this proposal, as are others.)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/B5HCHATCSKSGWNSA7DNEEOE5TLR25XQG/
Code of Conduct: http://python.org/psf/codeofconduct/