[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
Guido wrote:
I honestly and strongly believe that we should do nothing here. Python
> thrives because it is relatively simple. Adding new syntax to deal with
> looping special cases makes it less simple, and encourages a bad coding
> style (nested loops, multiple breaks...).
>
I agree with about 80% of this statement. In particular I believe strongly
that we should do nothing here, without strong evidence that the change
will bring at least significant benefit to some users, and no or very
little harm to the rest.
I also believe that meeting that criteria is only the first step. It is
quite possible for a reasonable request for change to be reasonably refused.
Again, I believe that one reason why Python thrives is that it is
relatively simple for novices. Another reason is that it provides
facilities such as __dunder__ methods and metaclasses, so that experts can
do advanced things. List comprehensions perhaps lie somewhere in between.
>From a syntactic point of view, I think it important that we do what we can
to avoid novices accidentally encountering an advanced feature. Here's an
example. PEP 622 -- Structural Pattern Matching suggests introducing a
language feature that, I think, most novices will find hard to understand
properly. But it seems that experts will like it's power and simplicity,
for doing some advanced things.
PEP 622 introduces new keywords 'match' and 'case'. The new keywords make
it easy for us to warn novices not to use it (and we don't put it in the
beginners tutorial). Here's the example from the PEP.
def make_point_3d(pt):
match pt:
case (x, y):
return Point3d(x, y, 0)
case (x, y, z):
return Point3d(x, y, z)
case Point2d(x, y):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
Some conditions necessary for "break to a label" to be accepted are strong
use cases, and a syntax that keeps the construction out of the hands of the
novices. These conditions are not sufficient.
I intend to keep my eyes open, as I go about my daily activities, of strong
use cases. If I don't see any, then most likely you won't hear anything
more from me on this suggestion.
--
Jonathan
___
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/ES2B2AX2KCES3PCTZRFJCZA7AKNUXOVF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
On 2020-07-29 at 07:09:05 -0700, Guido van Rossum wrote: > I honestly and strongly believe that we should do nothing here. Python > thrives because it is relatively simple. Adding new syntax to deal > with looping special cases makes it less simple, and encourages a bad > coding style (nested loops, multiple breaks...). I was about to go off on another Get Off My Lawn rant, so thank you for putting this so succintly and so politely. :-) If I end up with more than one flag controlling my search loop, then it's time to break (pun intended) the logic into smaller/simpler pieces rather than to look for a more complicated language construct. ___ 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/V66EY5LEXXTBVYB55NQJXSQNTXFXBVC5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Access (ordered) dict by index; insert slice
.iloc[] is the Pandas function for accessing by integer-location: https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.iloc.html """ Purely integer-location based indexing for selection by position. .iloc[] is primarily integer position based (from 0 to length-1 of the axis), but may also be used with a boolean array. Allowed inputs are: - An integer, e.g. 5. - A list or array of integers, e.g. [4, 3, 0]. - A slice object with ints, e.g. 1:7. - A boolean array. - A callable function with one argument (the calling Series or DataFrame) and that returns valid output for indexing (one of the above). This is useful in method chains, when you don’t have a reference to the calling object, but would like to base your selection on some value. .iloc will raise IndexError if a requested indexer is out-of-bounds, except slice indexers which allow out-of-bounds indexing (this conforms with python/numpy slice semantics). """ https://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#selection-by-position I don't remember why df.iloc[3] is preferred over directly getitem'ing df[3] ? - Because `3` could be a key or an integer-location; to avoid ambiguity - Because changing between df[3] and df.loc[3] and df[3:5] and df.iloc[3:5] is unnecessary cognitive burden: it's easier to determine that the code is intentionally accessing by integer-location from '.iloc' than from ':' (indicating slice notation) >>> odict.iloc[3] Would this be the only way to access only item 4 from an odict of length greater than 4 with slice notation for dict views generated from selection by integer-location? >>> odict[3:4] What does this do? Confusing to a beginner: >>> odict[3,] On Wed, Jul 29, 2020, 1:28 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Christopher Barker writes: > > > from itertools import islice > > > > smaller_dict = dict(islice(large_dict.items(), 0, 255)) > > > > which works, and isn't doing an unnecessary copying but it's pretty > > darn ugly, as far as I'm concerned. > > In your application, I think that's just pretty, myself. The only thing > that's missing is slice notation. But that's probably not hard to > implement in terms of the islice function, just completely redundant. > ___ > 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/LPHMWNCI3VPPN7FEBEUJR4K2QDVNCPX3/ > 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/X4VOHLF4PBDYW7WI7YQIGO4ZZ4KT5Z6N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
Jonathan Fine writes: > Here's a baby example - searching in a nested loop. Suppose we're > looking for the word 'apple' in a collection of books. Once we've > found it, we stop. While I was writing a reply, several people replied with very similar comments, so I won't repeat them. But these two examples are so obnoxious I had to post them: >>> for page in (page for book in books for page in book if 'a' in page): ... break ... >>> page 'abc' >>> [page for book in books for page in book if 'a' in page][0] 'abc' >>> ___ 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/UC5DV2KLXZTRXYBRCAWB7PFODBVNIZDK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
On Wed, Jul 29, 2020 at 07:01 Mathew Elman wrote: > > > On Wed, 29 Jul 2020 at 14:42, Guido van Rossum wrote: > >> On Wed, Jul 29, 2020 at 02:51 Mathew Elman >> wrote: >> >>> >>> . >>> If it *is* useful, it occurs to me that (1) this looks a lot like the try ... except ... pattern, and (2) breaks are generally perceived as exceptional exits from a loop. Instead of "if break [LABEL]", "except [LABEL]" might work, although the semantic difference between labels and exceptions might get a ton of pushback. >>> >>> ... >>> Steve >>> >>> In the related thread I suggested using `except`, but it was largely >>> ignored. >>> >>> >>> *If* you want tou propose clearer syntax for this, please extend the loop syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if [not] break’. >>> —Guido >>> >>> So I understand, does this mean that any extended syntax for this should >>> be *totally* new and not draw on existing constructs such as >>> `try-except` or `if-else`? >>> Or just that the additional clarity should come from extending the loop >>> rather than the implicit `if`? >>> >> >> Actually, given that ‘else:’ already confuses people I very much doubt >> that any other new construct will be acceptable. It is totally five not to >> “solve” this problem at all — all use cases can be done by adding flag >> variables explicitly manipulated by the user’s code. >> > I understand that the "problem" with `else` is aesthetic, though one could > debate the importance of such a problem. > > What I mean to ask is, for example, would having `for-except-else` > (analogous to `try-except-else`) be an acceptable extension of "the loop > syntax, not the ‘if’ syntax"? > I honestly and strongly believe that we should do nothing here. Python thrives because it is relatively simple. Adding new syntax to deal with looping special cases makes it less simple, and encourages a bad coding style (nested loops, multiple breaks...). > > >>> Mathew >>> >>> >>> Notice: >>> This email is confidential and may contain copyright material of members >>> of the Ocado Group. Opinions and views expressed in this message may not >>> necessarily reflect the opinions and views of the members of the Ocado >>> Group. >>> >>> If you are not the intended recipient, please notify us immediately and >>> delete all copies of this message. Please note that it is your >>> responsibility to scan this message for viruses. >>> >>> References to the "Ocado Group" are to Ocado Group plc (registered in >>> England and Wales with number 7098618) and its subsidiary undertakings (as >>> that expression is defined in the Companies Act 2006) from time to time. >>> The registered office of Ocado Group plc is Buildings One & Two, Trident >>> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. >>> ___ >>> 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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> -- >> --Guido (mobile) >> > > Notice: > This email is confidential and may contain copyright material of members > of the Ocado Group. Opinions and views expressed in this message may not > necessarily reflect the opinions and views of the members of the Ocado > Group. > > If you are not the intended recipient, please notify us immediately and > delete all copies of this message. Please note that it is your > responsibility to scan this message for viruses. > > References to the "Ocado Group" are to Ocado Group plc (registered in > England and Wales with number 7098618) and its subsidiary undertakings (as > that expression is defined in the Companies Act 2006) from time to time. > The registered office of Ocado Group plc is Buildings One & Two, Trident > Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. > ___ > 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/YTC6Z4DHUOXSKS7L6MM4HQ4WSZAGVSET/ > 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/A6DGYUOEKUYNT42IOLPJUGT4Z6PZADW4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
On Wed, 29 Jul 2020 at 14:42, Guido van Rossum wrote: > On Wed, Jul 29, 2020 at 02:51 Mathew Elman wrote: > >> >> . >> >>> If it *is* useful, it occurs to me that (1) this looks a lot like the >>> try ... except ... pattern, and (2) breaks are generally perceived as >>> exceptional exits from a loop. Instead of "if break [LABEL]", "except >>> [LABEL]" might work, although the semantic difference between labels >>> and exceptions might get a ton of pushback. >> >> ... >>> >> Steve >>> >> >> In the related thread I suggested using `except`, but it was largely >> ignored. >> >> >> *If* you want tou propose clearer syntax for this, please extend the loop >>> syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if >>> [not] break’. >>> >> >>> —Guido >>> >> >> So I understand, does this mean that any extended syntax for this should >> be *totally* new and not draw on existing constructs such as >> `try-except` or `if-else`? >> Or just that the additional clarity should come from extending the loop >> rather than the implicit `if`? >> > > Actually, given that ‘else:’ already confuses people I very much doubt > that any other new construct will be acceptable. It is totally five not to > “solve” this problem at all — all use cases can be done by adding flag > variables explicitly manipulated by the user’s code. > I understand that the "problem" with `else` is aesthetic, though one could debate the importance of such a problem. What I mean to ask is, for example, would having `for-except-else` (analogous to `try-except-else`) be an acceptable extension of "the loop syntax, not the ‘if’ syntax"? >> Mathew >> >> >> Notice: >> This email is confidential and may contain copyright material of members >> of the Ocado Group. Opinions and views expressed in this message may not >> necessarily reflect the opinions and views of the members of the Ocado >> Group. >> >> If you are not the intended recipient, please notify us immediately and >> delete all copies of this message. Please note that it is your >> responsibility to scan this message for viruses. >> >> References to the "Ocado Group" are to Ocado Group plc (registered in >> England and Wales with number 7098618) and its subsidiary undertakings (as >> that expression is defined in the Companies Act 2006) from time to time. >> The registered office of Ocado Group plc is Buildings One & Two, Trident >> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. >> ___ >> 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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. ___ 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/YTC6Z4DHUOXSKS7L6MM4HQ4WSZAGVSET/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
On 7/28/20 10:30 PM, Rob Cliffe via Python-ideas wrote: A possible, unrelated, future language extension is to allow breaking out of more than one loop at a time. I would think that break would handle that situation. -- ~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/LEBAC5QKDXVCBZJ5NUXTSLFBCW2TW42L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
On 29.07.20 13:33, Jonathan Fine wrote: Thank you all, particularly Guido, for your contributions. Having some examples will help support the exploration of this idea. Here's a baby example - searching in a nested loop. Suppose we're looking for the word 'apple' in a collection of books. Once we've found it, we stop. for book in books: for page in book: if 'apple' in page: break if break: break This can be realized already with `else: continue`: for book in books: for page in book: if 'apple' in page: break else: continue break However it looks more like this should be a function and just return when there is a match: for book in books: for page in book: if 'apple' in page: return True Or flatten the loop with itertools: for page in it.chain.from_iterable(books): if 'apple' in page: break This can also be combined with functions `any` or `next` to check if there's a match or to get the actual page. However, suppose we say that we only look at the first 5000 or so words in each book. (We suppose a page is a list of words.) This leads to the following code. for book in books: word_count = 0 for page in book: word_count += len(page) if word in page: break if word_count >= 5000: break found if break found: break This also could be a function that just returns on a match. Or you could use `itertools.islice` to limit the number of words. I don't see a reason for double break here. At this time, I'd like us to focus on examples of existing code, and semantics that might be helpful. I think once we have this, the discussion of syntax will be easier. By the way, the word_count example is as I typed it, but it has a typo. Did you spot it when you read it? (I only noticed it when re-reading my message.) Finally, thank you for your contributions. More examples please. I think the need for two (or more) distinct `break` reasons or the same `break` reason at multiple different locations in a loop is pretty rare. Are there any counter examples? Otherwise such cases can be handled already today and there's no need for additional syntax (apart from the "else" ambiguity). ___ 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/5OGVHMKXR5K5FACDTKCO2KHTOPYVF66I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
On Wed, Jul 29, 2020 at 02:51 Mathew Elman wrote: > > . > >> If it *is* useful, it occurs to me that (1) this looks a lot like the >> try ... except ... pattern, and (2) breaks are generally perceived as >> exceptional exits from a loop. Instead of "if break [LABEL]", "except >> [LABEL]" might work, although the semantic difference between labels >> and exceptions might get a ton of pushback. > > ... >> > Steve >> > > In the related thread I suggested using `except`, but it was largely > ignored. > > > *If* you want tou propose clearer syntax for this, please extend the loop >> syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if >> [not] break’. >> > >> —Guido >> > > So I understand, does this mean that any extended syntax for this should > be *totally* new and not draw on existing constructs such as `try-except` > or `if-else`? > Or just that the additional clarity should come from extending the loop > rather than the implicit `if`? > Actually, given that ‘else:’ already confuses people I very much doubt that any other new construct will be acceptable. It is totally five not to “solve” this problem at all — all use cases can be done by adding flag variables explicitly manipulated by the user’s code. > > Mathew > > > Notice: > This email is confidential and may contain copyright material of members > of the Ocado Group. Opinions and views expressed in this message may not > necessarily reflect the opinions and views of the members of the Ocado > Group. > > If you are not the intended recipient, please notify us immediately and > delete all copies of this message. Please note that it is your > responsibility to scan this message for viruses. > > References to the "Ocado Group" are to Ocado Group plc (registered in > England and Wales with number 7098618) and its subsidiary undertakings (as > that expression is defined in the Companies Act 2006) from time to time. > The registered office of Ocado Group plc is Buildings One & Two, Trident > Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. > ___ > 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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/ > 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/Y7PMBCC7EE7IWEFXSJN4ZNKFT3DUMSS4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
Thank you all, particularly Guido, for your contributions. Having some examples will help support the exploration of this idea. Here's a baby example - searching in a nested loop. Suppose we're looking for the word 'apple' in a collection of books. Once we've found it, we stop. for book in books: for page in book: if 'apple' in page: break if break: break However, suppose we say that we only look at the first 5000 or so words in each book. (We suppose a page is a list of words.) This leads to the following code. for book in books: word_count = 0 for page in book: word_count += len(page) if word in page: break if word_count >= 5000: break found if break found: break At this time, I'd like us to focus on examples of existing code, and semantics that might be helpful. I think once we have this, the discussion of syntax will be easier. By the way, the word_count example is as I typed it, but it has a typo. Did you spot it when you read it? (I only noticed it when re-reading my message.) Finally, thank you for your contributions. More examples please. -- Jonathan ___ 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/ECALTXEP7M3YWAQCHLPRWPBJRQKQICBC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?
On 2020-07-29 at 14:26:25 +0900, "Stephen J. Turnbull" wrote: > 2qdxy4rzwzuui...@potatochowder.com writes: > > > in order to foil suck attacks. > > Typo of the Year candidate! (It was a typo, right?) Call it a Freudian slip of the fingers. ___ 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/GS6TDRETAPG2WRLMNDQFZORSYC2OID2A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else
. > If it *is* useful, it occurs to me that (1) this looks a lot like the > try ... except ... pattern, and (2) breaks are generally perceived as > exceptional exits from a loop. Instead of "if break [LABEL]", "except > [LABEL]" might work, although the semantic difference between labels > and exceptions might get a ton of pushback. ... > Steve > In the related thread I suggested using `except`, but it was largely ignored. *If* you want tou propose clearer syntax for this, please extend the loop > syntax, not the ‘if’ syntax. So, ‘case ... zero’ makes more sense than ‘if > [not] break’. > > —Guido > So I understand, does this mean that any extended syntax for this should be *totally* new and not draw on existing constructs such as `try-except` or `if-else`? Or just that the additional clarity should come from extending the loop rather than the implicit `if`? Mathew -- Notice: This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group. If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses. References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL. ___ 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/TVTCXQN5KDMQUCFQ7AJES2RISPFD6OTL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict
On Wed, 29 Jul 2020 at 06:41, Inada Naoki wrote:
> FWIW, I optimized dict(d) in https://bugs.python.org/issue41431
> (https://github.com/python/cpython/pull/21674 )
> [...] 4.76x faster (-79%)
>
Great!
On Wed, 29 Jul 2020 at 06:41, Inada Naoki wrote:
> On Sun, Jul 26, 2020 at 4:44 AM Marco Sulla
> wrote:
> >
> > I also remembered another possible use-case: kwargs in CPython. In C
> code, kwargs are PyDictObjects. I suppose they are usually not modified; if
> so, fdict could be used, since it seems to be faster at creation.
>
> [...] note that kwargs is not created by `dict(d)`.
> It is created by PyDict_New() and PyDict_SetItem().
Yes, I was really thinking about PyDict_New().
On Sat, 25 Jul 2020 at 21:55, Guido van Rossum wrote:
> [...] Unfortunately it's impossible to change without breaking tons of
> existing code, since things like `kwds.pop("something")` have become a
> pretty standard idiom to use it.
>
Well, I was thinking about CPython code. Anyway, maybe there's a way to not
break old code:
def hello(name: str, **kwargs: frozendict) -> str:
# code
In the meanwhile I tried to optimize iteration. It seems also that
iteration can be faster:
https://github.com/Marco-Sulla/cpython/commit/3d802ba227eb588b0608f31cfa2357064b4726bf
I also done some other changes later, but for some reason I get a segfault now:
https://github.com/Marco-Sulla/cpython/commit/51e2c45a5b7fa36f47aa55f2b4426c0dc09baab6
___
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/AYJN2BVWU5F2SR3D7L5I7P6K2HHLZLTW/
Code of Conduct: http://python.org/psf/codeofconduct/
