[Python-Dev] Re: new syntax
On Tue, Mar 3, 2020 at 8:06 AM Luca Wolf wrote: > > Dear Python Team, > > I have a good idea for a new comand in Python. > > It’s „intput()“ for numbers. So you don’t have to write „int(Input())“. > > It’s much easier to write and it’s faster too. > > You can use the same for „floatput()“, so don’t have to write > „float(Input())“. > > > > I hope you can make something good with this idea. > Put this at the top of your program: def intput(p=""): return int(input(p)) def floatput(p=""): return float(input(p)) There! Done :) BTW, ideas like these generally want to go to python-ideas, not python-dev; or for some of them, python-list is appropriate too, as you'll often get responses showing how you can do it with existing Python versions. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W5ICQOI5HQSSRMNBY5BJCLFDUXINKAEO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict
On Thu, Feb 27, 2020 at 8:15 PM Serhiy Storchaka wrote:
>
> 27.02.20 10:46, Chris Angelico пише:
> > On Thu, Feb 27, 2020 at 7:41 PM Serhiy Storchaka
> > wrote:
> >> sympy/utilities/runtests.py
> >>
> >> Sorry, but the current code
> >>
> >> globs = globs.copy()
> >> if extraglobs is not None:
> >> globs.update(extraglobs)
> >>
> >> looks much clearer to me than the proposed
> >>
> >> globs = globs | (extraglobs if extraglobs is not None else {})
> >
> > Is there a reason for not writing it as:
> >
> > globs = globs | (extraglobs or {})
> >
> > ? That reads fairly well to me.
>
> Sure. Although it would work different if extraglobs is a false value
> different from None, empty mapping and iterable.
Yes, technically it's different. But other than this silently ignoring
errors like passing 0 rather than None, it's unlikely to have any
material difference.
> But if we ignore such
> subtle details, it could be written also as
>
> globs = {**globs, **(extraglobs or {})}
Yeah, but now I think the pipe syntax has a definite advantage.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/JR3T3GFE3L6BWI7WVZ5OEOU6NCRRQRLY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Merging PRs without CLA signed
On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou wrote: > > On Mon, 24 Feb 2020 00:30:41 -0500 > Kyle Stanley wrote: > > > In that case I'm not sure the author ought to get credit for the PR. They > > can file a bug pointing out the typo and someone else can submit a fix. > > > > That sounds like a reasonable solution to me; even for more substantial > > issues (if signing the CLA is a genuine issue). I think there are a fair > > number of individuals out there who just want to fix something and aren't > > concerned with attributions or long-term contributions; they just want to > > fix the issue for themselves or perhaps for altruistic reasons. > > I'd like to point out that the relevant perspective here isn't PSF > policy as much as copyright law. Something as trivial as a typo fix > for sure isn't copyrightable, so there's no point in requiring a CLA > for it. For more involved changes, things are less clear, and a court > would be the final authority; but that's admittedly an argument for > erring on the side of caution and requiring a CLA for *any* non-trivial > change. > I don't think anyone disputes that the CLA is needed for any non-trivial change. The question is, what constitutes a non-trivial change? Is it subjective? What's the smallest copyrightable edit (which may or may not be related to the smallest copyrightable piece of text)? Does it depend on context - is fixing a link more trivial than fixing a piece of English? It'd be great to get a lawyer's firm stance on this. On the PEPs repo, I've merged a good few simple PRs, and don't want to be putting the PSF into legal trouble. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KNX3ZIQKABBNH6LXEWZ765UKVDR7C3CT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On Fri, Jan 24, 2020 at 7:40 PM Victor Stinner wrote: > > The change is that Python 2.7 is no longer supported (since 2020-01-01). > Which means that it's now okay to remove things, correct? Starting with 3.9, it's no longer necessary to maintain compatibility with 2.7? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HB6UQMP7FUKT6EAXZDTTCBNMGGJ7NWAC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner wrote: > We kept a compatibility layer with Python 2 on purpose, PEP 4 says: > > "In order to facilitate writing code that works in both Python 2 & 3 > simultaneously, any module that exists in both Python 3.5 and Python > 2.7 will not be removed from the standard library until Python 2.7 is > no longer supported as specified by PEP 373." > > The rule was used since Python 3.0 until Python 3.8, but it changed in > Python 3.9 which includes many incompatible changes for the first time > in the Python 3 major version. I'm sorry, I don't understand what 'changed'. Isn't that rule exactly WHY 3.9 is the removal point? Python 2.7 is no longer supported, and its final post-support release is scheduled earlier than 3.9's first beta and feature freeze. Doesn't that mean that PEP 4 is being followed precisely? What have I misunderstood? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GCCLU2O2QJTGECQKUYEHD2KVD3IKJTLE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?
On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote: > > The only thing I'm unsure of here is whether direct use of the `==` and > `!=` operators are included as "implicit calls" to the dunders. I > *think* I understand Guido's intention, but I'm not sure: > > * x == y MUST call `__eq__` > > * likewise x != y MUST call `__ne__` > > * but compound objects such as lists and other collections MAY skip > calling `__eq__` (or `__eq__`) on their component parts. > Are there any non-container uses where this comes up? Can the rule be codified simply as that container membership, in all core/stdlib types, is defined by "x is y or x == y"? (And possibly some additional words regarding recursive equality, if that isn't considered to be an extension of "membership".) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YE3X3IDZB4RI4ZJHSQEKX67EFJTLYYQA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
On Thu, Feb 6, 2020 at 7:42 PM Musbur wrote:
>
> Depends on what d is.
>
> >>> type({})
>
>
> So the result is {(1, 2): None}, but the ambiguity comes from the
> definition of {}, not from my proposal.
>
Actually, what Serhiy hinted at was a consequence (and, I would say, a
rather weird corner case) of the current definition of |= as being
"equivalent to update()". Since update() will accept a number of
things, including an iterable of pairs, it's actually possible to use
a set of two-element tuples as a representation of keys and values. It
seems pretty unlikely that anyone would use a *set* for this (as
opposed to, say, a list or generator), but it does mean that your
proposal would conflict with that. Which in turn means you're actually
asking for |= to special-case sets; not impossible, by any means, but
it's a definite change and not simply a logical extension of current
behaviour.
I don't think supporting sets in |= is worth this confusion,
especially since there's no easy way to override the choice of value.
It'd be just as easy to do thing|=dict.fromkeys(s) and avoid the whole
issue. However, IMO the &= operator would be better able to accept a
set, and this is something that wouldn't conflict (and thus can be
safely added later).
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/BTYIZSBWR3O5JRIGFHOZWVIPUISUGDHB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?
On Tue, Feb 4, 2020 at 10:12 AM Sebastian Berg
wrote:
>
> Now, probably this has been rejected a hundred times before, and there
> are some very good reason why it is a horrible thought...
>
> But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> operation (and in a sense it seems to me that it is), is there a point
> in explicitly defining it?
>
> That would mean adding `operator.equivalent(a, b) -> bool` which would
> allow float to override the result and let
> `operator.equivalent_value(float("NaN"), float("NaN))` return True;
> luckily very few types would actually override the operation.
>
> That operator would obviously be allowed to use the shortcut.
>
> At that point container `==` and `in` (and equivalence) is defined
> based on element equivalence.
> NAs (missing value handling) may be an actual use-case where it is more
> than a theoretical thought. However, I do not seriously work with NAs
> myself.
The implication here is that there would be a corresponding dunder
method, yes? If it's possible for a type to override it, that would
need a dunder. I think that's not necessary; but if there were some
useful name that could be given to this "identical or equal"
comparison, then I think it'd be useful to (a) put that function into
the operator table, and (b) use that name in the description of
container operations.
Can the word "equivalent" be used for this, perhaps?
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/6W2WWBXDD5H45DCGV4H2BRUSC3LI7JWD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?
On Tue, Feb 4, 2020 at 1:08 PM Steven D'Aprano wrote:
>
> On Tue, Feb 04, 2020 at 12:33:44PM +1100, Chris Angelico wrote:
>
> [Sebastian Berg]
> > > But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> > > operation (and in a sense it seems to me that it is), is there a point
> > > in explicitly defining it?
> > >
> > > That would mean adding `operator.equivalent(a, b) -> bool` which would
> > > allow float to override the result and let
> > > `operator.equivalent_value(float("NaN"), float("NaN))` return True;
> > > luckily very few types would actually override the operation.
>
> > The implication here is that there would be a corresponding dunder
> > method, yes? If it's possible for a type to override it, that would
> > need a dunder.
>
> I think the whole point of this is that it *cannot* be overridden.
Yes, I agree.
> Can we summarise this issue like this?
>
> [quote]
> Containers or other compound objects are permitted to use identity
> testing to shortcut what would otherwise be an equality test (e.g. in
> list equality tests, and containment tests), even if that would change
> the behaviour of unusual values, such as floating point NANs which
> compare unequal to themselves, or objects where `__eq__` have side
> effects.
>
> Such containers are permitted to assume that their contents all obey the
> reflexivity of equality (each value is equal to itself) and so avoid
> calling `__eq__` or `__ne__`.
>
> This is an implementation-specific detail which may differ across
> different container types and interpreters.
> [end quote]
I'd actually rather see it codified as a specific form of comparison
and made a guarantee, upon which other guarantees and invariants can
be based. It's not an optimization (although it can have the effect of
improving performance), it's a codification of the expectations of
containers. As such, this comparison would be defined by language
rules as the way that built-in containers behave, and would also be
the recommended and normal obvious way to build other container types.
> > Can the word "equivalent" be used for this, perhaps?
>
> We don't need and shouldn't have a dunder for this, but the word
> "equivalent" would be wrong in any case. Two objects may be equivalent
> but not equal, for example, when it comes to iteration, the string "abc"
> is equivalent to the list ['a', 'b', 'c'].
Hmm, true, although that's equivalent only in one specific situation.
In mathematics, "congruent" means that two things are functionally
equivalent (eg triangles with the same length sides; in programming
terms we'd probably say that two such triangles would be "equal" but
not identical), even if there's a specific context for such
equivalence, such as stating that 12,345 is congruent to 11 modulo 7,
because the remainders 12345%7 and 11%7 are both 4. So maybe
"congruent" could be used for this concept?
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/AFWTEJ4LHPRGALIB4GNURQ26VCVZXZRC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
On Fri, Feb 7, 2020 at 9:30 AM Brandt Bucher wrote: > > Sorry Paul, I sent my reply too soon. > > I see what you're saying, and I'm pretty firmly -1 on reinventing (or > importing) copy.copy. We already have an API for copying a dict (dict.copy). > > I still fail to see problem with using a method that doesn't start and end > with underscores, other than that we "haven't done it". > Before Python 3.0, iterators had a next() method, and that was explicitly and consciously changed to __next__(). The arguments there seem relevant here too. https://www.python.org/dev/peps/pep-3114/ ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SGWZHDDSMZEH53N2MK2MSY7UQPG543FU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
On Thu, Feb 6, 2020 at 3:47 AM Brandt Bucher wrote: > > > I have one suggestion: Wouldn't it be useful for these operators to also > > accept sets (functionally acting like a dict with None for all values)? > > > Why None? Why not 0, or False, or 42? This sort of thing belongs more in > > a function or method, IMHO. > > Well, in their defense, None is the null object in Python, so it would be a > natural choice. With that said, I am strongly against this for several > reasons: > > - The proposal in its current form is very easy to wrap your head around: "|" > takes dicts, "|=" takes anything dict.update does. > - Python doesn't allow sets to be dictionaries anywhere else. It's much more > natural to use a dict like a set than to use a set like a dict. Hence, this > PEP! > - A consistent argument that we've gotten since the very beginning is > something to the effect of "I don't know what types are being used in the > expression 'a | b'." While we argue that this isn't the issue in practice > that people make it out to be, accepting sets here would definitely muddy the > waters. > - and you can use dict.fromkeys to "upgrade" a set to a dict anyway. If this goes through as is, and then in a few years' time we start seeing lots of people begging to be able to skip the explicit fromkeys and accept sets directly, it can be addressed then. Personally, I think sets make good sense on the right hand side of an intersection (as a means of saying "whitelist the keys to this set"; values would be irrelevant there anyway), but not with union/update. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NZWJDWAHGJSOMI23ZAU5CDEC4BHJMFRT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?
On Sat, Jan 25, 2020 at 9:40 AM Tim Peters wrote: > I think it needs more words, though, to flesh out what about this is > allowed by the language (as opposed to what CPython happens to do), > and to get closer to what Guido is trying to get at with his > "*implicit* calls". For example, it's at work here, but there's not a > built-in container in sight: > > >>> import math > >>> def f(): > ... while True: > ... yield math.nan > >>> math.nan in f() > True > The iterator/generator is behaving the way a lazy container would, so it's fairly unsurprising. Perhaps "container-like objects"? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LP6VL2GQZKOQEA4ZLLXKPB25IOSI6PHY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Documenting Python's float.__str__()
On Wed, Jan 22, 2020 at 4:03 AM Eric V. Smith wrote: > The reason repr adds the '.0' that 'g' does not is to avoid this problem: > > >>> type(eval(repr(17.0))) == type(17.0) > True > >>> type(eval(format(17.0, '.17g'))) == type(17.0) > False > The OP wasn't asking about eval, though, but about float. If you're depending on the ability to eval the repr of a float, you also have to concern yourself with inf and nan, which are not builtin names. But I believe float(repr(x)) == x for any float x. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LA3UGPBZYV3ODLEIUDUP26J43IHS56LI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
On Tue, Dec 24, 2019 at 1:57 PM Kyle Stanley wrote:
> Add (much faster for dicts):
> >>> timeit.timeit("s = set(); s.add(0)", number=100_000_000)
> 13.330938750001224
> >>> timeit.timeit("d = {}; d[0] = None", number=100_000_000)
> 5.788865385999088
I think this is an artifact of Python not having an empty set literal.
>>> timeit.timeit("s = set(); s.add(0)", number=100_000_000)
13.275540543720126
>>> timeit.timeit("d = dict(); d[0] = None", number=100_000_000)
13.044076398015022
>>> timeit.timeit("d = {}; d[0] = None", number=100_000_000)
6.088695731014013
>>> timeit.timeit("s = {1}; s.add(0)", number=100_000_000)
9.260965215042233
>>> timeit.timeit("d = {1:2}; d[0] = None", number=100_000_000)
8.75433829985559
When both use the constructor call or both use a literal, the
difference is far smaller. I'd call this one a wash.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/ODZYHNI57MFZD3I7TGP3B3HJTRX36KGB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Improvement to SimpleNamespace
On Wed, Apr 15, 2020 at 2:09 PM Raymond Hettinger
wrote:
>
> [GvR]
> > We should not try to import JavaScript's object model into Python.
>
> Yes, I get that. Just want to point-out that working with heavily nested
> dictionaries (typical for JSON) is no fun with square brackets and quotation
> marks.
>
My solution to that has usually been something along the lines of:
def get(obj, path):
for step in path.split("-"):
obj = obj[step]
return obj
print(get(catalog, 'clothing-mens-shoes-extra_wide-quantity'))
Will often be custom-tweaked to the situation, but the basic idea is the same.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/XNCNGO3PYOTFVWKTYCO6T57JW3YH24D4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 617: New PEG parser for CPython
On Tue, Apr 7, 2020 at 5:03 AM Guido van Rossum wrote: > > On Mon, Apr 6, 2020 at 11:36 AM Steven D'Aprano wrote: >> Personally, I would not like to have to explain to newcomers why `match` >> is a keyword but you can still use it as a function or variable, but not >> other keywords like `raise`, `in`, `def` etc. >> >> match expression: >> match = True > > > What kind of newcomers do you have that they even notice that, unless you > were to draw attention to it? I'm serious -- from the kind of questions I've > seen in user forums, most newcomers are having a hard enough time learning > more fundamental concepts and abstractions than the precise rules for > reserved words. > >From my experience of teaching a variety of languages, including SQL, it's usually not something people have a problem with in toy examples - but it becomes a major nuisance when they're trying to deal with a problem and some keyword is getting in the way. SQL is *full* of context-sensitive keywords, and every once in a while, someone uses a non-reserved word as a column name, and everything works until they run into some specific context where it doesn't work. (It's a bit messier than in Python due to multiple abstraction layers eg ORMs, and sometimes they deal with these issues and sometimes not; but it's still that much harder to debug specifically _because_ things aren't always reserved.) Ultimately it comes down to the number of edge cases that people have to learn, and how edgy those cases are. Python already has the possibility to override builtins, so you can say "list = []" without an error; context-sensitive keywords sit in a space between those and fully-reserved words. It'll come down to specific words as to whether it's inevitably going to be a problem down the track, or almost certainly going to be fine. BTW, is the PEG parser going to make it easier to hack on the language syntax? If so, it'd be that much easier to experiment with these kinds of ideas in a separate branch/fork, and quickly find out if there's going to be any major impact. At the moment, editing the grammar is a bit daunting - too many easy ways to mess it up. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OAF2EVT6ZGRFOHMVLZGETZSSG52CGYQV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Further PEP 615 Discussion: Equality and hash of ZoneInfo
On Sun, Apr 19, 2020 at 3:39 AM Paul Ganssle wrote:
>
> A few weeks ago, I submitted PEP 615 to the steering council for a decision.
> There's been a decent amount of discussion there with some very good
> questions. I think they are mostly resolved (though I'm happy to have other
> people look over the logic of some of my responses there), but Victor brought
> up the question of the equality and hash behavior of ZoneInfo, and while I'm
> leaning one way, I could easily be convinced - particularly if people have
> real use cases that they are planning to implement that would be affected by
> this.
>
> I've summed up the options on the discourse thread, and would appreciate if
> anyone is able to give some feedback.
>
> Thanks!
In every use-case that I've ever had, and every one that I can
imagine, I've not cared about the difference between "US/Eastern" and
"America/New_York". In fact, if ZoneInfo("US/Eastern") returned
something that had a name of "America/New_York", I would be fine with
that. Similarly, Australia/Melbourne and Australia/Sydney are, to my
knowledge, equivalent. (If I'm wrong on my own country's history of
timezones, then I apologize and withdraw the example, but I'm talking
about cases where you absolutely cannot tell the difference based on
the displayed time.) Having those compare equal would be convenient.
I don't think it's a problem to have equivalent objects unable to
coexist in a set. That's just the way sets work - len({5, 5.0}) is 1,
not 2.
Since options 3 and 4 are the most expensive, I'm fine with the idea
of a future method that would test for equivalence, rather than having
them actually compare equal; but I'd also be fine with having
ZoneInfo("US/Eastern") actually return the same object that
ZoneInfo("America/New_York") returns. For the equality comparison, I
would be happy with proposal 2.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/JPUGSSXX2MWF3ABH3QNHXSMNVDWMRVJS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Question about bytecode stability
On Mon, Apr 6, 2020 at 1:53 PM Jonathan Goble wrote: > > I'm getting ready to get back into an old personal project with some new > ideas. Before I do, I need to ask a question regarding the stability of > CPython bytecode. Before you say it, I am well aware and fully understand > that the opcodes may change in value and semantics between 3.x and 3.(x+1) > without notice, and that's acceptable to me. > > My question is, are the opcodes guaranteed stable across the lifetime of a > single 3.x release? In other words, are they guaranteed to not change values > or semantics between 3.x.y and 3.x.(y+1)? Reading through the list of opcodes > in the dis documentation, it seems that all changes have occurred in 3.x.0, > so it seems the answer would be yes, but then the "CPython implementation > detail" paragraph at the top doesn't specify that and is a little vague on > whether that's true or not. > The best way to look at this is to consider how long a .pyc file is valid. They're currently named something like __pycache__/modulename.cpython-38.pyc which is a fairly clear indication that the cached compiled module should be valid for any CPython 3.8.x release. So yes, you should be safe within any given release. The reason it's a CPython implementation detail is also hinted at in the file name: if you were to use Jython or PyPy or IronPython or MicroPython or any other implementation, you can't be sure your bytecodes will work, even if the version number is the same. (An interpreter can be compatible with Python 3.8 without having the same bytecode as CPython 3.8.) So for your purposes, it sounds like, yes, this WILL work. :) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ICZUG7FBLAVUTCGSAZMFDS2UDHMKY7MR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev wrote: > > I'm skeptical about anything that hides an object's "true nature": this is a > major landmine in diagnostics because it lies to you about what > you are looking at and where to look for its implementation. > > E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" > -- so I would search the code for "AddressFamily" to see what > I'm looking at and what else I can do with it. The fact that it's also > directly availabe from the `socket` module is incidental: it could be > as easily made available from anywhere else -- not even a module. > But if it's described as socket.AF_UNIX then you know where to go looking for it, and type() can tell you the type if you actually need it. +1 for changing the socket enums; -1 for changing enums in general. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/O4XYZC7FBEO3ELAZGLEUNQY6PDCP7PED/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
On Thu, Mar 26, 2020 at 12:08 PM Ivan Pozdeev via Python-Dev wrote: > > > On 26.03.2020 2:41, Chris Angelico wrote: > > On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev > > wrote: > >> I'm skeptical about anything that hides an object's "true nature": this is > >> a major landmine in diagnostics because it lies to you about what > >> you are looking at and where to look for its implementation. > >> > >> E. g. in this case, AF_UNIX is a member of some entity called > >> "AddressFamily" -- so I would search the code for "AddressFamily" to see > >> what > >> I'm looking at and what else I can do with it. The fact that it's also > >> directly availabe from the `socket` module is incidental: it could be > >> as easily made available from anywhere else -- not even a module. > >> > > But if it's described as socket.AF_UNIX then you know where to go > > looking for it, > > No, I don't. https://docs.python.org/3/library/functions.html#repr sets the > standard -- thus the expectation -- for user-defined types: > "...otherwise the representation is a string enclosed in angle brackets that > contains the name of the type of the object together with > additional information often including the name and address of the object" -- > which this suggestion would be breaking. > > By this standard, "socket.AF_UNIX" looks like something defined directly at > module level. So I'll be looking for a definition at module > level -- and not find it. At which point, I'd suspect shenanigans like a > dynamic creation or assignment. Which can be absolutely anywhere! > And I'll be looking for the wrong thing still! > """For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval()...""" >>> socket.AF_UNIX If the repr were "socket.AF_UNIX", then that would indeed be a string that would yield an object with the same value. The current repr isn't wrong by this definition, but nor is the proposed change. Is it defined at module level? I couldn't care less; all that matters is that it is *accessible* at module level. I don't have to say "socket.AddressFamily.AF_UNIX". ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4Q7SVP6ZXR4SAPMDWYGPH7OWX5YXI44M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name
On Sat, Mar 28, 2020 at 11:28 AM Ivan Pozdeev via Python-Dev wrote: > > On 26.03.2020 19:24, Ethan Furman wrote: > > Before Enum, the repr for socket.AF_UNIX was: > > > > 1 > > > > Not very useful for debugging. > > On the contrary, it's perfect. I know everything I need: it's an integer > constant, end of story. > > When examining some live object, I would probably see that "1" and won't even > need to look anything up to know what I'm dealing with. This is something I see *very* frequently from expert and novice Python programmers: the belief/assumption that seeing the concrete data is the most important thing. As an extreme expert in socket programming, you probably DO interpret the integer 1 as "AF_UNIX", but quite honestly, I wouldn't recognize it as such. But a repr that says that it's socket.AF_UNIX is far far more helpful. Consider: Suppose you have a call to socket.socket(socket.SOCK_STREAM, socket.AF_INET, socket.IPPROTO_TCP) - only they're not literal values, they're coming from elsewhere. Pre-enum, all you know is that it's being passed the integers 1, 2, and 6, and how are you going to figure out what they mean? Thanks to the enum, you get to see them with their names (which may make the bug obvious). But either way, they are "socket.AF_INET" etc, they are not "socket.AddressFamily.AF_INET" - the class is a mere implementation detail. In actual fact, the concrete integer value is just an implementation detail, too. As long as passing socket.AF_INET results in an internet-address-family socket, it doesn't really matter what the actual integer is. For the sake of cross-language debugging, it's helpful to be able to see it, but most Python programmers aren't going to need it. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MDTY2P2UWIU2O2OYP7A6RVJLB4PA73MM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Tue, May 12, 2020 at 5:20 PM Paul Moore wrote: > > On Tue, 12 May 2020 at 07:53, Brandt Bucher wrote: > > > > Another proposed idiom, per-module shadowing of the built-in zip with > > > > some subtly different variant from itertools, is an anti-pattern that > > > > shouldn't be encouraged. > > > Source? > > > > Point taken. I probably went a bit far labeling this a straight-up > > "anti-pattern", but it is certainly annoying to find that someone has added > > `from pprint import pprint as print` at the top of a module, for example > > (which has actually happened to me before). Very hard to figure out what's > > happening. > > Also irrelevant. It's very easy to suggest bad ways of using a > feature. That doesn't make the feature bad. You seem to be arguing > that zip_strict is bad because people can misuse it. We could probably > remove 99% of the Python language by that argument... > And considering that "from __future__ import print_function" is an officially-sanctioned way to cause a semantic change to print, I don't think it's really that strong an argument. Python is *deliberately* designed so that you can shadow things. I am most in favour of the separate-functions option *because* it makes shadowing easy. Not an anti-pattern at all. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EWNW7SQGN55NIME6LD3NVVJUWIKXZO4I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou wrote: > > On Fri, 15 May 2020 10:46:25 -0400 > David Mertz wrote: > > > > > 1. +1 itertools.zip_strict function > > > 2. +1 zip.strict(*args) > > > 3. +1 zip(*args, mode='strict') # mode='shortest' by default > > > 4. +0 zip(*args, strict=True) > > > > > > > Mostly I agree with Steven on relative preference: > > > > itertools.zip_strict() +1 > > zip.strict() +0.5 > > zip(mode='strict') +0 > > zip(strict=True) -0.5 > > For me: > > * zip(strict=True) +1 > * zip(mode='strict') -0 > * itertools.zip_strict() -0.5 > * zip.strict() -1 (but really, I'd like to make this -1e10) > Since we're posting: itertools.zip_strict() +1 zip.strict() +0.1 zip(strict=True) -0.5 zip(mode='strict') -1 ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JFPAP6TKMYOJNLVRN52RPN6432FDY2N4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Wed, May 13, 2020 at 4:38 AM Ethan Furman wrote: > > > - > > https://github.com/python/cpython/blob/27c0d9b54abaa4112d5a317b8aa78b39ad60a808/Lib/os.py#L510 > > Wow -- I don't even know how to parse that! > Wow, that's quite an example. Of something, I'm not sure what, but definitely an example. Based on two booleans, entries is either None or a list. If it's None, this loops over just the directory names; if it's a list, then it's been populated in perfect parallel to dirs (see the preceding loop), thus guaranteeing that the two lists are perfectly parallel. But in that case, "name" actually gets a tuple of (name,entry), and then inside the loop, it does a three-way branch that is guaranteed (and asserted) to split out the name and entry ONLY when there actually will be one. Definitely an odd piece of code. But it can never zip over things of different lengths. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P6K3JGADX5A34CY2VOKVCJDYTDX3WQEY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proliferation of tstate arguments.
On Wed, Mar 18, 2020 at 3:50 AM Mark Shannon wrote: > The accessibility of a thread-local variable is a strict superset of > that of a function-local variable. > > Therefore storing the thread state in a thread-local variable is at > least as capable as passing thread-state as a parameter. > And by that logic, globals are even more capable. I don't understand your point. Isn't the purpose of the tstate parameters to avoid the problem of being unable to have multiple tstates within the same OS thread? I think I've missed something here. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NLDQYOZYFDDXR73MR4XSLKN5NWZPSLWE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On Sun, Mar 22, 2020 at 5:41 AM Steven D'Aprano wrote: > > On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote: > > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney > > wrote: > > > This is a proposal to add two new methods, ``cutprefix`` and > > > ``cutsuffix``, to the APIs of Python's various string objects. > > > > The names should use "start" and "end" instead of "prefix" and > > "suffix", to reduce the jargon factor > > Prefix and suffix aren't jargon. They teach those words to kids in > primary school. > > Why the concern over "jargon"? We happily talk about exception, > metaclass, thread, process, CPU, gigabyte, async, ethernet, socket, > hexadecimal, iterator, class, instance, HTTP, boolean, etc without > blinking, but you're shying at prefix and suffix? > As a general rule, jargon from your OWN domain is easier to justify than jargon from some OTHER domain. (Though in this case, I agree that "prefix" and "suffix" shouldn't be a problem.) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BSCTUBWDBFHOJQJKBX2HFTDSWHI6VGCV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes
On Sun, Mar 22, 2020 at 1:02 PM Nathaniel Smith wrote:
>
> On Sat, Mar 21, 2020 at 11:35 AM Steven D'Aprano wrote:
> >
> > On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > > wrote:
> > > > This is a proposal to add two new methods, ``cutprefix`` and
> > > > ``cutsuffix``, to the APIs of Python's various string objects.
> > >
> > > The names should use "start" and "end" instead of "prefix" and
> > > "suffix", to reduce the jargon factor
> >
> > Prefix and suffix aren't jargon. They teach those words to kids in
> > primary school.
>
> Whereas they don't have to teach "start" and "end", because kids
> already know them before they start school.
>
> > Why the concern over "jargon"? We happily talk about exception,
> > metaclass, thread, process, CPU, gigabyte, async, ethernet, socket,
> > hexadecimal, iterator, class, instance, HTTP, boolean, etc without
> > blinking, but you're shying at prefix and suffix?
>
> Yeah. Jargon is fine when there's no regular word with appropriate
> precision, but we shouldn't use jargon just for jargon's sake. Python
> has a long tradition of preferring regular words when possible, e.g.
> using not/and/or instead of !/&&/||, and startswith/endswith instead
> of hasprefix/hassuffix.
>
Given that the word "prefix" appears in help("".startswith), I don't
think there's really a lot to be gained by arguing this point :)
There's absolutely nothing wrong with the word.
But Dennis, welcome to the wonderful world of change proposals, where
you will experience insane amounts of pushback and debate on the
finest points of bikeshedding, whether or not people actually even
support the proposal at all...
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/UFV5CPYKJSRGOAOIHVZMBSQ3HY6B5VDE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Hygenic macros PEP.
On Wed, Sep 16, 2020 at 5:23 AM Mark Shannon wrote: > In general, I would except macros to be used within libraries, so that > those libraries gain the power of their custom macros without making > Python ever larger and more complex. > > However, there is no reason why they cannot be made more widely > available. Should a macro become widely used and popular, then it can be > considered for adoption into the language. I'd find both of those to be scary options, since there can be many many different versions of the macros in the wild, making Python into a nightmarish hodge-podge of different dialects. But with support like this, Python could be more easily prototyped; a proposed new syntactic feature could be played with by coding it up as a macro, before it's actually part of the language. Users would be encouraged to try it but NOT to publish code using it. If some feature then became a part of (say) Python 3.14, then the macro system could be used to backport it as far as possible. So I'm +0.75 on this, but not with the justification you've given :) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GEWCUFTCQJLTV2WF44BALX4CNJM2ZY46/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Hygenic macros PEP.
On Wed, Sep 16, 2020 at 5:31 AM Chris Angelico wrote: > Users would be encouraged to try it but > NOT to publish code using it. Clarification: by "publish" I mean in production, or as libraries that people will be depending on. It'd be on par with playing around in a fork of Python with the new feature, except that people can try it out without actually patching the C code. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WUZBXEHJFL7J6UKN7CNOODLB2QYNCHPA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Changing Python's string search algorithms
On Thu, Oct 15, 2020 at 11:38 AM Tim Peters wrote: > I think this is premature. There is almost never an optimization > that's a pure win in all cases. For example, on some platforms > `timsort` will never be as fast as the old samplesort in cases with a > very large number of equal elements, and on all platforms `timsort` > consumes more memory. And it's a wash on "random" data on most > platforms. Nevertheless, it was a significant speed win for many - > possibly even most - real-life cases. And timsort is one of my go-tos for teaching the concept of hybrid sorting algorithms, because, at its heart, it's simple enough to explain, and it manages to be so incredibly valuable in real-world code. :) > But it would leave open a different idea for an "opt-in" facility: one > that allowed to give a needle to a function and get back an object > capturing the results of preprocessing. Then a different wrapper > around the search code that accepted the already-pre-processed info. > There are, e.g., certainly cases where repeated searches for a given > 4-character needle could be sped significantly by exploiting the new > code, but where the overhead of preprocessing is too much to bear in > "random" performance testing. It would also open the door to more > aggressive (expensive) kinds of preprocessing. That's where users may > be able to make useful, informed judgments. Kinda like the way a compiled regex is used? I like this idea. So it'd be heuristics in the core language that choose a good default for most situations, and then a str method that returns a preprocessed needle. In a Python implementation that doesn't want to use two different algorithms, that preprocessor could return the string unchanged, but otherwise it's an opaque object usable only in string searches. +1, if my interpretation of your description is correct. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4MOC4RQDFPFGCF2OHUAK4YACGGYMTFGS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Changing Python's string search algorithms
On Sat, Oct 17, 2020 at 12:30 PM Tim Peters wrote: > > I don't plan on making a series of these posts, just this one, to give > people _some_ insight into why the new algorithm gets systematic > benefits the current algorithm can't. It splits the needle into two > pieces, u and v, very carefully selected by subtle linear-time needle > preprocessing (and it's quite a chore to prove that a suitable > splitting always exists!): > > needle == u + v > > [... more details...] Thank you, great explanation. Can this be added to the source code if/when this algorithm gets implemented? I've learned all kinds of things from the huge block comments about timsort, list growth, and the like. They make great reading when you're trying to figure out how to explain things (or if you're a bored nerd browsing for curiosity's sake - that works too!). ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7QZPJAELSJ426IF6TCVWACZ4P5RXEJMJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip
On Tue, Jun 2, 2020 at 8:55 PM Nick Coghlan wrote: > > > > On Tue., 2 Jun. 2020, 11:23 am Steven D'Aprano, wrote: >> >> >> >> > The conceptual idea here is that the "truncate" flag name would technically >> > be a shorter mnemonic for "truncate_silently", so clearing it gives you an >> > exception rather enabling padding behaviour. >> > >> > Flipping the sense of the flag also means that "truncate=True" will appear >> > in IDE tooltips as part of the function signature, providing significantly >> > more information than "strict=False" would. >> >> "Significantly" more? I don't think so. >> >> Truncate at what? >> >> - some maximum length; >> - some specific element; >> - at the shortest input. > > > Given that the only input parameters are the iterables themselves, it's a > stretch to even consider the first two as possibilities. > Why? I can conceivably imagine that zip(iter1, iter2, truncate=5) would consume at most 5 elements from each iterable. It's not much of a stretch. It doesn't happen to be what's proposed, but it's a reasonable interpretation. (Though then the default would probably be truncate=None to not truncate.) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7VDR7U53YPC5XPELHQ5TGZCJ74VIQ7KB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum and the Standard Library
On Sat, Sep 19, 2020 at 11:44 AM Guido van Rossum wrote: > Another brainstorm (or brainfart): maybe repr() should show the module/class > and the name, and str() should only show the name. We'd then get > ``` > >>> # Mock-up! > >>> print(str(re.i)) > IGNORE > >>> print(repr(re.i)) > re.IGNORE > >>> > ``` > and similar for Color.RED: > ``` > >>> # Another mock-up! > >>> print(str(Color.RED)) > RED > >>> print(repr(Color.RED)) > Color.RED > >>> > ``` > +1. There's actually a bit of a weird edge case with IntFlag at the moment, and this would bypass that, at least for the str(). >>> from enum import IntFlag, auto >>> class UF(IntFlag): ... CT_LOW_GRAVITY = auto() ... FLYING = auto() ... >>> UF.CT_LOW_GRAVITY | UF.FLYING >>> str(UF.CT_LOW_GRAVITY | UF.FLYING) 'UF.FLYING|CT_LOW_GRAVITY' The "UF." prefix is put on the start of the combined group, which means it's not actually evallable (for what it's worth), and it's that bit inconsistent. I'm absolutely fine with removing the classname altogether, so this would show as "FLYING|CT_LOW_GRAVITY". ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BEAZU4H3OS3PS45ZRZIVTPDGD7JSPGW7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano wrote: > > On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote: > > > Do you have any details to back this up? You're not just asking for a > > proposal to be accepted, you're actually asking for (quite a bit of) > > money, and then hoping to find a contractor to do the actual work. > > Payment is on delivery. At each stage, if the contractor fails to > deliver the promised gains, they get nothing. > > (I believe that Mark is being polite by referring to a generic > contractor. I think he is referring to himself.) It's a little unclear from the proposal, as there was something about whether a suitable contractor could be found, but sure. TBH I'd be happier with this proposal as a direct offer/request for money than as "hey let's go look for potential coders", but it sounds like that's the plan anyway? > > That means you're expecting that anyone would be able to achieve this, > > given sufficient development time. > > With sufficient time, maybe the horse will learn to sing. > > https://everything2.com/title/And+maybe+the+horse+will+learn+how+to+sing > > But I don't think Mark believes *anyone* will be able to improve > performance. If it were that easy that anyone could do it, Python would > already be blazingly fast. Yeah. And the "anyone" part is the concern I had - that the proposal was asking for funding and then for a search for a contractor. But if it's "pay me and I'll write this", then it's a bit more concrete. > > BIG BIG concern: You're basically assuming that all this definition of > > performance is measured for repeated executions of code. > > That's not what the proposal says. > > "Performance should improve for all code, not just loop-heavy and > numeric code." > > In fact Mark goes further: he says that he's willing to allow some > performance degradation on loop heavy code, if the overall performance > increases. "Overall performance" is a myth, and there's no way that CPython will magically be able to execute any code with the exact same performance improvement. So my question is: what happens to startup performance, what happens to short scripts, what happens to the interpreter's load times, etc, etc, etc? It could be that all code becomes faster, but only after it's been run a few times. That would be great for, say, a web app - it handles a request, goes back and waits for another, and then handles the next one a bit faster - but not for a command-line script. (And yes, I'm aware that it'd theoretically be possible to dump the compiler state to disk, but that has its own risks.) > > What would happen if $2M were spent on improving PyPy3 instead? > > Then both of the PyPy3 users will be very happy *wink* > > (I know, that's a terrible, horrible, inaccurate slight on the PyPy > community, which is very probably thriving, and I would delete it if I > hadn't already hit Send.) Yes, you're being horribly insulting to the third user of PyPy3, who is probably right now warming up his interpreter so he can send you an angry response :) I guess my biggest concern with this proposal is that it's heavy on mathematically pure boasts and light on actual performance metrics, and I'm talking here about the part where (so we're told) the code is all done and it just takes a swipe of a credit card to unlock it. And without the ability to run it myself, I can't be sure that it'd actually give *any* performance improvement on my code or use-cases. So there's a lot that has to be taken on faith, and I guess I'm just a bit dubious of how well it'd fulfil that. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4N4SSXNDAP2GZQSL7F2JBC2RJVZ3WEL6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote: > > Hi everyone, > > CPython is slow. We all know that, yet little is done to fix it. > > I'd like to change that. > I have a plan to speed up CPython by a factor of five over the next few > years. But it needs funding. > > The overall aim is to speed up CPython by a factor of (approximately) five. > We aim to do this in four distinct stages, each stage increasing the speed of > CPython by (approximately) 50%. > This is a very bold estimate. Particularly, you're proposing a number of small tweaks in stage 2 and expecting that (combined) they can give a 50% improvement in overall performance? Do you have any details to back this up? You're not just asking for a proposal to be accepted, you're actually asking for (quite a bit of) money, and then hoping to find a contractor to do the actual work. That means you're expecting that anyone would be able to achieve this, given sufficient development time. BIG BIG concern: You're basically assuming that all this definition of performance is measured for repeated executions of code. That's how PyPy already works, and it most often suffers quite badly in startup performance to make this happen. Will your proposed changes mean that CPython has to pay the same startup costs that PyPy does? What would happen if $2M were spent on improving PyPy3 instead? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3NBP3KLTMXNDJ2ME4QPSATW2ZIMKVICG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano wrote: > A minor point, and I realise that the costs are all in very round > figures, but they don't quite match up: $2 million split over five > stages is $400K per stage, not $500K. The proposal is for four stages. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DFFCUKWRBR557SWJEQPUFV6WEKWLFKKR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: os.scandir bug in Windows?
On Tue, Oct 27, 2020 at 10:00 AM Greg Ewing wrote: > > On 27/10/20 8:24 am, Victor Stinner wrote: > > I would > > rather want to kill the whole concept of "access" time in operating > > systems (or just configure the OS to not update it anymore). I guess > > that it's really hard to make it efficient and accurate at the same > > time... > > Also it's kind of weird that just looking at data on the > disk can change something about it. Sometimes it's an > advantage to *not* have quantum computing! > And yet, it's of incredible value to be able to ask "now, where was that file... the one that I was looking at last week, called something about calendars, and it had a cat picture in it". Being able to answer that kinda depends on recording accesses one way or another, so the weirdnesses are bound to happen. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZMNVRGZ7ZEC5EAKLUOX64R4WKHOLPF4O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PyPy performance stats (was Re: Speeding up CPython)
On Tue, Oct 27, 2020 at 2:42 AM Matti Picus wrote: > > > On 10/21/20 2:38 PM, Matti Picus wrote: > > On 10/21/20 20:42:02 +1100 Chris Angelico wrote: > > > >> When I go looking for PyPy performance stats, everything seems to be > >> Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or > >> whichever specific version)? Or maybe it's right there on > >> https://speed.pypy.org/ and I just can't see it - that's definitely > >> possible:) > >> > >> ChrisA > > > > > > They are not on the front page. You can find them, but it requires > > digging around in the Comparison page[0]. > > > > I guess we could switch to emphasizing python3 on the front page, help > > in updating and reconfiguring Codespeed [1] would be awesome. > > > > Matti > > > > > > [0] https://speed.pypy.org/comparison/ > > > > [1] https://github.com/python/codespeed/tree/speed.pypy.org > > > > Just as a follow up: the front page of speed.pypy.org now shows the > latest pypy 3.6 vs cpython 3.6.7. > Thank you! Good to see! ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E357UBOFRIIGWI64ZWOIADN65UQJAQ5K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On Fri, Jul 3, 2020 at 4:09 AM David Mertz wrote: >> An issue is that commit messages are uneditable after merge, so something >> written somewhere suggesting consideration of this would be a good idea, >> with authors/mergers bearing this in mind, however unusual a change on this >> basis would be. This would be additional burden on the core dev team, but if >> commitment is to be made to inclusivity, it might be what's necessary. > > > I don't think so. > https://docs.github.com/en/github/committing-changes-to-your-project/changing-a-commit-message. > Interactive rebasing is perfectly possible, isn't it. I admit my git-fu > isn't that strong, but I've done something that I *think* is the same as > this. It's possible I'm missing some distinction between the trees I've > modified and the current one, but I don't think so. > When you do that sort of rewriting, you're constructing a new and independent history and then saying "hey, this is the history I want everyone to respect now, thanks". It's full-on Back To The Future stuff, and can have annoying or serious consequences with everyone who has a clone or fork of the repo. It would be extremely annoying to anyone who has an open PR at the time of the rewrite, but the annoyance would be temporary (hopefully one-off). ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A2XBFOH5WGEOASSXHHKRWEHMZBN625SU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On Fri, Jul 3, 2020 at 5:17 AM Ivan Pozdeev via Python-Dev wrote: > > > On 02.07.2020 21:20, Chris Angelico wrote: > > On Fri, Jul 3, 2020 at 4:09 AM David Mertz wrote: > >>> An issue is that commit messages are uneditable after merge, so something > >>> written somewhere suggesting consideration of this would be a good idea, > >>> with authors/mergers bearing this in mind, however unusual a change on > >>> this basis would be. This would be additional burden on the core dev > >>> team, but if commitment is to be made to inclusivity, it might be what's > >>> necessary. > >> > >> I don't think so. > >> https://docs.github.com/en/github/committing-changes-to-your-project/changing-a-commit-message. > >> Interactive rebasing is perfectly possible, isn't it. I admit my git-fu > >> isn't that strong, but I've done something that I *think* is the same as > >> this. It's possible I'm missing some distinction between the trees I've > >> modified and the current one, but I don't think so. > >> > > When you do that sort of rewriting, you're constructing a new and > > independent history and then saying "hey, this is the history I want > > everyone to respect now, thanks". It's full-on Back To The Future > > stuff, and can have annoying or serious consequences with everyone who > > has a clone or fork of the repo. > > > > It would be extremely annoying to anyone who has an open PR at the > > time of the rewrite, but the annoyance would be temporary (hopefully > > one-off). > > > If you are talking about rewriting the PEP8 commit, it has proven to cause so > much damage that this is warranted despite the inconveniences IMO. > I think I agree. The consequences would be notable, but not untenable. There's a lot of debate still, but I think that if the commit message were amended (and the commit diff kept as it currently is), there could be a non-vitriolic discussion about whether or not to include any further stipulations about the quality of English used. (Which might result in no change at all. That's a valid conclusion.) Formal proposal: Either request a new commit message from the original author, or have someone rewrite it, and we go ahead and make the change. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NOJE4SL3GTYH4U5WYXMWA4POJDSJSLEQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Wed, Jul 8, 2020 at 10:45 AM Greg Ewing wrote: > > On 8/07/20 12:24 pm, Daniel Moisset wrote: > > Many people in this thread have argued that the double meaning in the > > PEP might be confusing, but Python already has a double meaning in other > > places. > > But assignment targets have always been clearly separated by > being on the left of an assignment operator, either = or :=. > The PEP proposes to intermingle them, with only very subtle clues, > such as the presence or absence of dots, to distinguish them. > Part of the point of the post you responded to is that assignment targets can be found in other contexts too - "for x[0] in iter:" uses x[0] as an assignment target, and there's no equals sign to be seen. You're right about the presence/absence of a dot being very subtle, but hang tight, wait for the next publication of the PEP; its authors are working on that exact problem. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/N4DJC5LOZH6T5NIJ32CDDSPQAAC4K24G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On Wed, Jul 8, 2020 at 6:17 PM Inada Naoki wrote: > > Since this is very new system, can we have some restriction > to allow aggressive optimization than regular Python code? > > # Class Pattern > > Example: > > match val: > case Point(0, y): ... > case Point(x, 0): ... > case Point(x, y): ... > > * Can VM cache the "Point" at first execution, and never lookup in > next time? (e.g. function executed many times) I'd prefer not - that seems very confusing. > # Constant value pattern > > Example: > > match val: > case Sides.SPAM: ... > case Sides.EGGS: ... > > * Can VM cache the value of "Sides.SPAM" and "Sides.EGGS" for next execution? > Similar, but with the additional consideration that you can create a "pre-baked pattern" by using a dict, so if you're worried about performance, use the slightly uglier notation (assuming that Sides.SPAM and Sides.EGGS are both hashable - and if they're not, the risk of prebaking is way too high). > * Can VM lookup "Point" only once per executing `match`, instead three times? > * Can VM lookup "Sides" only once, instead of two? These two I would be less averse to, but the trouble is that they make the semantics a bit harder to explain. "Dotted names are looked up if not already looked up, otherwise they use the same object from the previous lookup". If you have (say) "case socket.AddressFamily.AF_INET", does it cache "socket", "socket.AddressFamily", or both? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IR5UUBLXBAZDT45MGYD2CX42K2R7Z5LB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On Wed, Jul 8, 2020 at 8:56 PM Inada Naoki wrote: > > On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote: > > > > > > These two I would be less averse to, but the trouble is that they make > > the semantics a bit harder to explain. "Dotted names are looked up if > > not already looked up, otherwise they use the same object from the > > previous lookup". If you have (say) "case > > socket.AddressFamily.AF_INET", does it cache "socket", > > "socket.AddressFamily", or both? > > > > I meant "It is implementation detail" and "User must not rely on side effects > of attribute access." > Fair enough. I wouldn't mind that, it seems like a nice optimization that would only harm code that would be extremely confusing to read anyway. But only within one matching - caching beyond that seems more dangerous. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XORPYNPF2ZNS6YX6AHXXBHMC6VQEYD5V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On Fri, Jul 3, 2020 at 10:10 AM Łukasz Langa wrote: > Commit messages aren't usually scrutinized to this extent. If you looked at > the last 1000 commits in cpython, you'd find quite a few with messages that > could be seriously improved. We don't though because commits are immutable. > You can revert them but we never downright replace them with different ones. > Otherwise what's the point in me signing release tags? > True, but very few of them have caused such controversy as this. And I don't believe anyone signs release tags on the PEPs repository (correct me if I'm wrong?), and it has far fewer forks and generally shorter-lived ones than CPython has. I am NOT advocating commit rewriting on CPython itself. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LFXOHCAO5RTIRGQQQIR4IWZY5YVLY2F5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Sun, Jul 5, 2020 at 12:03 PM Shantanu Jain wrote: > - Finally, I did mention increasing the scope of constant value patterns to > accommodate expressions (as opposed to just dotted names). If we were to do > this, it’s a reason to prefer some syntaxes for constant value patterns over > others. > I'm kinda theoretically in favour of expressions, but only the sort that logically "feel" like constants. Unary minus and the addition of real and imaginary parts are already supported, so what's still of value? IMO exponentiation of 2 is usually better spelled in hex (instead of 2**10, use 0x400, unless there's good reason), and since you can have underscores to break up an integer, that handles powers of 10 as well. What notations would you want to use? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/T24W2FZ6UY36CI2GP4LKGBSLSHBYH4K3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Sat, Jul 4, 2020 at 12:48 AM Rob Cliffe via Python-Dev wrote: > > Whoa! > > I have an uneasy feeling about this PEP. > > AFAIK the usual procedure for adding a new feature to Python is: > An idea is raised and attracts some support. > Someone sufficiently motivated writes a PEP. > The PEP is thoroughly discussed. > Eventually a consensus (or at least an "agree to differ" stalemate) > is reached. > The PEP is accepted (if it is). > (Then and only then) Someone works on the implementation. > etc. > > However, PEP 622 only seems to have been presented to the Python > community only *after* a well-developed (if not finalised) > implementation was built. A fait accompli. The PEP is still a draft and has not been accepted. Don't worry, the normal process is still happening :) Having a reference implementation is a HUGE help, because people can play around with it. There's a fork running an interactive playground so you can go right now and get a feel for the way the syntax works. The implementation has *not* been merged into the CPython trunk. It's not a fait accompli - it's a tool to help people evaluate the proposal (and all of the different variants of the proposal as it evolves). Speaking with my PEP Editor hat on, I would be *thrilled* if more proposals came with ready-to-try code. Only a very few have that luxury, and a lot of the debating happens with nothing but theory - people consider what they *think* they'd do, without actually being able to try it out and see if it really does what they expect. Having a reference implementation isn't necessary, of course, but it's definitely a benefit and not a downside. Also, there HAVE been proposals with full reference implementations that have ended up getting rejected; it's not a guarantee that it'll end up getting merged. Hope that lessens your fears a bit :) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E5U5Z6RRWSWHGXTZEQ6CBPORVXS3CPWD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev wrote: > > > On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote: > > On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev wrote: >> >> So what? > > Unnecessary >> >> They'll have to synchronise their history to ours to be able to make a PR. >> And if they don't, it doesn't matter for us what they do with the data >> anyway since they are responsible for maintaining it and keeping it relevant >> if they need to, not us > > That is not a very collaborative mindset. > > > I fail to see how. We provide all the tools to collaborate. If a person has a > divergent history, they will see that when trying to collaborate (submit a PR > or otherwise interact with our repo from theirs in any way) and will be able > to fix that problem then and there. > > > Can somebody give an example of when we force-pushed before? Surely there > should be a PEP outlining when we force push and how we communicate this to > our "consumers" before/when we do so? > Even if someone isn't aware of the change, the PEPs repo *already* rewrites commits as they get merged, so any discrepancies would be papered over cleanly. Consider: https://github.com/python/peps/pull/1488 Two commits in the pull request https://github.com/python/peps/commit/045450aaf47941f3ee7daaa1774947b31885b2aa One commit in the final repo. If someone has the old version of the repo and creates a pull request, we'll just squash all the differences down and create a single commit that does the intent in a cleaner way. The only real effect will be a bit of noise during the PR process itself. There has ALREADY been far more hassle resulting from this commit message than there would be from a force-push. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W3UOLWJZHRLJA75PJZ5O434FPPLBZMLQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On Sun, Jul 12, 2020 at 11:04 AM Guido van Rossum wrote: > > On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico wrote: >> >> On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing >> wrote: >> > >> > Just had another thought about marking assignment targets. >> > >> > The PEP currently forbids repeating bound names in a pattern >> > to avoid raising expectations that >> > >> > case Point(x, x): >> > >> > would match only if the two arguments were equal. >> > >> > But if assignment targets were marked, we could write this as >> > >> > case Point(?x, x): >> > >> > and it would work as expected. >> >> Hang on. Matching happens before assignment, so this should use the >> previous value of x for the matching. At least, that's my >> understanding. If you do something like: >> >> case Point(x, 2): >> >> it won't assign x unless the second coordinate is 2, right? > > > Good catch. That's actually undefined -- we want to let the optimizer have > some leeway in how to generate the best code for matching. See > https://www.python.org/dev/peps/pep-0622/#performance-considerations > > Currently it doesn't optimize all that much -- it just processes patterns > from left to right: > ``` > >>> match Point(3, 3): > ... case Point(x, 42): pass > ... > >>> print(x) > 3 > >>> > ``` > Ah, okay. My "obvious" intuition was that this wouldn't assign, and Greg's equally "obvious" intuition was that it would. I think that disagreement should be a strike against the "Point(?x, x)" notation - I can't be the only person who would misinterpret it. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DT2RBMJ2BO2FG5PBWCNGID2DPYYMVQV5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing wrote: > > Just had another thought about marking assignment targets. > > The PEP currently forbids repeating bound names in a pattern > to avoid raising expectations that > > case Point(x, x): > > would match only if the two arguments were equal. > > But if assignment targets were marked, we could write this as > > case Point(?x, x): > > and it would work as expected. > Hang on. Matching happens before assignment, so this should use the previous value of x for the matching. At least, that's my understanding. If you do something like: case Point(x, 2): it won't assign x unless the second coordinate is 2, right? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C3L6EUY5SAMWHSDOHNQJLWXPUJ67A4AQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Recent PEP-8 change
On Thu, Jul 2, 2020 at 7:27 PM Antoine Pitrou wrote: > Otherwise why stop at English? I could just as well write my comments > in French if it's all about individual freedom. Requiring English is > not inclusive, it forced people like me to painfully adapt to a > language I wasn't used to. And that has nothing to do with "white > supremacy". True, but "inclusive" isn't just about the people *writing*. If you write your comments in French, and someone else uses Turkish, another uses Japanese, and still another opts for Hebrew, it becomes nearly impossible for anyone to *read* those comments. Standardizing on a single language ensures that everyone can read the comments in a single, consistent language. If we want to be completely fair to everyone, we could insist that comments be written in Latin. That way, nobody gets a "home turf" advantage, and we're all going to the effort of translation... but I'm sure you agree that this wouldn't be an improvement to Python :) So if there's going to be one language chosen, logically it should be a language that is familiar to many people. That means that Mandarin Chinese, Spanish, and English, I believe, would be the most favoured choices. Chinese has the toughest demands on input methods, and between Spanish and English, I'd need to hear from someone whose first language is Spanish as to how viable it would be. But it's still necessary to standardize on just one. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GUNLZDGNHZXQPMTCONR5MY3HP2NG52TH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Wed, Jun 24, 2020 at 3:49 PM Ethan Furman wrote:
>
> On 06/23/2020 10:31 PM, Chris Angelico wrote:
> > On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote:
> >> On 06/23/2020 09:01 AM, PEP 622 wrote:
> >>
> >>> from enum import Enum
> >>>
> >>> class Color(Enum):
> >>> BLACK = 1
> >>> RED = 2
> >>>
> >>> BLACK = 1
> >>> RED = 2
> >>>
> >>> match color:
> >>> case .BLACK | Color.BLACK:
> >>> print("Black suits every color")
> >>> case BLACK: # This will just assign a new value to BLACK.
> >>> ...
> >>
> >> As others have noted, the leading dot to disambiguate between a name
> >> assignment and a value check is going to be a problem. I think it's also
> >> unnecessary because instead of
> >>
> >> case BLACK:
> >> blahblah()
> >>
> >> we can do
> >>
> >> case _:
> >> # look ma! BLACK is just "color"!
> >> BLACK = color # if you really want it bound to another name
> >>
> >> In other words, the PEP is currently building in two ways to do the same
> >> thing -- make a default case. One of those ways is going to be a pain;
> >> the other, once renamed to "else", will be perfect! :-) As a bonus, no
> >> special casing for leading dots.
> >>
> >
> > But what if that's composed into something else?
> >
> > class Room(Enum):
> > LIBRARY = 1
> > BILLIARD_ROOM = 2
> > ...
> >
> > match accusation:
> > case (Color.SCARLETT, Room.BILLIARD_ROOM):
> > print("Correct")
> > case (Color.SCARLETT, _):
> > print("Not there!")
> > case (_, Room.BILLIARD_ROOM):
> > print("Wrong person!")
> > case (_, _):
> > print("Nope. Just nope.")
> >
> > Without the dots, there's no way to tell whether you're matching
> > specific values in the tuple, or matching by length alone and then
> > capturing. You can't use the 'else' keyword for a partial match.
>
> Well, your example isn't using leading dots like `.BLACK` is, and your
> example isn't using `case _` as a final catch-all, and your example isn't
> using "case some_name_here" as an always True match. In other words, your
> example isn't talking about what I'm talking about. ;-)
>
But it IS using "_" as a catch-all. The simple "case _:" case is using
_ the same way that "case (Color.SCARLETT, _):" is.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/UGNM557U543RFPIOS2CCN7J3VVYIQ4SF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote:
>
> On 06/23/2020 09:01 AM, PEP 622 wrote:
>
> > from enum import Enum
> >
> > class Color(Enum):
> > BLACK = 1
> > RED = 2
> >
> > BLACK = 1
> > RED = 2
> >
> > match color:
> > case .BLACK | Color.BLACK:
> > print("Black suits every color")
> > case BLACK: # This will just assign a new value to BLACK.
> > ...
>
> As others have noted, the leading dot to disambiguate between a name
> assignment and a value check is going to be a problem. I think it's also
> unnecessary because instead of
>
> case BLACK:
> blahblah()
>
> we can do
>
> case _:
> # look ma! BLACK is just "color"!
> BLACK = color # if you really want it bound to another name
>
> In other words, the PEP is currently building in two ways to do the same
> thing -- make a default case. One of those ways is going to be a pain; the
> other, once renamed to "else", will be perfect! :-) As a bonus, no special
> casing for leading dots.
>
But what if that's composed into something else?
class Room(Enum):
LIBRARY = 1
BILLIARD_ROOM = 2
...
match accusation:
case (Color.SCARLETT, Room.BILLIARD_ROOM):
print("Correct")
case (Color.SCARLETT, _):
print("Not there!")
case (_, Room.BILLIARD_ROOM):
print("Wrong person!")
case (_, _):
print("Nope. Just nope.")
Without the dots, there's no way to tell whether you're matching
specific values in the tuple, or matching by length alone and then
capturing. You can't use the 'else' keyword for a partial match.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/TYKZU5HALAN3I72NBKE4QC3ZJI355DY7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Anti-PEP
On Mon, Jun 29, 2020 at 12:53 AM wrote: > > In my humble opinion, this doesn't warrant the creation of a new structure, > but rather a restructuring of PEPs. > > As mentioned by others, we have a "Rejected Ideas" section already, but that > seems to somewhat miss the point. It captures only the arguments that have > won, arguments moved against specific parts of the PEP which have managed to > overthrow that specific part. > "Rejected Ideas" is more about alternatives, not about why this entire proposal should be rejected. > I propose to expand this into a section (call it Anti-PEP if you like, though > I'd prefer something less arcane myself) that systematically approaches every > argument moved against the PEP as a whole and any specific part of it, > signalling the state of each objection (updated on a schedule, perhaps). > Yep! A number of PEPs have "Objections" sections. I think that'd be a good title for it. > This would achieve: > - Keeping everyone informed at a glance on every objection. > - Prevent duplicate objections, as you'd be aware of similar objections to > the one you want to raise and have your voice be heard there. > - Put all the pros and cons in one place, clearly labelled. > - Give a better overview of the objective arguments for and against: I > believe subjective and emotional motivations would end up being compressed by > the format in a way that would make it clear whether there is any value to > them. > Agreed. If a PEP author doesn't feel s/he can do justice to the Objections section, it would make very good sense to collaborate with someone of opposing view for that purpose. And if someone feels that the PEP author isn't properly representing the opposing views, raise the matter and ask the author to expand that section. I don't think we need any concept of "Anti-PEP", but I would definitely support a push to have a better "Objections" section in controversial PEPs. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UYAF5U3E27Z5XIC73VO6QHAJG3Z74B3L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup
On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou wrote: > > On Wed, 24 Jun 2020 12:38:52 -0700 > Guido van Rossum wrote: > > Everyone, > > > > If you've commented and you're worried you haven't been heard, please add > > your issue *concisely* to this new thread. Note that the following issues > > are already open and will be responded to separately; please don't bother > > commenting on these until we've done so: > > > > - Alternative spellings for '|' > > - Whether to add an 'else' clause (and how to indent it) > > - A different token for wildcards instead of '_' > > - What to do about the footgun of 'case foo' vs. 'case .foo' > > > > (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a > > variable binding and '?' for a wildcard.) > > I don't know if you read it, so I'll reiterate what I said :-) > > """ > Overall, my main concern with this PEP is that the matching semantics > and pragmatics are different from everything else in the language. > When reading and understanding a match clause, there's a cognitive > overhead because suddently `Point(x, 0)` means something entirely > different (it doesn't call Point.__new__, it doesn't lookup `x` in the > locals or globals...). Obviously, there are cases where this is > worthwhile, but still. > AIUI, the case clauses are far more akin to *assignment targets* than they are to expressions. If you see something like this: [x, y] = foo() then you don't expect it to look up x or y in the current scope, nor to construct a list. Is there any way to make the syntax look more like assignment? Or maybe this won't even matter - people will simply get used to it with a bit of experience, same as "for x, y in stuff" has an assignment target in it. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JGX7PZ6LMSDNS4OWQIJBWGGM6E7V4XO7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Wed, Jun 24, 2020 at 5:30 AM Rob Cliffe via Python-Dev wrote: > > The PEP is great, but this strikes me as horribly confusing, given that > 401|403|404 is already legal syntax. > IIUC any legal expression can come between `case` and `:`, but expressions > that contain `|` at their outermost level are interpreted differently than > from in other contexts. > Presumably adding parentheses: > case (401|403|404): > would make it equivalent to > case 407: > > Is a separator (other than whitespace) actually needed? Can the parser cope > with > case 401 403 404: > > Failing that IMO preferable, albeit not ideal, possibilities would be > 1) Use colon as the separator. > 2) Use comma as the separator - this is already legal syntax too, but IMO > it reads more naturally. > (And IIRC there are already contexts where brackets are necessary to > indicate a tuple.) > Perhaps someone can think of something better. > > I also (with others) prefer `else:` or perhaps `case else:` to using the`_` > variable. > The latter is obscure, and woudn't sit well with code that already uses that > variable for its own purposes. > It's not really arbitrary expressions, though. It's more like an assignment target list, but with some handling of constants. case (x, y): is very similar to (x, y) = ... There is the definite risk of confusion with 'if' statements, because you can say "case 401|403|404:" but you can't say "if x == 401|403|404:", and people already try to do that (usually with the 'or' keyword). I think the risk is worth it, given the expressiveness gained, but I can see the line of argument that it's going to cause confusion. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GEMFLQCNZG3WPZYTBNC54S4A3XLIUMPR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Wed, Jun 24, 2020 at 2:04 AM Guido van Rossum wrote: > def http_error(status): > match status: > case 404: > return "Not found" > case 418: > return "I'm a teapot" > case _: > return "Something else" > > Note the last block: the "variable name" `_` acts as a *wildcard* and > never fails to match. I can't find it among the rejected alternatives, but was it considered to use "..." as the wildcard, rather than "_"? It carries similar meaning but its special case of "this will never be bound" is simply preventing an error, rather than making one otherwise-valid name special. > Raw strings and byte strings are supported. F-strings are not allowed (since > in general they are not really literals). It won't come up often, but are triple-quoted strings allowed? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OH4UXRFTPXG2JQFW44GZ2E2FGHYAC4LK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Wed, Jun 24, 2020 at 10:11 AM Guido van Rossum wrote: > > On Tue, Jun 23, 2020 at 4:41 PM MRAB wrote: >> >> On 2020-06-23 22:50, Barry Warsaw wrote: >> > On Jun 23, 2020, at 14:31, Chris Angelico wrote: >> > >> >> I can't find it among the rejected alternatives, but was it considered >> >> to use "..." as the wildcard, rather than "_"? It carries similar >> >> meaning but its special case of "this will never be bound" is simply >> >> preventing an error, rather than making one otherwise-valid name >> >> special. >> > >> > I thought of that too as I was reading the PEP, but forgot to add it to my >> > notes. I do like ellipsis more than underscore here. >> > >> +1 > > > The problem is that ellipsis already has a number of other meanings, *and* is > easily confused in examples and documentation with leaving things out that > should be obvious or uninteresting. Also, if I saw [a, ..., z] in a pattern I > would probably guess that it meant "any sequence of length > 2, and capture > the first and last element" rather than "a sequence of length three, and > capture the first and third elements". (The first meaning is currently > spelled as [a, *_, z].) > Ah, yes, very good point. Agreed. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QTB6GLWLB3BZU3I2PWF7TML73HF4LYRZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)
On Sat, Jun 13, 2020 at 3:50 AM Edwin Zimmerman wrote:
>
> My previous timings were slightly inaccurate, as they compared spawning
> processes on Windows to forking on Linux. Also, I changed my timing code to
> run all process synchronously, to avoid hitting resource limits.
>
> Updated Windows (Windows 7 this time, on a four core processor):
>
> >>> timeit.timeit('x=multiprocessing.Process(target=exit);x.start();x.join()',
> >>> number=1000,globals = globals())
> 84.7111053659259
>
Thanks, I was actually going to ask about joining the processes, since
you don't really get a good indication of timings from asynchronous
operations like that. Another interesting data point is that starting
and joining in batches makes a fairly huge difference to performance,
at least on my Linux system. Starting with your example and rescaling
the number by ten to compensate for performance differences:
>>> timeit.timeit('x=multiprocessing.Process(target=exit);x.start();x.join()',
>>> number=1,globals = globals())
14.261007152497768
Just for completeness and consistency, confirmed that adding a list
comp around it doesn't change the timings:
>>> timeit.timeit('xx=[multiprocessing.Process(target=exit) for _ in
>>> range(1)];[x.start() for x in xx];[x.join() for x in xx]',
>>> number=1,globals = globals())
14.030426062643528
But doing a hundred at a time and then joining them all cuts the time in half!
>>> timeit.timeit('xx=[multiprocessing.Process(target=exit) for _ in
>>> range(100)];[x.start() for x in xx];[x.join() for x in xx]',
>>> number=100,globals = globals())
5.470761131495237
The difference is even more drastic with spawn, although since it's
slower, I also lowered the number of iterations.
>>> ctx = multiprocessing.get_context('spawn')
>>> timeit.timeit('x=ctx.Process(target=exit);x.start();x.join()',
>>> number=1000,globals = globals())
40.82687543518841
>>> timeit.timeit('xx=[ctx.Process(target=exit) for _ in range(100)];[x.start()
>>> for x in xx];[x.join() for x in xx]', number=10,globals =
>>> globals())8.566341979429126
8.566341979429126
Would be curious to know if that's the same on Windows.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/YFRM3LNO37B5JXNYPO2T7CAVYQRGAYES/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno wrote: > Tools should adapt to the language, not the other way around. If things had > to be done the way they had always been done, without any change, for fear of > people not being used to it, we wouldn't even have Python at all. People > learn and adapt. It seems like a small price to pay in exchange for > consistency and removal of ambiguity, considering people will still have to > learn the new feature one way or another. > But consistency is exactly what you'd be destroying here. Python is extremely consistent in that you ALWAYS indent after a line ends with a colon, and what comes after it is logically contained within that statement. It's about whether *people* can handle it, more than whether tools can, and the consistency helps a lot with that. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S56BYBQIWTV2SQYBTYT3ZRPNI7CLF5MR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Function suggestion: itertools.one()
On Tue, Jul 28, 2020 at 5:24 AM Steven Barker wrote: > > A single-name unpacking assignment can do exactly what you want, albeit with > slightly less helpful exception messages: > > jack, = (p for p in people if p.id == '1234') # note comma after the name > jack > Agreed. As a minor readability refinement, I would prefer to spell this with square brackets: [jack] = (p for p in people if p.id == '1234') The effect is identical, but for the one-item unpack, I prefer not to have the vital-but-subtle trailing comma. (You can use square brackets on larger assignment lists too, but they don't add anything.) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/62ZAKSHT6VHT66CHFBPJHHAUQSW2S3DK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)
On Sat, Aug 15, 2020 at 12:32 AM Mark Shannon wrote: > > Hi all, > > I've written up a critique of PEP 622. > Rather than dump a 2000 line email on you all, I've made a git repo. > > https://github.com/markshannon/pep622-critique > I started reading it. You're saying the same things that everyone else has said, so I stopped reading. Do you have anything new to add to the discussion, or is this 2000 lines of rehash? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MVNBDQDYFOLEU3PQ5OFP25T7VACUZOL3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On Tue, Jan 12, 2021 at 4:22 AM Larry Hastings wrote: > > > I've written a new PEP. Please find it below. Happy reading! > Can this get added to the PEPs repo and assigned a number and such? BTW, the currently preferred wording for the copyright blurb is slightly different. If you're the sole author of this text, can you please consider the license terms shown in PEP 12? ChrisA PEP editor - if you need a hand, I'm here to help ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QPVFGPHFGODJ4AJLLYFIGPKIYCKK2KPW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann wrote:
>
>
> On 1/8/21 4:31 PM, Mats Wichmann wrote:
> >
> >
> > Someone reported a testsuite break on stuff I work on (scons) with
> > 3.10a4, and it looks similar to this which appears in the changelog at
> >
> > https://docs.python.org/3.10/whatsnew/changelog.html#changelog
> >
> > bpo-23898: Fix inspect.classify_class_attrs() to support attributes with
> > overloaded __eq__ and __bool__. Patch by Mike Bayer.
> >
> > Except when I go look at that BPO issue, it's old - closed 2015. Is
> > this appearing in the 3.10 changelog in error? Sorry - confused !!!
>
> okay, that was silly, I didn't realize the changelog was cumulative over
> many versions, so that entry was not for 3.10 at all (teach me to do
> searching in browser window, where it just flies right past any section
> headings so I miss it was for a different version :) ).
>
> > The test in question does indeed touch a class which overrides __bool_
> > in order to raise an exception (to say "don't do that"), and in the test
> > run the (expected) exception is not raised.
>
> So updated information: the test in question is checking if a class (A)
> has an attribute using a truth test, where the attribute's value is an
> instance of another class (B) and expecting that that will cause the
> __bool__ method to be called. [aside: this test is done to validate that
> a class which really doesn't want this kind of test indeed rejects it]
> That apparently no longer happens, if it's wrapped in a try block ???
> Distilled down to simple case:
>
> class A:
> pass
>
> class B:
> def __bool__(self):
> raise AttributeError("don't do that!")
>
> a = A()
> b = B()
> a.b = b
> # expect this to cause b.__bool__ to be called
> if a.b:
> print("Found it!")
>
> and it raises the exception. But when protected:
>
> try:
> if a.b:
> pass
> except AttributeError:
> print("Got expected exception")
> else:
> print("Missed expected exception")
>
> it won't trigger. But if I add a "real" statement in the block following
> the "if", then it's back to the pre-3.10 behavior of calling __bool__:
>
> try:
> if a.b:
> dummy = True
> except AttributeError:
> print("Got expected exception")
> else:
> print("Missed expected exception")
>
>
> Any thoughts on this?
Oooh interesting. I tried on a build of 3.10 from October and:
1) The unguarded version bombed out with an exception
2) The "if... pass" version reported that it got the exception
3) The "if... dummy" version reported that it got the exception
ie every one of them did indeed raise. But on a fresh build from the
master branch, I got the same results you did. That means the change
happened some time between commit 497126f7ea and commit ace008c531, an
800ish commit span.
I'll start bisecting to try to track this down. It looks like "if a.b:
pass" is getting partially optimized out; the disassembly shows a
being loaded, its attribute b being looked up, and then it just jumps
to the else - there's no POP_JUMP_IF_FALSE as there is when there's a
bit of actual code in there.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/K2LD2L5RF2ZFUYEXQ3Z5U4TY5QBRFPCQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On Tue, Jan 12, 2021 at 5:10 AM Larry Hastings wrote: > > > Certainly. I'm just another victim in the copy-and-paste wars. > Ah yes, the Battle of the Clipboard. Iconic, epic, such a glorious engagement! But the casualties were steep. Fortunately we can rebuild. > I actually have write access to the PEPs repo (I'm a former release manager) > so I'd be happy to check it in myself once it gets a number, however that > happens. Before I do so I'll study PEP 12 as if it was gonna be on > tomorrow's midterms. > Number allocation is pretty informal. Go ahead and grab PEP 649; in the unlikely event that someone else pushes a commit creating that PEP before you get to it, grab PEP 650 instead :) I'm happy to help out if you need me, but it sounds like you got this! ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/F65N4HBJZFTZL2VNFV77ZTJN4RVPCHWU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally
On Tue, Jan 12, 2021 at 12:56 PM Larry Hastings wrote: > > It was a balancing act. Using an 64-byte empty dict per object with no > defined annotations seems so wasteful. And anything short of an empty dict, > you'd have to guard against. Current code already has to guard against > "__annotations__ aren't set" anyway, so I figured the cost of migrating to > checking a different condition would be small. And None is so cheap, and the > guard is so easy: > > if o.__annotations__: > Does it have to be mutable? If not, maybe there could be a singleton "immutable empty dict-like object", in the same way that an empty tuple can be put anywhere that expects a sequence. That'd be as cheap as None (modulo a once-per-interpreter cost for the additional static object). ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TWBC545KC7CK3DS5JZL4WBJM4BXZZBTI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis
On Tue, Nov 24, 2020 at 7:00 AM Ethan Furman wrote:
>
> On 11/23/20 11:06 AM, Larry Hastings wrote:
> > On 11/23/20 8:15 AM, Brian Coleman wrote:
> >> def process(root_node: Node):
> >> def process_node(node: Node):
> >> if isinstance(node, StringNode):
> >> return node.value
> >> elif isinstance(node, NumberNode):
> >> return float(node.value)
> >> elif isinstance(node, ListNode):
> >> return [process_node(child_node) for child_node in
> node.children]
> >> elif isinstance(node, DictNode):
> >> return {key: process_node(child_node) for key, child_node in
> node.children}
> >> else:
> >> raise Exception('Unexpected node')
> >
> > You don't need the "else".
>
> Without the "else" errors will pass silently.
>
> > And you can change all your "elif"s into "if"s too.
>
> On average, doubling your comparisons and therefore becoming slower.
I think the implication is that, since all the successful if
statements go into returns, you can leave off the "else" and just put
the "raise" immediately. It's a special case that applies ONLY to
situations where the pattern matching is the entire purpose of the
function.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/5XN74AAVN2MITMG574LNCDBZJCP2LN76/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote: > > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture > patterns. This is by far the clearest and easiest to read form I've seen thus > far, and I suspect that it would be the easiest to explain to users already > familiar with usage of "as" from other areas in Python. A new feature being > as distinguishable as possible and easy to explain to existing users is very > important in my book, and based on the responses, I think that the current > "=" form used in PEP 634 for matching class patterns would be substantially > more difficult for users to mentally parse and understand compared to "as". > > It's also worth considering new Python users that might have general OO > experience but not with robust pattern matching (e.g. Java-heavy > backgrounds). I could definitely see "case Point(x=a, y=b):" being confused > for instantiation, whereas usage of "as" makes it more clear that something > else is happening (hopefully leading them to search around for more info > about Python pattern matching). > case Point(x=as a, y=as b): That doesn't read well to me. Or is there some other spelling of 'as' that makes better sense to you? ChrisA (why am I responding to this topic? I'm really not sure.) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SJ23TYZCYIYCBHFKKKVVEX4MQB726YXM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?
On Tue, Nov 17, 2020 at 9:44 PM Steven D'Aprano wrote: > `try...except` is no different. > ... > The only wrinkle in the case of `try...except` is that the error > variable is deleted, even if it wasn't actually used. If you look at the > byte-code generated, each compound try...except with an exception > variable is followed by the equivalent of: > > err = None > del err > > > There really ought to be a FAQ about this, but it has something to do > with the exception object forming a long-lasting reference cycle. To > avoid that, the error variable is nuked on leaving the compound block. That's a much bigger wrinkle than it might seem at first, though, and I agree, this is a quite literal frequently-asked-question and should be made clear somewhere. The except clause is special in that, if you want the exception afterwards, you have to reassign it to another variable; but it doesn't ACTUALLY introduce a subscope, despite kinda looking like it does. Interestingly, Python 3.10 has a very odd disassembly: >>> def f(): ... try: g() ... except Exception as e: ... print(e) ... >>> import dis >>> dis.dis(f) 2 0 SETUP_FINALLY 10 (to 12) 2 LOAD_GLOBAL 0 (g) 4 CALL_FUNCTION0 6 POP_TOP 8 POP_BLOCK 10 JUMP_FORWARD44 (to 56) 3 >> 12 DUP_TOP 14 LOAD_GLOBAL 1 (Exception) 16 JUMP_IF_NOT_EXC_MATCH54 18 POP_TOP 20 STORE_FAST 0 (e) 22 POP_TOP 24 SETUP_FINALLY 20 (to 46) 4 26 LOAD_GLOBAL 2 (print) 28 LOAD_FAST0 (e) 30 CALL_FUNCTION1 32 POP_TOP 34 POP_BLOCK 36 POP_EXCEPT 38 LOAD_CONST 0 (None) 40 STORE_FAST 0 (e) 42 DELETE_FAST 0 (e) 44 JUMP_FORWARD10 (to 56) >> 46 LOAD_CONST 0 (None) 48 STORE_FAST 0 (e) 50 DELETE_FAST 0 (e) 52 RERAISE >> 54 RERAISE >> 56 LOAD_CONST 0 (None) 58 RETURN_VALUE >>> Reconstructing approximately equivalent Python code, this would mean it looks something like this: def f(): try: g() except Exception as e: try: print(e) e = None del e raise finally: e = None del e except: raise return None I don't understand why (a) the "e = None; del e" part is duplicated, nor (b) why the RERAISE opcodes are there in two branches, but I guess it works out best to be explicit in there? Anyhow. You say that this can't come up very often because people can go a long time without asking, but the trouble is that there are two false interpretations that are both extremely close - either that "except E as e:" is similar to "with E as e:", or that the except clause creates its own scope. It's entirely possible to see supporting evidence for your own wrong assumption and never actually know the truth. Maybe this is going to be the next "Python has call-by-value" vs "Python has call-by-reference" debate? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6NKGXWLRX3SD4JQDFCOR43TAXREC33GD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?
On Wed, Nov 18, 2020 at 4:08 AM Richard Damon wrote: > > One comment about having the exception handler 'save state' and restore > it is that frequently the purpose of the exception handler is TO make > changes to outer variable to fix things up based on the exception. > > I could see the desire of a way to create an internal scope of sorts and > create names limited to that scope, but wouldn't want such a scope being > anywhere automatic, and likely what would make more sense is defining a > particular name (or names) to have a limited scope. The ONLY variable that would be special is the one named in the "except Exc as e:" clause. Everything else would follow the normal rules. This is the only variable that is currently special, and ti'd be the only one that ever needs to be special (since it has the refloop that makes memory management harder). ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6O2YYUF7M5PZNZQX7EVYU4U7KTJ7QUHB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?
On Wed, Nov 18, 2020 at 8:38 AM Steven D'Aprano wrote: > To start with, what else are they using "e" for? Surely it would be more > important to use a better name *there* rather than change the exception > variable. 2.718281828? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CNXCWVJA7C7POXFV7VHNM64O22NQ54KN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
On Tue, Nov 10, 2020 at 3:19 AM Simon Cross wrote: > > I really enjoyed learning from this "user manual with a strong > narrative component" so I would personally like to see it stay even if > a new tutorial is created for a different kind of audience. If that were to happen, what I'd prefer is to cut lots of info out of the *TUTORIAL* and make a new document called, say, *Python Advanced Techniques* or something, which could still have the narrative style but would be aimed at people who know how to use basic functionality and are looking to learn more. The name "tutorial" definitely screams "thing you should go through first". It shouldn't have to teach you everything. Keep the tutorial simple. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/J4P3ACWDJYCQ2MN3KMTR3D76TYHNULKV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
On Tue, Nov 10, 2020 at 3:38 AM Guido van Rossum wrote: > > Do you want to join the docs WG? IIUC it’s open to new members. (Carol?) > Me personally, or members of this conversation in general? My life is a bit too chaotic at the moment to take on more responsibilities, although I might reconsider in mid 2021. But don't let that stop anyone else who's interested. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HX2XLUBI2MAV5P4NIAIL2VR45KAUHSNQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On Tue, Nov 3, 2020 at 8:53 AM Glenn Linderman wrote: > > On 11/2/2020 1:42 PM, Guido van Rossum wrote: > > But we feel that `case x, x` can easily be misunderstood as "a tuple > > of two equal values" > > So what _is_ the syntax for "a tuple of two equal values" ? > > case x, ?x: # comes to mind (not that it is in the PEP :)) case x, y if x == y: If it gets a lot of demand, a dedicated syntax can be added in the future without breaking anything. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/574IVLKJKR2JF455MRRHUH23V7HEXX4I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)
On Sat, Oct 31, 2020 at 5:31 AM Mark Shannon wrote: > > It's right here that you lose me. Anyone who reduces pattern matching to "a > > fancy switch statement" probably isn't the right person to be discussing > > its semantics and usefulness with. It seems that some people just can't > > separate the two ideas in their mind. It's like calling a class a "fancy > > module". > > Pattern matching is a fancy switch statement, if you define "fancy" > appropriately ;) > > Reducing pattern matching to some sort of switch statement is exactly > what a good implementation should do. It's what compilers are for. > The comparison seems entirely reasonable to me. "What compilers are for" is turning useful high level constructs into low level executable forms. I don't think anyone would say that a for loop is just a fancy GOTO, even though it gets compiled into one. I don't care how the compiler represents something; I care how I'll be using it. A regular expression isn't, to me, a state machine - it's a way to describe a text pattern. > > It's okay that you feel that way, but hopefully you'll understand if people > > start to tune out messages that contain these sorts of comments. > > > > What does "these sorts of comments" mean? > Ones that you disagree with? > > If I am wrong, please explain why in an as objective a fashion as possible. Considering how subjective your posts in this thread are, there's some irony in begging for the complaint to be objective. > >> I would ask anyone who wants pattern matching adding to Python, to not > >> support PEP 634. > > > > Seriously? > > Yes. Absolutely. > PEP 634 is seriously flawed. FUD. You haven't given a single reason for it to be considered flawed, you've just said that it 'is' flawed, as though we should already know what's wrong with it. I don't draw this parallel lightly, but Mark, you're actually sounding scarily similar to jmf and his anti-PEP393 posts. Extremely light on actual arguments, and entirely based on emotive complaints and an assumption that your readers already know why this is somehow a bad thing. If you want PEP 634 to be rejected, explain why. Don't try to get us to go back over the past thousands of posts (never mind the ones stretching back ten years even). ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M6IH6ZC42YYEJFUJ356FIQX44OAGWGCQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Wed, Oct 21, 2020 at 3:31 AM Mark Shannon wrote: > > Hi Chris, > > On 20/10/2020 4:37 pm, Chris Angelico wrote: > > On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote: > >> > >> Hi everyone, > >> > >> CPython is slow. We all know that, yet little is done to fix it. > >> > >> I'd like to change that. > >> I have a plan to speed up CPython by a factor of five over the next few > >> years. But it needs funding. > >> > > > >> The overall aim is to speed up CPython by a factor of (approximately) > >> five. We aim to do this in four distinct stages, each stage increasing the > >> speed of CPython by (approximately) 50%. > >> > > > > This is a very bold estimate. Particularly, you're proposing a number > > of small tweaks in stage 2 and expecting that (combined) they can give > > a 50% improvement in overall performance? > > 20 tweaks each providing a 2% is a 49% speedup. > Stage 1 will open up optimizations that are currently worthwhile. Yes, I understand mathematics. Do you have evidence that shows that each of the twenty tweaks can give a two percent speedup though? > > Do you have any details to back this up? You're not just asking for a > > proposal to be accepted, you're actually asking for (quite a bit of) > > money, and then hoping to find a contractor to do the actual work. > > I am offering to do the work. Sure, that takes away some of the uncertainty, but you're still asking for a considerable amount of money sight-unseen. > > BIG BIG concern: You're basically assuming that all this definition of > > performance is measured for repeated executions of code. That's how > > PyPy already works, and it most often suffers quite badly in startup > > performance to make this happen. Will your proposed changes mean that > > CPython has to pay the same startup costs that PyPy does? > > Could you clarify what you think I'm assuming? > > When you say start up, do you mean this? > > $ time python3 -S -c "" > > real0m0.010s > > $ time pypy -S -c "" > > real0m0.017s > > No, there would be no slower startup. In fact the tier 0 interpreter > should start a fraction faster than 3.9. That's a microbenchmark, but yes, that's the kind of thing I'm talking about. For short scripts, will "python3.13 script.py" be slower than "python3.9 script.py"? > > What would happen if $2M were spent on improving PyPy3 instead? > > The PSF loses $1M to spend on CPython maintenance, to start with. > > What would happen to PyPy? I have no idea. > > Partial success of speeding up CPython is very valuable. > Partial success in getting PyPy to support C extensions well and perform > well when it currently does, is much less valuable. > > CPython that is "only" 2 or 3 times faster is a major improvement, but a > PyPy that supports 80% of the C extensions that it currently does not is > still not a replacement for CPython. > True, but it does sound like you're pushing for the sorts of changes that PyPy already has. Not sure whether your proposed changes would be better done to PyPy or to CPython. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/I4XKZNAZBLPWCRS5EQ4UY6DMV3LDMJPN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Wed, Oct 21, 2020 at 8:23 PM Matti Picus wrote: > Just to set the record straight, PyPy has been available on conda-forge > [0] since March, and has seen close to 70,000 downloads [1] from that > channel alone, in addition to the downloads from > https://downloads.python.org/pypy and the other channels where it is > available. This is far from CPython's wild popularity, but people are > successfully using it with the scientific python stack. It is true there > is more work to be done, that does not mean it is useless. > When I go looking for PyPy performance stats, everything seems to be Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or whichever specific version)? Or maybe it's right there on https://speed.pypy.org/ and I just can't see it - that's definitely possible :) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V2P5LDQWLMRYP24Q7O7QE3S4YDLUQ224/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PyPy performance stats (was Re: Speeding up CPython)
On Wed, Oct 21, 2020 at 10:38 PM Matti Picus wrote: > > On 10/21/20 20:42:02 +1100 Chris Angelico wrote: > > > When I go looking for PyPy performance stats, everything seems to be > > Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or > > whichever specific version)? Or maybe it's right there on > > https://speed.pypy.org/ and I just can't see it - that's definitely > > possible:) > > > > ChrisA > > > They are not on the front page. You can find them, but it requires > digging around in the Comparison page[0]. > > - Executables: use only "cpython 3.7.6" and any of the "pypy3-jit-64" > > - Chart type: normal bars > > - Normalization: cpython3.7.6 or pypy3-jit-64, whichever way makes more > sense to you > > - horizontal. Ah, cool, got it - thanks! My reading of this is that a good few of the benchmarks are coming out firmly in PyPy's favour, but a number of them are still in CPython's favour (including "telco" where PyPy is staggeringly worse for some reason). But a number of the "PyPy is worse" benchmarks are ones that seem less significant - for instance, SQLAlchemy seems to be slower, but if you're using SQLAlchemy, you're probably more concerned about database performance than the CPU cost inside Python. > For some reason the "permalink" feature does not let me share that > configuration. Yeah, there seem to be some issues with that page. The first time I loaded it, the chart was entirely broken - I was looking for the "show chart" button, but it was just that it had errored out for some reason. Still, at least the data's there. > I guess we could switch to emphasizing python3 on the front page, help > in updating and reconfiguring Codespeed [1] would be awesome. If only I had infinite time in the day, I'd love to dive in and help out... It definitely would be worth at least having a quick summary and link somewhere. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IP7DXROXIYAV7RXL2JSILON7CBKZYELJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote: > > On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote: > > > That'd leave open > > the option for "foo() if x else foo()" to be optimized down to just > > "foo()", although I don't think that particular one is needed. > > That would be an unsafe optimization. Not all objets are representable > as truthy/falsey values, e.g. numpy arrays. > > >>> bool(a) > Traceback (most recent call last): > File "", line 1, in > ValueError: The truth value of an array with more than one element > is ambiguous. Use a.any() or a.all() > > Not even all builtin values. This is in Python 3.9: > > >>> bool(NotImplemented) > :1: DeprecationWarning: NotImplemented should not be used in > a boolean context > True > > I believe that 3.10 makes it an error. If not 3.10, then it will surely > happen soon. But even without the change to NotImplemented, it has never > been the case that *every* object is guaranteed to be either truthy or > falsey. At least not since the Python 1.x `__nonzero__` dunder was put > into the language. > But this is exactly where we started: with a boolification that fails, in a context where the result wouldn't actually change anything. Actually calling bool() on something will continue to have the behaviour you're describing, but if the truthiness or falsiness would make no difference, is the interpreter required to find out? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IMG437FNV552XUWOQJW76A7SFAJQULEH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote: > > On 1/12/21 10:37 PM, Chris Angelico wrote: > > On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote: > >> > >> On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote: > >> > >>> That'd leave open > >>> the option for "foo() if x else foo()" to be optimized down to just > >>> "foo()", although I don't think that particular one is needed. > >> > >> That would be an unsafe optimization. Not all objets are representable > >> as truthy/falsey values > > >> Not even all builtin values. This is in Python 3.9: > >> > >> >>> bool(NotImplemented) > >> :1: DeprecationWarning: NotImplemented should not be used in > >> a boolean context > >> True > >> > >> I believe that 3.10 makes it an error. If not 3.10, then it will surely > >> happen soon. But even without the change to NotImplemented, it has never > >> been the case that *every* object is guaranteed to be either truthy or > >> falsey. At least not since the Python 1.x `__nonzero__` dunder was put > >> into the language. > > > > But this is exactly where we started: with a boolification that fails, > > in a context where the result wouldn't actually change anything. > > Actually calling bool() on something will continue to have the > > behaviour you're describing, but if the truthiness or falsiness would > > make no difference, is the interpreter required to find out? > > Yes. > > Optimizations are an implementation detail, and implementation details should > not change the language. > The language can also be defined in an optimization-friendly way, though. Consider how we got positional-only arguments in Python: first they existed in C-implemented functions in CPython, even though they couldn't exist in pure Python code, and then the functionality got added to the language definition, thus permitting the optimization. Or consider dictionary lookup. Most people treat it as "find a key which is equal to the one you're looking for", but the actual definition is "find a key which is identical to, or equal to, the one you're looking for". That's partly to ensure that weird cases like NaN don't break too badly, but also it means that x.__eq__(x) doesn't have to be called all the time. The topic under discussion is a language definition. Choosing to permit the optimization doesn't mean that the implementation detail changes the language. Choosing to deny it means there won't be an optimization. I personally don't see any reason to force Python to calculate something unnecessarily, given that this is *already* happening in other situations (see the "if a and b:" optimization, which doesn't boolify twice). ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SAUNDT7XTTFWREABUXPE2OKWI6KBQECO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On Fri, Jan 15, 2021 at 10:13 PM Rob Cliffe via Python-Dev wrote: > > > > On 12/01/2021 15:53, Mark Shannon wrote: > > Hi everyone, > > > > > > > > In master we convert `if x: pass` to `pass` which is equivalent, > > unless bool(x) has side effects the first time it is called. This is a > > recent change. > > > Suppose x is not a currently valid variable name at runtime. Will the > NameError still be "optimised" away? No, it won't. The expression still gets fully evaluated. The ONLY part that gets optimized away is the check "is this thing true?". ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KQ2QH3VB5Q6LYCBE4SUWZKRMML54TOXS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On Wed, Jan 13, 2021 at 9:08 PM Emily Bowman wrote: > > Even if you define __bool__() as returning a bool, and error/undefined > behavior otherwise, that doesn't eliminate side effects. Is it even possible > to nail down a definition to the point that you can say, "Thou shalt not > mutate or cause anything" and have it meaningfully enforced in the compiler > or interpreter? > Yes - just say "will be called when the interpreter needs to know the booleanness of the object", and don't mandate that it be called if the interpreter already knows. If someone writes a __bool__ function that decrements a counter and returns True if it's still above zero, then they're shooting themselves in the foot, and we don't have to protect them. It's like having __iter__ return an object on which __iter__ doesn't return self. There's no protection in the language to stop you from creating such a monster, but you'll run into problems sooner or later if you do, and it's not a bug in Python. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RN7SAZ3X4YM2KEHNVMAXDNPLQFWVY7NJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On Wed, Jan 13, 2021 at 8:02 PM Ethan Furman wrote:
>
> On 1/12/21 11:27 PM, Chris Angelico wrote:
> > On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
>
> >> Optimizations are an implementation detail, and implementation details
> >> should not change the language.
> >>
> >
> > The language can also be defined in an optimization-friendly way,
> > though. Consider how we got positional-only arguments in Python: first
> > they existed in C-implemented functions in CPython, even though they
> > couldn't exist in pure Python code, and then the functionality got
> > added to the language definition, thus permitting the optimization.
>
> 1. What optimization?
> 2. Did the language change because of the optimization?
It's a lot faster for C-implemented functions to require positional
parameters. A number of functions had help text that implied that they
accepted keyword-or-positional args, but if you tried to call them
with keyword args, they'd error out.
And yes. PEP 457 and then PEP 570 introduced real positional-only
arguments, and part of the debate surrounded the question "should we
require that all C-implemented functions support keyword args?". Why
have a performance hit on all C functions just for the sake of an
arbitrary consistency? Instead, the language definition was changed to
make this possible - and now we have, for instance, "len(obj, /)",
which clearly does not accept len(obj="x"), but does accept len("x").
> > Or consider dictionary lookup. Most people treat it as "find a key
> > which is equal to the one you're looking for", but the actual
> > definition is "find a key which is identical to, or equal to, the one
> > you're looking for".
>
> Exactly. The definition, i.e. language spec, says identity, then equality.
Right. The definition is set to permit the optimization. Therefore the
optimization cannot be in violation of the spec.
> > The topic under discussion is a language definition. Choosing to
> > permit the optimization doesn't mean that the implementation detail
> > changes the language. Choosing to deny it means there won't be an
> > optimization.
>
> There are, I am sure, many optimizations that are not possible because of
> Python's dynamism. `if ` is
> supposed to evaluate `bool(something)`, regardless of what comes after.
It doesn't, though. There is a difference between:
if a and b: ...
and
x = a and b
if x: ...
The first one will boolify a only once; the second will figure out
what bool(a) is before the assignment, and then (if it's false)
boolify it again in the 'if' statement.
Current builds of Python 3.10 optimize this away too:
if a or 1: print(1)
Regardless of the truthiness of a, the print call will happen.
(Note that a is still *evaluated*. It's just not queried for
truthiness. For instance, "if f() or 1:" will still call the function;
it just won't call __bool__() on the return value.)
> > I personally don't see any reason to force Python to calculate
> > something unnecessarily, given that this is *already* happening in
> > other situations (see the "if a and b:" optimization, which doesn't
> > boolify twice).
>
> Sure, and I agree that calling `bool()` a second time is wasteful, as well as
> possibly confusing -- Python already has
> the answer from the first `bool()` call, so why would it need to do it again?
> That seems a matter of correctness, not
> optimization.
>
Is it? It means that there's a visible difference between putting it
in a variable and doing it inline. If it's okay to do that, then why
is it not okay to remove the bool check when it can't affect the
result?
In theory, "x = (expr)" followed by "if x:" should perform the exact
same checks as "if (expr):"; if it's okay to violate that principle
for "if a and b:", then why not for "if a: pass"? Either way, the
interpreter knows that any sane __bool__ function cannot affect the
result.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RK36KL2EH5I54W76INZ64OBFJ5BBY5L7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On Wed, Jan 13, 2021 at 4:24 AM Richard Damon wrote:
>
> On 1/12/21 10:53 AM, Mark Shannon wrote:
> > Hi everyone,
> >
> > Should the optimizer eliminate tests that it can prove have no effect
> > on the control flow of the program, even if that may eliminate some
> > side effects in __bool__()?
> >
> > For several years we have converted
> >
> > if a and b:
> > ...
> >
> > to
> >
> > if a:
> > if b:
> > ...
> >
> > which are equivalent, unless bool(a) has side effects the second time
> > it is called.
> >
> > In master we convert `if x: pass` to `pass` which is equivalent,
> > unless bool(x) has side effects the first time it is called. This is a
> > recent change.
> >
> > This is one of those "easy to fix, if we can decide on the semantics"
> > bugs.
> >
> >
> > Submit your thoughts to https://bugs.python.org/issue42899, please.
> >
> > Cheers,
> > Mark.
>
> One key point about 'and' and 'or' is that those operators are defined
> to be 'short circuiting', i.e. that with a and b, that if a is false,
> then b is not evaluated at all. This can be important if a is a
> condition that test if the expression b is 'safe' to evaluate. In fact,
> isn't it true that 'a and b' is defined to be the equivalent to: 'a if
> not a else b' so b doesn't need to be evaluated unless a is truthy.
Yes, the shortcircuiting behaviour isn't in question. But consider:
class A:
def __bool__(self):
print("A().__bool__")
return False
def f():
print("if A() and A()")
if A() and A(): x = 1
print("cond = A() and A()")
cond = A() and A()
if cond: x = 1
f()
And once you've run the code, disassemble the function for extra insight.
There's a very definite difference here, and it's the same difference as:
for x in thing:
and
for x in iter(thing):
I'd be fine with documenting that __bool__ is (guaranteed to be)
called only if the interpreter needs to know the result, leaving open
the option for things like this to be optimized out. That'd leave open
the option for "foo() if x else foo()" to be optimized down to just
"foo()", although I don't think that particular one is needed.
> I know that I would be very surpised if a statement like
>
>
> if foo():
>
> pass
>
> ended up optimizing itself and not calling foo(), which is only one step
> away from the quoted case of
>
> if b:
>
> pass
>
> which is the equivalent to
>
> if b.__bool__():
>
> pass
Yes, they do look similar. The difference is that calling __bool__ is
under the interpreter's control, and it's easier to document that it
be assumed to be side-effect-free.
> Yes, perhaps there is more of an expectation that __bool__() is
> innocuous, but is that a an assumption that should be baked into the
> language.
>
I think so. Consider that sometimes other dunders won't be called, if
the interpreter believes it's not necessary:
class A(float):
def __index__(self):
print("A().__index__")
return 10
class B(int):
def __index__(self):
print("B().__index__")
return 10
print(range(20)[A():B()])
If it's a subclass of float, slicing will call __index__, but if it's
a subclass of int, Python knows already that it can use the internal
integer value.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/GHKDF6YE3D43JPWS7GVG34FVPJNYE5SO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Fri, May 14, 2021 at 7:31 PM Petr Viktorin wrote:
> Perhaps it would be beneficial to provide a common base class or
> factory, so we get a good repr. But I don't think another common value
> like None and Ellipsis would do much good.
>
Agreed - I think Sentinel would make a great class, from which you
instantiate purpose-specific sentinels.
But maybe there really needs to be a way to NOT specify an argument,
and to find out that an argument wasn't specified? Defaulting is only
one way to handle it. Consider:
def truly_optional_arg(x, y, *z):
"""Two mandatory args, and then an optional one"""
if z: print("Got an extra arg")
pass_arg = input("Pass the arg? ") == "y"
truly_optional_arg(10, 20, *([30] if pass_arg else []))
It's horrifically ugly, but it really and truly does/doesn't pass that
argument, and it really and truly detects whether one was passed. To
make that sort of thing actually viable, there'd need to be some sort
of language support; maybe something where the local name would start
out unbound, but testing for a local's boundness is a clunky
try/except, so that might also need some support.
Do we ever really need the ability to pass a specific sentinel to a
function, or are we actually looking for a way to say "and don't pass
this argument"?
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/VSKX4PV4URDMNAJ6AYW3H3XKI4XWPJNS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter
On Tue, May 18, 2021 at 8:51 PM Stephen J. Turnbull wrote: > > Steve Holden writes: > > On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano > > wrote: > > > > > Steve > > > (one of the other ones) > > > > > > > We are all other Steves! > > +1 > > There were five Steves (and one Stephanie) in my 6th grade class (of > 27). "Steve, move that " became an idiom > > -- Other Steve since 1994 > I feel the need to redress the balance of names here. This thread has had a mere two Chrises so far, and I am improving that statistic by 50%. ChrisA (used to style his name as "chrisa" but people complained that I looked like a girl) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UMMFCI5NTHCF3PZVNJYVRH4ZKQQDWE5L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
On Thu, May 13, 2021 at 5:37 PM Abdur-Rahmaan Janhangeer wrote: > > Greetings, > > One crucial missing piece in the Python world is the focus > on internals of projects. You have many talks on usage and > scaling but not enough on internals. Even less workshops. > For OpenSource to thrive, you need people who master the codebase. > It's a long process. You get there by having core contributors over > time. How does a contributor becomes a core one? By getting the feet wet > into the codebase and tackling more difficult as time passes. That's why > instead of waiting for people to find issues, work on it, wait for validation, > we can improve the training process without damage to the codebase. > People get the educational version of the repo, solve the issues at their > own pace up to the level where they'll feel confident to try a meaningful > PR. Seeing it with the eye of a knowledgeable person makes will make them > PR not just for the sake of PR but because of a real need. How is this "educational version" different from a forked git repository? I'm confused here. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/N2BUH2MHDTPERNA4TLCXQOL5KQ5FFL3D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Sat, May 15, 2021 at 2:04 AM Barry Warsaw wrote: > > On May 14, 2021, at 02:38, Chris Angelico wrote: > > > > Do we ever really need the ability to pass a specific sentinel to a > > function, or are we actually looking for a way to say "and don't pass > > this argument”? > > Very often, that’s the case. Such a “it’s okay to not pass this argument” > construct would have to work with the Optional type too. What I mean is: how often do you actually need to pass the specific sentinel, as opposed to the normal construct of asking if the argument was or wasn't passed? Eg if you have a function like this: _sentinel = object() def func(x, y=_sentinel): if y is _sentinel: ... else: ... Would you ever call it like this: func(42, _sentinel) ? Because if there's no reason to ever pass the sentinel, then it's nothing more than an implementation detail for the concept of "was this argument passed?", and that's exactly what I'm asking about. > The other use case I have for a special case single use singleton is for > dict.get(), i.e. > > missing = object() > value = somedict.get(‘key’, missing) > if value is missing: > # It ain’t there. > I'd write that one with a try/except instead. The whole point of get() is to provide the missing value. try: value = somedict['key'] except KeyError: # It ain't there. No sentinel needed. Same number of lines. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TMZWXDXJSVXTEKJNXYDMQNHTFC6ZXIOH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The repr of a sentinel
On Fri, May 21, 2021 at 3:51 AM David Mertz wrote: > > On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote: >> >> On Sat, May 15, 2021 at 2:09 AM David Mertz wrote: >> > Just add a ._uuid attribute and have object equality follow equality of >> > that attribute. There's no reason to expose that in the .__repr__, but it >> > would be inspectable in concept. >> >> I think it's worth preserving the idiom of comparing sentinels using >> `is`, as we do for `None` and other existing sentinel values. It's >> relatively easy to do, such as by using a single-value Enum or by >> using a class with a custom __new__. > > > This only works if: > > a) Unpickling is within a single interpreter session > b) Sentinels are explicitly created in imported modules, not as a runtime, > user-level creation > > Maybe there's a way to do it, but how would you handle this situation: > > if some_runtime_condition: > my_sentinal = Sentinel(desc="Gosh, I need a sentinel") > # ... code ... > pickle.dump(thing_using_sentinel, fh) > > Equality is certainly a lot easier to get than identity here. > Probably the easiest way would be to have some kind of unique identifier (a fully-qualified name) that can be pickled, and then any time you attempt to construct a Sentinel with that identifier, it's guaranteed to return the same object. That way, in your example, unpickling it in another session where that runtime condition is false would simply create a brand new sentinel, which would be the same as any others that also get unpickled; and if, subsequently, you reconstruct my_sentinal, it would be the same one as got unpickled. The hardest part would be figuring out a reliable way to define the identifier, without massively duplicating or requiring that something be registered somewhere. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3WKMD7Q3JMLDWI3L2WOGIJB767PYJO2W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Question for potential python development contributions on Windows
On Mon, May 24, 2021 at 6:40 PM Łukasz Langa wrote: > > > On 20 May 2021, at 07:03, pjfarl...@earthlink.net wrote: > > The Python Developers Guide specifically states to get VS2017 for developing > or enhancing python on a Windows system. > > Is it still correct to specifically use VS2017 , or is VS2019 also acceptable? > > > We have to update the devguide. VS 2019 is supported, probably even > recommended, as long as the C++ tools are v14.x. > Also of note is this page: https://wiki.python.org/moin/WindowsCompilers It lists Visual Studio versions for different Python versions (for compiling extensions), but it stops at 3.8. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HF33ZPO2TRVQIXDGMSMVIB7IRPS64KFV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proposal: declare "unstable APIs"
On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote: > > I think it makes sense, and I do see a difference between Provisional and > Unstable. Is this anything more than a documentation label? > Would it be a pipe dream to hope that static checkers could be taught to recognize them? Not a huge deal, but it would mean you could ask something to analyze your code (I hesitate to call it a type checker, since this is nothing to do with data types, but the same kind of tool) and it'd tell you whether your code is (a) portable to all OSes, (b) portable to all Pythons, and (c) stable across versions. BTW, does "unstable" cover things like dis.dis(), which have existed and will continue to exist for many versions, but their output can change? In one sense, dis.dis() always does the exact same thing: it shows you the disassembly of a piece of code. In another sense, its output changes drastically when things change. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MRNDNHVLQWX5HC3LETQVUT4XX2TKYKVW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proposal: declare "unstable APIs"
On Fri, Jun 4, 2021 at 8:31 AM Guido van Rossum wrote: > > On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote: >> >> On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote: >> > >> > I think it makes sense, and I do see a difference between Provisional and >> > Unstable. Is this anything more than a documentation label? >> > >> >> Would it be a pipe dream to hope that static checkers could be taught >> to recognize them? Not a huge deal, but it would mean you could ask >> something to analyze your code (I hesitate to call it a type checker, >> since this is nothing to do with data types, but the same kind of >> tool) and it'd tell you whether your code is (a) portable to all OSes, >> (b) portable to all Pythons, and (c) stable across versions. > > > Yeah, this could easily be taken on by any of the many linters. Cool cool. >> BTW, does "unstable" cover things like dis.dis(), which have existed >> and will continue to exist for many versions, but their output can >> change? In one sense, dis.dis() always does the exact same thing: it >> shows you the disassembly of a piece of code. In another sense, its >> output changes drastically when things change. > > > That's debatable. I sure hope people aren't ever parsing dis output. > That's exactly what I mean. People shouldn't be parsing that output, because it's human-readable. Does it count as an API change when the human-readable output is giving different information? Actually, I think I just talked myself out of this. The sys.version_info tuple is going to change from one version to another (obviously!), but it is, by definition, stable and dependable. So I think no, it's not "unstable" based on human-readable output. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HDTPVRMBX7L5NPWFSDOHTO7UTISOUC6Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is the Python review process flawed?
On Wed, Jun 30, 2021 at 2:36 AM wrote: > > I just stumbled upon the following issue and subsequent pull request. It is a > very small bugfix. There is currently a bug in Python and this pull request > fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it > doesn't get reviewed, nor merged. And this has been going on since March > 2017. Why not just merge this? It's not like it's huge or obstructing or > obfuscating the current code base? There's always time to write an > improvement or a complete rewrite of this module feature later for an > upcoming minor release. But if there is currently a bug in Python and the > bugfix is available - why doesn't it get merged? > > https://github.com/python/cpython/pull/4819 > > If this doesn't get fixed, doesn't that mean the Python review process is > flawed? Sure, Python is an open source project and many people just work in > their free time. But this doesn't really apply here, does it? The bugfix is > available. Only a review is required. All this is happening while new > features get added to Python with every new minor version. While the bug is > allowed to live there. Please help me understand how this can happen. > > I love Python. No hard feelings. But this is really bugging me and I can't > help but feel disappointed. > It looks like that was closed in favour of a different PR: https://github.com/python/cpython/pull/16341 There's been quite a bit of discussion on both of them. Are you sure you linked to the correct pull request? ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HW7IWAAYKSTOMXCXAVAZM3L7RGFSTBTO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is the Python review process flawed?
On Fri, Jul 2, 2021 at 10:06 AM Eric V. Smith wrote: > > On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote: > > "Merging something is also a responsibility to whoever does it" - And it's > > also a responsibility to fix bugs, no? I don't get why you're so afraid of > > (maybe!) introducing a new bug when there already (certainly!) is a bug. > > Because the new bug you introduce might be much, much worse than the bug > you're fixing. > It's worth noting that, in the (rare) cases where there clearly is no downside to fixing a bug... it just gets fixed. You won't see those kinds of issues in Stack Overflow answers, because they're not there any more. Calling the review process flawed on the basis of the issues still open after X years is as incomplete a picture as saying that all music from the 18th century is awesome on the basis of the music that's still being played today. *By definition*, you're only seeing the hairy issues, the ones where it's far from clear what the correct action is (merge, modify, or do nothing). If you want a rough idea of the things that get fixed quietly, browse the What's New for a point release, for example: https://www.python.org/downloads/release/python-394/ ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TC6MFY6HEQEV4XPLSRMYDMFAOU32WJ6V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
On Mon, Apr 26, 2021 at 2:27 PM Nathaniel Smith wrote: > Yeah, you've understood correctly, and you see why I wrote "both the > current proposal and the alternative have very complex implications > and downsides" :-) > > [chomp lots of very helpful summarizing] Gotcha, thanks! ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LCQLKVQMBLHFX74WQD3Z5BIMYT5ARQFP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble wrote: > > On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote: >> >> On 4/29/21 10:35 AM, Jonathan Goble wrote: >> > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote: >> >> >> >> Which raises the question: Do we want to have a standard name for >> stdlib Flags when no flags are set? >> > >> > If you want a flag to represent no flags set, it takes one line to write >> it yourself, as in this example I copied >> > verbatim from the docs: >> > >> > >>> class Color(Flag): >> > ... BLACK = 0 >> > ... RED = auto() >> > ... BLUE = auto() >> > ... GREEN = auto() >> > ... >> > >>> Color.BLACK >> > >> > >>> bool(Color.BLACK) >> > False >> >> Are you suggesting that the standard name for 0 be 'BLACK'? ;-) > > > Any color you want as long as it's BLACK. ;-) > > But seriously, my point is that it's already trivially possible for enum > authors to give the zero case a name of their own choosing that makes sense > for their use case, so we don't need special automatic names for it. The one > obvious way to do it, and the explicit way to do it, is to define your own > name to be equal to zero. Creating an automatic name for zero now, after the > enum module is well-established, violates the Zen of Python in at least > three, possibly four ways: > > - it's implicit behavior (compared to the explicitness of defining your own > name) > - it violates the "one obvious way to do it" principle (I can conceivably see > arguments developing in the community over whether the automatic name should > be preferred or if one should write an explicit name for zero, as neither is > clearly and obviously better than the other) > - it requires a special case for backward compatibility with the @enum.unique > decorator > - it's arguably ambiguous what object should be returned for foo(0) when an > explicit name is defined (due to the documented behavior that a second name > for the same value is an alias for the first; is the automatic name created > first or last?) > OTOH, zero is already supported. If you create a flag without defining a zero entry, it implicitly gets one with the name None. >>> class Color(Flag): ... RED = auto() ... BLUE = auto() ... GREEN = auto() ... >>> c = Color.GREEN|Color.BLUE >>> c >>> c &= Color.GREEN >>> c >>> c &= Color.BLUE >>> c >>> c.name >>> c.value 0 It makes good sense to have an actual name for it. If the automatic/default name (Color.NONE or whatever name it gets) is considered to be created at the very end of the class definition, this would resolve the ambiguity. And unique() could simply prevent the creation of NONE if there's anything else (eg Color.BLACK) with the value of zero. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QBWVLDC752PFAADMAM4GYIJGJ7USTRHA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Keeping Python a Duck Typed Language.
On Thu, Apr 22, 2021 at 7:53 PM Paul Moore wrote: > I wonder whether type checkers could handle a "magic" type (let's call > it DuckTyped for now :-)) which basically means "infer a protocol > based on usage in this function". So if I do: > > def my_fn(f: DuckTyped): > with f: > data = f.read() > for line in f: > print(line) > f.close() > > then the type checker would automatically build a protocol type like > the one I defined above and use that as the type of f? That would make > it much easier to include duck typed arguments in function signatures > while keeping the benefits of static type checking. > Someone will likely correct me if this is inaccurate, but my understanding is that that's exactly what you get if you just don't give a type hint. The point of type hints is to give more information to the type checker when it's unable to simply infer from usage and context. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RW5ACSLJP2RLBZWDGQRGBD6ZAVRUQWMG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Keeping Python a Duck Typed Language.
On Thu, Apr 22, 2021 at 5:03 PM Ryan Gonzalez wrote: > > On Apr 21, 2021, 5:29 PM -0500, Paul Bryan , wrote: > > As demonstrated, protocols don't get us there because duck typing isn't a > matter of having an object exhibit all of the attributes of a duck, but > rather some subset of attributes to be used by the consumer. I want this duck > to quack; someone else will want it to waddle. I don't see how type hints > could reasonably support "file like object" in the duck type sense (unless > the consumer were to specify the exact attributes of the duck it's interested > in, which I fear would become a tedious type writing style). > > > I'd argue that, if you frequently have cases where functions use a relatively > small subset of a much larger interface, it's simply that your interfaces are > too large. You're always free to define your own, smaller protocols that just > implement the subset of the interfaces you need. > File-like objects are used VERY frequently in the stdlib, and actual open file objects have quite a large interface. The use-case is a pretty real one: "if I were to create a simulant file object to pass to json.load(), what methods do I need?". Maybe in some cases, the "smaller protocols" option is practical, but it would need to have a useful name. For instance, if it needs to be readable, iterable, closeable, and autocloseable via __enter__/__exit__, that's ... uhh a readable, iterable, closeable context manager? Not an improvement over "file-like object". ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2LQQXLETT6TFB4UATJBEN5HDI47KAZME/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Keeping Python a Duck Typed Language.
On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote: > > > > On Sat, 24 Apr 2021, 10:02 am Skip Montanaro, > wrote: >> >> >>> Practically speaking, one issue I have is how easy it is to write >>> isinstance or issubclass checks. It has historically been much more >>> difficult to write and maintain a check that something looks like a duck. >>> >>> `if hasattr(foo, 'close') and hasattr(foo, 'seek') and hasattr(foo, >>> 'read'):` >>> >>> Just does not roll off the figurative tongue and that is a relatively >>> simple example of what is required for a duck check. >>> >>> To prevent isinstance use when a duck check would be better, >> >> >> I'm going to chime in briefly then return to lurking on this topic, trying >> to figure out all the changes to typing while I wasn't paying attention. >> Back in ancient times I recall "look before you leap" as the description of >> either of the above styles of checks, no matter which was easier to type. At >> the time, I thought the general recommendation was to document what >> attributes you expected objects to provide and just make the relevant >> unguarded references. I no longer recall what the tongue-in-cheek >> description of that style was (just "leap"?) Is that more simple usage more >> akin to classic "duck typing" than always guarding accesses? I assume that >> will still have a place in the pantheon of Python type variants. > > > LBYL: Look before you leap (check then use) > EAFP: Easier to ask forgiveness than permission (use, then handle any > exceptions or let them escape) > > (for accessing external resources rather than satisfying internal type > consistency, you usually need the latter, as the external state may change > between checking and usage) > > Duck typing usually falls squarely into the EAFP category. Isn't it orthogonal? LBYL means checking first, EAFP means going ahead and doing things, and coping with failure. Duck typing means caring about it having a specific method/attribute, nominal typing means caring about it "being a list". You can test either form in advance, and you can certainly duck-type in EAFP style, so there's only one quadrant that might not be possible (and even that, I'm sure, would be possible somehow). ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FJA52VPBTOI5JSOYIEIZDRCJGEOQ6V3P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: On the migration from master to main
On Sat, Mar 27, 2021 at 3:33 AM Baptiste Carvello wrote: > > Le 25/03/2021 à 15:59, Stefano Borini a écrit : > > On Tue, 23 Mar 2021 at 21:39, Python Steering Council > > wrote: > >> This isn’t just about ‘master’ being rooted in slavery. > > > > No it's not and I am shocked that such ignorance would exist to believe > > that. > > It is indeed not, but the peculiar bitkeeper/git usage is. > > If both sides would agree on this, we could finally move on. > The one thing we can agree on is that it's easier to roll over and let the change happen than to try to fight against politically-motivated changes. Politics, truth to tell, is more important than technical matters. Sometimes, it's just not worth arguing any more. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FZPLVZS27KXYSPHOBYQFBXZE7BW72LWQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
On Sun, Apr 4, 2021 at 6:20 PM Paul Moore wrote: > > On Sun, 4 Apr 2021 at 01:37, Brandt Bucher wrote: > > > > Mark Shannon said: > > > I was relying on the "reference" implementation, which is also in the PEP. > > > > Can you please stop putting scare quotes around "reference implementation"? > > Agreed - apart from the implication Brandt noted, it's also > misleading. The code is in Python 3.10, so the correct term is "the > implementation" (or if you want to be picky, "the CPython > implementation"). To me, the term "reference implementation" implies > "for reference, not yet released". > Normally, the term "reference implementation" means "the basis implementation that everything else is compared against". For instance, a compression algorithm might be published as a mathematical document, with a reference implementation in some language. It's then possible to create a new implementation in some other language, or more optimized, or whatever else; but to know whether it's giving the correct results, you compare its output to the output of the reference implementation. CPython is the reference implementation for the Python language. It's possible to have a discrepancy between the standard and the implementation, but it's still the reference implementation (just occasionally a buggy one). In this case, I believe that the term "reference implementation" is strictly accurate, and concur with Brandt's request to not discredit it by implying that it's only purporting to be one. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C5ZWYROKGA4FJWOTCSBYLFDRUWA5FAZO/ Code of Conduct: http://python.org/psf/codeofconduct/
