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

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: > >

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

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

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

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

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

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

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

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

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

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? >> >>

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

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

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

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: >

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

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: > ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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. >

[Python-ideas] Re: Simplifying functions syntax

@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

[Python-ideas] Re: Simplifying functions syntax

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

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

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

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

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

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

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

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

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

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

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:

[Python-ideas] Re: Simplifying functions syntax

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

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

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

[Python-ideas] Re: Simplifying functions syntax

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