[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
There is an important difference between monkeypatching in general, vs monkey-patching an object that was explicitly marked and documented as expecting a monkeypatch. (That said, my personal opinion is that this is pretty heavyweight for very little gain; why not just create a placeholder class that static analysis tools are supposed to recognize as likely-to-be-replaced later? And why not just use strings giving the expected eventual class name? It isn't as though the analysis can verify whether something actually meets the full intended contract before they've also parsed the continuation.) ___ 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/JCPKY36RLN5WEFET34EHM4SC6STIJIUC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 684: A Per-Interpreter GIL
> That sounds like a horrible idea. The GIL should never be held during an > I/O operation. For a greenfield design, I agree that it would be perverse. But I thought we were talking about affordances for transitions from code that was written without consideration of multiple interpreters. In those cases, the GIL can be a way of saying "OK, this is the part where I haven't thought things through yet." Using a more fine-grained lock would be better, but would take a lot more work and be more error-prone. For a legacy system, I'm seen plenty of situations where a blunt (but simple) hammer like "Grab the GIL" would still be a huge improvement from the status quo. And those situations tend to occur with the sort of clients where "Brutally inefficient, but it does work because the fragile parts are guaranteed by an external tool" is the right tradeoff. ___ 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/AAWSCUNVS2NUXRHVATO736KM6I5M6RK5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 684: A Per-Interpreter GIL
> Is ``allow_all_extensions`` the best name for the context manager? Nope. I'm pretty sure that "parallel processing via multiple simultaneous interpreters" won't be the only reason people ever want to exclude certain extensions. It might be easier to express that through package or module name, but importlib and util aren't specific enough. For an example of an extension that works with multiple interpreters but only if they share a single GIL ... why wouldn't that apply to any extension designed to work with a Singleton external resource? For example, the interpreters could all share a single database connection, and repurpose the GIL to ensure that there isn't a thread (or interpreter) switch mid-transaction. ___ 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/RUDVIEDDCNFDRBIQVQU334GMPW77ZNOK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 3)
> "periodically reset the refcount for immortal objects (only enable this > if a stable ABI extension is imported?)" -- that sounds quite expensive, > both at runtime and maintenance-wise. As I understand it, the plan is to represent an immortal object by setting two high-order bits to 1. The higher bit is the actual test, and the one representing half of that is a safety margin. When reducing the reference count, CPython already checks whether the refcount's new value is 0. It could instead check whether refcount & (not !immortal_bit) is 0, which would detect when the safety margin has been reduced to 0 -- and could then add it back in. Since the bit manipulation is not conditional, the only extra branch will occur when an object is about to be de-allocated, and that might be rare enough to be an acceptable cost. (It still doesn't prevent rollover from too many increfs, but ... that should indeed be rare in the wild.) -jJ ___ 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/O324Q4KMMXL2UHOQIZZWS52U7YHJGYEI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"
I suggest being a little more explicit (even blatant) that the particular details of: (1) which subset of functionally immortal objects are marked as immortal (2) how to mark something as immortal (3) how to recognize something as immortal (4) which memory-management activities are skipped or modified for immortal objects are not only Cpython-specific, but are also private implementation details that are expected to change in subsequent versions. Ideally, things like the interned string dictionary or the constants from a pyc file will be not merely immortal, but stored in an immortal-only memory page, so that they won't be flushed or CoW-ed when a nearby non-immortal object is modified. Getting those details right will make a difference to performance, and you don't want to be locked in to the first draft. -jJ ___ 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/EPH3PGNKUBUZK26Z2M4SQSPUVIGXZUNB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
I think you skimmed over "A floating point expert can probably look at this ... " I remember a time when I just assumed more bits was better, and a later time when I figured smaller was better, and a still later time when I wanted to match the published requirements for bitsize. So that was several years when I didn't really understand the tradeoffs, but could benefit from (or at least write better documentation) knowing the size. During those years, I would have recognized the importance of 1024, but would probably not have bothered interpreting 2.220446049250313. A method (or docstring) with a more friendly interface would be good. -jJ ___ 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/R4BW2ZL46Y23UYYQCOSWJ2B3KTSRO5LK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
> Why do you think the stdlib *must *provide an example implementation > for this specific scenario? Is there something unique to HTTP request > handling that you feel is important to demonstrate? *must* is too strong, but I would use a very strong *should*. I think the stdlib should provide simple source-included examples of most things. I think the case is even stronger when it is: (1) a fairly simple protocol (such as version 1 of http was) -- QUIC wouldn't count for a simple demonstration. (2) something new users are likely to find motivating. Short of "here is a way to do IO", and maybe "write a simple game", "get something from the web" is probably the most obvious case. (3) something where bootstrapping might be an issue (network protocols, particularly web downloads). Network access is not an always-available resource. Even when it is available, there is sometimes a barrier between "available in python" and "I could read it on my phone, but can't get it open in python". (4) something where a a beginner is likely to be overwhelmed by choices if we just say "use a 3rd party module". (5) something with a backwards-compatibility story in the stdlib already. As a side note, are there concerns about urllib.robotparser being broken or obsolete, or was that part of the deprecation proposal just contagion from urllib.request? -jJ ___ 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/HF5V6SFWV4BZUAOJTSEBD6DSZWSJONAM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
There are problems with urllib. With hindsight, it would have been nice to do a few things differently. But that doesn't make migrating away from it any easier. This thread has mentioned several "better" alternatives -- but with the exception of 3rd party Requests, the docs don't even mention them. Saying "You can do better, but we won't tell you how" is pretty rude to beginners, and we should not do it. Delegating to the operating system may be sensible for a production system, and there is nothing wrong with saying so in the docs, and it would be great if we made that easy. But it is absolutely not a reasonable replacement for a straightforward (possibly inefficient and non-scalable) implementation written in python that people can read and use for reference. urllib shouldn't be deprecated until we have a better solution to *that* use case that is also in the stdlib. (That might well be worth doing, but it should happen before the deprecation.) -jJ ___ 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/JI5CFS3WYXQEXKSEZH2ZTE3JJJ7AUAMW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?
- Should we require the presence of NaNs in order for CPython to build? - Should we require IEEE 754 floating-point for CPython-the-implementation? - Should we require IEEE 754 floating-point for Python-the-language? I don't have strong opinions on the first two, but for the language definition, I think the most we should say is "if an implementation does not support IEEE 754 floating-point, this must be mentioned in the documentation as an implementation limit." ___ 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/YEXX363XX6DS7ZC653RBLIPNQIHBVYTK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring
Guido van Rossum wrote:
> I personally think F-strings should not be usable as docstrings. If you
> want a dynamically calculated docstring you should assign it dynamically,
> not smuggle it in using a string-like expression. We don't allow "blah {x}
> blah".format(x=1) as a docstring either, not "foo %s bar" % x.
Nor, last I checked, even "string1" + "string2", even though the result is a
compile-time string in the appropriate location. I think all of these should
be allowed, but I'll grant that annotations reduce the need. I'll even admit
that scoping issues make the interpolating versions error prone, and the UI to
clear that up may be more of a hassle than it is worth.
-jJ
___
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/ZUWTCGK6KZJYCUDRR3JNB7H5W3ZHJWMT/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
Steven D'Aprano wrote:
> On Sat, Jan 08, 2022 at 12:59:38AM +0100, jack.jan...@cwi.nl wrote:
> For example, the arrow syntax for Callable `(int) -> str` (if accepted)
> could be a plain old Python expression, usable anywhere the plain old
> Python expression `Callable[[int], str]` would be.
In principle, yes. In practice, I think the precedence of "->" might be
tricky, particularly if the (int) part discourages people from wrapping the
full expression in parentheses.
> > What if we created a little language that is clearly flagged, for
> > example as t”….” or t’….’? Then we could simply define the
> > typestring language to be readable, so you could indeed say t”(int,
> > str) -> bool”. And we could even allow escapes (similar to
> > f-strings) so that the previous expression could also be specified,
> > if you really wanted to, as t”{typing.Callable[[int, str], bool}”.
> The following are not rhetorical questions. I don't know the answers,
> which is why I am asking.
> 1. Are these t-strings only usable inside annotations, or are they
> expressions that are usable everywhere?
I assume they *could* be used anywhere, there just wouldn't be huge reasons to
do so. Sort of like a string expression can be an entire statement; there just
usually isn't much reason (except as a docstring) to do it.
> 2. If only usable inside annotations, why bother with the extra prefix
> t" and suffix "? What benefit do they give versus just the rule
> "annotations use this syntax"?
It provides a useful box around the typing, so that people who are not
currently worried about typing can more easily concentrate on the portion they
do currently care about.
> 3. If usable outside of annotations, what runtime effect do they have?
They create a string. Which may or may not be a useful thing to do.
> The t-string must evaluate to an object. What object?
A string. The various "let us delay annotation evaluation" proposals have made
it clear that the people actually using typing don't want it to slow things
down for extra evaluation until they explicitly call for that evaluation,
perhaps as part of a special run.
> 4. If the syntax allowed inside the t-string is specified as part of the
> Python language definition, why do we need the prefix and suffix?
Same answer as number 2 ... it allows typing to be a less intrusive neighbor.
I don't think t" " is as good as some sort of braces, but ... we're out of
conventional braces available in ASCII.
> Likewise, if this is allowed:
> def func(arr: t"array [1...10] of int") -> str: ...
How many arguments do I pass to func? That is already tricky to see at a
glance, but
> def func(arr: array [1...10] of int) -> str: ...
is even more difficult to parse. By the time I've mentally attached the "of"
and "int" to the indexed (but not really) array that just describes a type,
I've forgotten what I was looking for and why.
> 5. What difference, if any, is there between `t"{expression}"` and
> `expression`?
In addition to the box (so readers can more easily filter it out), there is
also a flag to typing systems saying that they *should* elaborate the string.
What they elaborate it into will be very different from a regular string. That
won't happen every time the module is imported, but it will happen when the
string is actually needed for something.
-jJ
___
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/HY7I52ILYN7IYN2S6UQT57XV4R3YEC2Z/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
I'm seeing enough different interpretations to think things aren't quite specified -- but I'm not sure if it matters. (1) Is any of this something that should affect computation, or is it really just a question of how to interpret possibly ambiguous documentation? (2) Are any of these troubling cases something that a person should actually write for a normal situation? Or are they just arguments about which abbreviations are acceptable? Or about how automatically-generated (inferred) type descriptions should be written? (3) Are the slice-expansion questions all assumed to be indexing an n-dimensional array, as opposed to [start, stop, step]? Is that explicit in the PEP, and just not in the extracts here? (4) Expanding multiple * shouldn't be ambiguous; the problem is figuring out what to condense into which if two are adjacent. So s1, s2 =[a,b], (1,2,3) [*s1, *s2] should turn into [a, b, 1, 2, 3] The problem is that [*s3, *s4] = (a, b, 1, 2, 3) is ambiguous ... and I didn't really get that distinction from Petr's question or the answers. I can't tell whether I've missed something crucial, or others are arguing over angels on a pinhead ... so whatever the PEP ends up deciding, it should be explicit. (I *think* the earlier parts of this thread are consistent with this, and discussing whether to say explicitly that certain formats are forbidden (but maybe not enforced by the grammar), meaningless, or valid but currently meaningless outside of typing.) -jJ ___ 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/YH4URO5EDQODG4QMGOCSXHV6RYTMLK5M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Function Prototypes
Steven D'Aprano wrote:uble the size of Callable. > > I think it takes only the characters needed to write the name IntToIntFunc. > ... you may only use it once. Could you provide an example where it is only used once? The only way I can imagine is that you use it here when when defining your complicated function that takes a callback (once), but then you never actually call that complicated function, even from test code, nor do you expect your users to do so. > The status quo is that we can use an anonymous type in the annotation > without pre-defining it, using Callable. OK. I'm not sure it would be a good idea, but we agree it is legal. > PEP 677 proposes a new, more compact syntax for the same. Does it? I agree that "(int, float) -> bool" is more compact than typing.Callable[...], but that feels like optimizing for the wrong thing. I dislike the PEP's flat_map as an example, because it is the sort of infrastructure function that carries no semantic meaning, but ... I'll use it anyhow. def flat_map(l, func): out = [] for element in l: out.extend(f(element)) return out def wrap(x: int) -> list[int]: return [x] def add(x: int, y: int) -> int: return x + y It is reasonable to add a docstring to flat_map, but I grant that this doesn't work as well with tooling that might involve not actually seeing the function. I agree that adding a long prefix of: from typing import Callable def flat_map( l: list[int], func: Callable[[int], list[int]] ) -> list[int]: is undesirable. But the biggest problem is not that "Callable..." has too many characters; the problem is that "Callable[[...], list[...]]" requires too many levels of sub-parsing. The PEP doesn't actually say what it proposes, [and you've suggested that my earlier attempt was slightly off, which may not bode well for likelihood of typos], but I'll *guess* that you prefer: def flat_map( l: list[int], func: ((int) ->[int]) ) -> list[int]: which is slightly shorter physically, but not much simpler mentally. It therefore creates an attractive nuisance. def flat_map( l: list[int], func: wrap ) -> list[int]: on the other hand, lets you read this definition without having to figure out what "wrap" does at the same time. "wrap" is a particularly bad example (because of the lack of semantic content in this example), but I think it still easily beats the proposed new solution, simply because it creates a "you don't need need to peer below this right now" barrier. > Any proposal for function prototypes using > `def` is directly competing against Callable or arrow syntax for the > common case that we want an anonymous, unnamed type written in place. I'm saying that catering to that "common" case is a trap, often leading you to a local optima that is bad globally. > But if we can use an existing function as the prototype instead of > having to declare the prototype, that shifts the balance. I agree that re-using an existing function with the correct signature is better, *even* when that function doesn't make a good default. ... > > I would say the opposite: most callback or key functions have very > simple signatures. > If my function takes a key function, let's say: > def spam(mylist:[str], > a: int, > b: float, > c: bool|None, > key: Callable[[str], str], > ) -> Eggs: > mylist = sorted(mylist, key=key) > ... > the relevant signature is (str) -> str. Do we really need to give that a > predefined named prototype? > def StrToStr(s: str) -> str: pass If you really care about enforcing the str, then yes, it is worth saying key: str_key and defining str_key function as an example def str_key(data:str)->str return str(data) > I would argue that very few people would bother. Because it would usually be silly to care that the list really contained strings, as opposed to "something sortable". So if you do care, it is worth making your requirement stand out, instead of losing it in a pile of what looks like boilerplate. -jJ ___ 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/32QYLA7UFTC54UM3CO3REIH57WLLBL6H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Function Prototypes
Steven D'Aprano wrote: > In comparison, Mark's version: > @Callable > def IntToIntFunc(a:int)->int: > pass > # in the type declaration > func: IntToIntFunc > uses 54 characters, plus spaces and newlines (including 7 punctuation > characters); it takes up three extra lines, plus a blank line. As > syntax goes it is double the size of Callable. I think it takes only the characters needed to write the name IntToIntFunc. The @callable def section is a one-time definition, and not logically part of each function definition where it is used. I get that some people prefer an inline lambda to a named function, and others hate naming an infrastructure function, but ... Why are you even bothering to type the callback function? If it is complicated enough to be worth explicitly typing, then it is complicated enough to chunk off with a name. I won't say it is impossible to understand a function signature on the first pass if it takes several lines and whitespace to write ... but it is much easier when the the declaration is short enough to fit on a single line. An @ on the line above complicates the signature parsing, but can be mentally processed separately. The same is true of a named-something-or-other in the middle. Having to switch parsing modes to understand an internal ([int, float, int] -> List[int]), and then to pop that back off the stack is much harder. Hard enough that you really ought to help your reader out with a name, and let them figure out what that names means separately, when their brain's working memory isn't already loaded with the first part of your own function, but still waiting for the last part. > It separates the type declaration from the point at which it is used, > potentially far away from where it is used. The sort of code that passes around functions tends to pass around many functions, but with only a few signatures. If this is really the only time you'll need that signature (not even when you create the functions that will be passed from a calling site?), then ... great. But be nice to your reader anyhow, unless the signature is really so simple that the type-checking software should infer it for you. Then be nice by leaving it out as cruft. [As an aside, I would see some advantage to def myfunc(f:like blobfunc) pointing to an examplar instead of a specifically constructed function-type. You discuss this later as either ... f:blobfunc ... or ... f:blobfunc=blobfunc ... and I would support those, if other issues can be worked out.] -jJ ___ 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/ZDCSTHMZVSILZZMGI3GTTBTWB53ZRJOI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
Why are Immutability and transitive Immortality needed to share an object across interpreters? Are you assuming that a change in one interpreter should not be seen by others? (Typical case, but not always true.) Or are you saying that there is a technical problem such that a change -- even just to the reference count of a referenced string or something -- would cause data corruption? (If so, could you explain why, or at least point me in the general direction?) -jJ ___ 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/E3XKSDEDOLHBFFUS2TXGDSLV7YOQUZJB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: subinterpreters and their possible impact on large extension projects
Petr Viktorin wrote: >>> In Python 3.11, Python still implements around 100 types as "static >>> types" which are not compatible with subinterpreters, ... >>> seems like changing it may break the C API *and* the stable ABI > > If sub-interpreters each need their own copy of even immutable built-in > > types, then what advantage do they have over separate processes? > They need copies of all *Python* objects. A non-Python library may allow > several Python wrappers/proxies for a single internal object, > effectively sharing that object between subinterpreters. > (Which is a problem for removing the GIL -- currently all operations > done by such wrappers are protected by the GIL.) OK, so what is the advantage of having multiple interpreters? The only advantage I can see is that if you're embedding what are essentially several distinct python processes, you can still keep them all inside the single process used by the embedding program. But seems pretty far along the "they're already compiling anyhow; so the ABI isn't crucial" path. -jJ ___ 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/C2Z2RPRAIGYDODATM5BQQL6DA6LEOVVN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
Guido van Rossum wrote: > On Wed, Dec 15, 2021 at 6:57 PM Jim J. Jewett jimjjew...@gmail.com wrote: > > Immortal objects shouldn't be reclaimed by garbage collection, but they > > still count as potential external roots for non-cyclic liveness. > So everything referenced by an immortal object should also be made immortal Why? As long as you can get a list of all immortal objects (and a traversal function from each), this is just an extra step (annoying, but tolerable) that removes a bunch of objects from the pool of potential garbage before you even begin looking for cycles. > -- even its type. Hence immortal objects must be immutable. This is probably a good idea, since avoiding changes also avoids races and Copy on Write and cache propagation, etc ... but I don't see why it is *needed*, rather than helpful. -jJ ___ 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/4KY5XSHRMP3F3CWAW2OUW4NRXN4AB7EM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
How common is it to reload a module in production code? It seems like "object created at the module level" (excluding __main__) is at least as good of an heuristic for immortality as "string that meets the syntactic requirements for an identifier". Perhaps also anything created as part of class creation (as opposed to instance initialization). -jJ ___ 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/F3IEICCQTKGZMRX3L4JS4NEZZNXVMZGA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
Immortal objects shouldn't be reclaimed by garbage collection, but they still count as potential external roots for non-cyclic liveness. -jJ ___ 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/FMIUHY6K3UUAUTK7GDTTOO4ULXO74QMP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: subinterpreters and their possible impact on large extension projects
> In Python 3.11, Python still implements around 100 types as "static > types" which are not compatible with subinterpreters, like > &PyLong_Type and &PyUnicode_Type. I opened > https://bugs.python.org/issue40601 about these static types, but it > seems like changing it may break the C API *and* the stable ABI (maybe > a clever hack will avoid that). If sub-interpreters each need their own copy of even immutable built-in types, then what advantage do they have over separate processes? -jJ ___ 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/B7WO5B426HBTG6KZVKQXTJSBQL2S2ILQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)
Christian Heimes wrote: > On 09/12/2021 19.26, Petr Viktorin wrote: > > If the code is the authoritative source of truth, we need a proper > > parser to extract the information. ... unfortunately I don't trust it > > enough to let it define the API. Bugs in the parser could result in > > the API definition silently changing. > There are other options than writing a new parser. GCC and Clang are > flexible. For example GCC can be extended with plugins and custom > attributes. But they have the same problem ... it can be difficult to know if there is a subtle bug in someone's understanding of how the plugin interacts with, for example, nested ifndef. The failure mode for an explicitly manually maintained text file is that something doesn't get added when it should, and the more conservative API consumers wait an extra release before using it. -jJ We could extend the header files with custom attributes and > then use a plugin to create an ABI file from the attributes. > I created a quick n' hack > https://github.com/python/cpython/compare/main...tiran:gcc-pythonapi-plugin?... > > as proof of concept. > The plugin takes > PyAPI_ABI_FUNC(PyObject *) PyLong_FromLong(long); > and dumps the declaration as: > extern struct PyObject * PyLong_FromLong (long int); "abi_func" > Christian ___ 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/PKQFEIK75EWVTNMLB5CGBYLQANZG6QJH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
Steven D'Aprano wrote: > On Sat, Nov 20, 2021 at 11:46:56PM -0800, Christopher Barker wrote: > Maybe PEP 563 could include a decorator in the typing module to > destringify all the annotations in a class or function? If it were in an annotations module, that would probably be sufficient. If it is in typing, then it is a very heavyweight dependency -- heavy enough that even the people actually using that module for development (and not for production runs) are worried about the costs. If the costs of the typing module are that high, it is not acceptable to impose them on people not otherwise using the module. -jJ ___ 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/ZQHP24T2PKRTDBGZ36KLBHLLOKITP5ON/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
Paul Moore wrote: > More hazy memories here, but I think the original proposal left open > the possibility of annotations not being types at all - for example, > being docstrings for the arguments, or option names for a "function > call to CLI" tool, etc. Absolutely. While it was clear that Guido's own use cases were about typing, annotations were explicitly not limited to typing, which is one reason why some of the later changes have felt to some people like bait and switch. Maybe it is already too late to avoid that. > ... the expectation was that annotations > would be *types*, Even from the start, it was assumed that they would be objects. (Specifically types was expected to be common, but not universal.) The particular way strings are being substituted for evaluated objects has sometimes reminded me of raising a string instead of an exception class/object. It will work, but it can seem sloppy, and it can be annoying if you were assuming otherwise and suddenly have to add a bunch of evals. (That said, I haven't yet been sufficiently motivated to even tease out exactly what the problems are, let alone to propose an alternative that also satisfies the typing fans -- in part because it feels like the obvious optimization is to just not run typing, and it isn't clear what middle grounds are generally worthwhile.) >... personally, I have the same discomfort > about using explicit string annotations for forward references, it > feels like I'm not declaring a "proper type". > If what I say above is right, the debate here isn't about whether > annotations "are for types", but rather about whether reading the > types in annotations and using them to affect behaviour *at runtime* > is a legitimate use of annotations. I see that as a second dispute, which I had previously missed. I think you're right, though. On the other hand, I'm not sure the solution to both isn't just a helper function that does the 2nd-pass resolution -- preferably without requiring that all the rest of typing be imported, since even the people who want to use the typing package agree that importing it is not lightweight. > ... I lurk on the typing-sig, and from an outsider's perspective, the > participants seem to be almost entirely designers or heavy users of > static type checkers. That gives a certain emphasis to the proposals > coming from that group. At times, it sort of reminds me of OWL and "Semantic Web". There are plenty of people who will want to use annotations as a tool, but won't be willing to wade through what can feel like "How many angels can dance on the head of a pin?" discussions. That said, I'm not sure how to best reach people who just want a rough-and-ready usually-good-enough tool. -jJ ___ 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/JL3AQ4UVEVWXYTRFAVGVHNT23W2NCUDI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
Steven D'Aprano wrote: > I think > that many editors in common use don't support bidirectional text, or at > least the ones I use don't seem to support it fully or correctly. ... > But, if there is a concrete threat beyond "it looks weird", that it > another issue. Based on the original post (and how it looked in my web browser, after various automated reformattings, it seems that one of the failure modes that buggy editors have is that stuff can be part of the code, even though it looks like part of a comment, or vice versa This problem might be limited to only some of the bidi controls, and there might even be a workaround specific to # ... but it is an issue. I do not currently have an opinion on how important of an issue it is, or how adequate the workarounds are. -jJ ___ 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/ECO4R655UGPCVFFVAOQZ3DUZVHQY75BX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
Stephen J. Turnbull wrote: > Christopher Barker writes: > > For example, in writing math we often use different scripts to mean > > different things (e.g. TeX's Blackboard Bold). So if I were to use > > some of the Unicode Mathematical Alphanumeric Symbols, I wouldn't > > want them to get normalized. Agreed, for careful writers. But Stephen's answer about people using the wrong one and expecting it to work means that normalization is probably the lesser of evils for most people, and the ones who don't want it normalized are more likely to be able to specify custom processing when it is important enough. (The compatibility characters aren't normalized in strings, largely because that should still be possible.) > In fact, I think adding these symbols to Unicode was a bad idea; they > should be handled at a higher level in the linguistic stack (by > semantic markup). When I was a math student, these were clearly different symbols, with much less relation to each other than a mere case difference. So by the Unicode consortium's goals, they are independent characters that should each be defined. I admit that isn't ideal for most use cases outside of math, but ... supporting those other cases is what compatibility normalization is for. > It's also a UX problem. At slightly higher layer in the stack, I'm > used to using Japanese input methods to input sigma and pi which > produce characters in the Greek block, and at least the upper case > forms that denote sum and product have separate characters in the math > operators block. I understand why people who literally write > mathematics in Greek might want those not normalized, but I sure am > going to keep using "Greek sigma", not "math sigma"! The probability > that I'm going to have a Greek uppercase sigma in my papers is nil, > the probability of a summation symbol near unity. But the summation > symbol is not easily available, I have to scroll through all the > preceding Unicode blocks to find Mathematical Operators. So I am > perfectly happy with uppercase Greek sigma for that role (as is > XeTeX!!) I think that is mostly a backwards compatibility problem; XeTeX itself had to worry about compatibility with TeX (which preceded Unicode) and with the fonts actually available and then with earlier versions of XeTeX. -jJ ___ 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/JNFLAQUKNCWCJSMBNJZGHVD5ZELOTU6G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
Compatibility variants can look different, but they can also look identical. Allowing any non-ASCII characters was worrisome because of the security implications of confusables. Squashing compatibility characters seemed the more conservative choice at the time. Stestagg's example: е = lambda е, e: е if е > e else e shows it wasn't perfect, but adding more invisible differences does have risks, even beyond the backwards incompatibility and the problem with (hopefully rare, but are we sure?) editors that don't distinguish between them in the way a programming language would prefer. I think (but won't swear) that there were also several problematic characters that really should have been treated as (at most) glyph variants, but ... weren't. If I Recall Correctly, the largest number were Arabic presentation forms, but there were also a few characters that were in Unicode only to support round-trip conversion with a legacy charset, even if that charset had been declared buggy. In at least a few of these cases, it seemed likely that a beginning user would expect them to be equivalent. -jJ ___ 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/GNT3AG2SCVLMCJAZXSTIWFKKAYG25E7O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
ptmcg＠austin.rr.com wrote: > ... add a cautionary section on homoglyphs, specifically citing > “A” (LATIN CAPITAL LETTER A) and “Α” (GREEK CAPITAL LETTER ALPHA) > as an example problem pair. There is a unicode tech report about confusables, but it is never clear where to stop. Are I (upper case I), l (lower case l) and 1 (numeric 1) from ASCII already a problem? And if we do it at all, is there any way to avoid making Cyrillic languages second-class? I'm not quickly finding the contemporary report, but these should be helpful if you want to go deeper: http://www.unicode.org/reports/tr36/ http://unicode.org/reports/tr36/confusables.txt https://util.unicode.org/UnicodeJsps/confusables.jsp > I wanted to look a little further at the use of characters in identifiers > beyond the standard 7-bit ASCII, and so I found some of these same > issues dealing with Unicode NFKC normalization. The first discovery was > the overlapping normalization of “ªº” with “ao”. Here I don't see the problem. Things that look slightly different are really the same, and you can write it either way. So you can use what looks like a funny font, but the closest it comes to a security risk is that maybe you could access something without a casual reader realizing that you are doing so. They would know that you *could* access it, just not that you *did*. > Some other discoveries: > “·” (ASCII 183) is a valid identifier body character, making “_···” a valid > Python identifier. That and the apostrophe are Unicode consortium regrets, because they are normally punctuation, but there are also languages that use them as letters. The apostrophe is (supposedly only) used by Afrikaans, I asked a native speaker about where/how often it was used, and the similarity to Dutch was enough that Guido felt comfortable excluding it. (It *may* have been similar to using the apostrophe for a contraction in English, and saying it therefore represents a letter, but the scope was clearly smaller.) But the dot is used in Catalan, and ... we didn't find anyone ready to say it wouldn't be needed for sensible identifiers. It is worth listing as a warning, and linters should probably complain. > “_” seems to be a special case for normalization. Only the ASCII “_” > character is valid as a leading identifier character; the Unicode > characters that normalize to “_” (any of the characters in “︳︴﹍﹎﹏＿”) > can only be used as identifier body characters. “︳” especially could be > misread as “|” followed by a space, when it actually normalizes to “_”. So go ahead and warn, but it isn't clear how that could be abused to look like something other than a syntax error, except maybe through soft keywords. (Ha! I snuck in a call to async︳def that had been imported with *, and you didn't worry about the import *, or the apparently wild cursor position marker, or the strange async definition that was never used! No way I could have just issued a call to _flush and done the same thing!) > Potential beneficial uses: > I am considering taking my transformer code and experimenting with an > orthogonal approach to syntax highlighting, using Unicode groups > instead of colors. Module names using characters from one group, > builtins from another, program variables from another, maybe > distinguish local from global variables. Colorizing has always been an > obvious syntax highlight feature, but is an accessibility issue for those > with difficulty distinguishing colors. I kind of like the idea, but ... if you're doing it on-the-fly in the editor, you could just use different fonts. If you're actually saving those changes, it seems likely to lead to a lot of spurious diffs if anyone uses a different editor. -jJ ___ 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/NPTL43EVT2FF76LXIBBWVHDU6NXH3HF5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
Stephen J. Turnbull wrote: > Jim J. Jewett writes: > > At the time, we considered it, and we also considered a narrower > > restriction on using multiple scripts in the same identifier, or at > > least the same identifier portion (so it was OK if separated by > > _). > > This would ban "παν語", aka "pango". That's arguably a good idea > (IMO, 0.9 wink), but might make some GTK/GNOME folks sad. I am not quite motivated enough to search the archives, but I'm pretty sure the examples actually found were less prominent than that. There seemed to be at least one or two fora where it was something of a local idiom. >... I don't recall ever seeing > an identifier with ASCII and Japanese glommed together without a > separator. It was almost always of the form "English verb - Japanese > lexical component". The problem was that some were written without a "-" or "_" to separate the halves. It looked fine -- the script change was obvious to even someone who didn't speak the non-English language. But having to support that meant any remaining restriction on mixed scripts would be either too weak to be worthwhile, or too complicated to write into the python language specification. -jJ ___ 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/CUTMZG55WY3CLNNKB6VTPCOUXJ22EEZY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python
Chris Angelico wrote: > I'm not sure how a linter would stop > someone from publishing code on PyPI that causes confusion by its > character encoding, for instance. If it becomes important, the cheeseshop backend can run various validations (including a linter) on submissions, and include those results in the display template. ___ 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/NO6XRUPLOEAO2ZMUJEXXRNQMVFWZUGLT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
Serhiy Storchaka wrote: > 02.11.21 16:16, Petr Viktorin пише: > > As for \0, can we ban all ASCII & C1 control characters except > > whitespace? I see no place for them in source code. > All control characters except CR, LF, TAB and FF are banned outside > comments and string literals. I think it is worth to ban them in > comments and string literals too. In string literals you can use > backslash-escape sequences, and comments should be human readable, there > are no reason to include control characters in them. If escape sequences were also allowed in comments (or at least in strings within comments), this would make sense. I don't like banning them otherwise, since odd characters are often a good reason to need a comment, but it is definitely a "mention, not use" situation. > > For homoglyphs/confusables, should there be a SyntaxWarning when an > > identifier looks like ASCII but isn't? > > It would virtually ban Cyrillic. There is a lot of Cyrillic letters > which look like Latin letters, and there are complete words written in > Cyrillic which by accident look like other words written in Latin. At the time, we considered it, and we also considered a narrower restriction on using multiple scripts in the same identifier, or at least the same identifier portion (so it was OK if separated by _). Simplicity won, in part because of existing practice in EMACS scripting, particularly with some Asian languages. > It is a work for linters, which can have many options for configuring > acceptable scripts, use spelling dictionaries and dictionaries of > homoglyphs, etc. It might be time for the documentation to mention a specific linter/configuration that does this. It also might be reasonable to do by default in IDLE or even the interactive shell. -jJ ___ 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/BCZI6HCZJ34XABFFZETJMWFQWOUG4UB4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python
"The East Asian symbol for *ten* looks like a plus sign, so ``十= 10`` is a complete Python statement." Normally, an identifier must begin with a letter, and numbers can only be used in the second and subsequent positions. (XID_CONTINUE instead of XID_START) The fact that some characters with numeric values are considered letters (in this case, category Lo, Other Letters) is a different problem than just looking visually confusable with "+", and it should probably be listed on its own. -jJ ___ 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/RV7RU7DGWFIBEGFKNYDP63ZRJNP5Y4YU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
Larry Hastings wrote: > In Python, if you evaluate an undefined name, Python raises a > NameError. This is so consistent I'm willing to call it a "rule". Would it help the think of the function creation as catching that exception, and then finishing construction with its own version of NaN? ___ 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/KGMXBLE2AP2TBOUBOVCTNFHAVX77ZFLO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Steve Dower wrote: > Okay, I'll let myself get sucked into responding ONE TIME, but only > because you gave me such a nice API to work with :) This actually pushed me hard towards adding the null-aware operators. I agree that the named-function approach Paul suggests is better. I admit that there are times when a comprehensive model is good, and that if the DB schema is automatically generated, it should look something like this. But this is long enough that I would be unhappy if it were what I had to read to understand the database in the first place. (Yes, I know Java beans are pretty widely tolerated, but ... that doesn't make longer code desirable.) ___ 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/OFZZ4PYT4EWTXHZ2PGRO3FBFRPCV4NZC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC on Callable Type Syntax
It isn't clear to me that reusing the inspect.Signature object was even considered. If it was rejected as too complicated for most signatures, please put that in the PEP. My own opinion, admittedly not as a typing fan, is that if you need enough details to want more than Callable, then you probably do want the full power of inspect.Signature, though you may also want some convenience methods to indicate that certain portions of the signature are undefined, rather than following the example function. -jJ ___ 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/PTG2WNWIFBBCSDSB4HC5QENXILD6LGUC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 except* formatting
Yury Selivanov wrote: > IMO it would make more sense to write `except all E`, > but `all()` is a built-in and so this would be at > odds with (1). [`try: .. except group:` already being valid > syntax today ] If anything, that makes "except all E" less of a problem; the built-in all is not an exception, so any current meaning would be, at the least, a dodgy renaming of a built-in to something unrelated -- in which case a reader *should* already be suspicious. -jJ ___ 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/GRVMPGZFNE67GE25SQCRCQWZQFZMA7PX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 except* formatting
except* looks like the exception statement has a footnote, which isn't wrong. *(E1, E2) looks like they are being unpacked, which is wrong. -jJ ___ 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/7IKS3YFPFT5JO7QBJGNPMM33XUYKK7CK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Making code object APIs unstable
Guido van Rossum wrote: > On Fri, Aug 13, 2021 at 11:17 AM Terry Reedy tjre...@udel.edu wrote: > > On 8/13/2021 1:24 PM, Guido van Rossum wrote: > I'm actually not sure what use case you're talking about. "source/code that hadn't actually changed and was just being re-compiled and run". I've done it as the first stage of porting or reviving long-dead code. I've seen it done when deployment is handed off to a different group than development, and also when using a library component that had not been recently maintained. ___ 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/B2VROA577DHONXYE3OL5XXKKLLRUNX6R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Making code object APIs unstable
How badly would the code objects be crippled? >(no exception table, no endline/column tables, > qualname defaults to name) That sounds like it would be a pain for debugging, but might still work for source/code that hadn't actually changed and was just being re-compiled and run (possibly with the caveat that the data needs to be clean enough to avoid exceptions). Since that is a common use case, and one where there is a good reason not to make any source-level changes, it would be good to keep compatibility for that minimal level. -jJ ___ 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/URGJJWVEDKROLYOUWQ5QQ5CROZHLTH7G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is the Python review process flawed?
esmeraldagarcia＠byom.de wrote: >> "If you would like more value out of it or to speed >> up the process, you can provide your own reviews." - > Seriously? I can't help but feel like that comment > sounds kinda arrogant. I've done it and it sometimes helps. That said, there is still a problem -- it isn't always easy to tell at a glance which issues are reviewed and apparently OK. There is a Stage field that can be changed from Patch Review to Commit Review, and at least some core committers seem to search on that. If you have specific suggestions on better ways to signal "This is important, as confirmed by [StackOverflow / twitter thread / downstream bug report ...]" or "This patch has already been reviewed and someone besides the author thinks it is ready", that could be very helpful. And now would be a great time to suggest such improvements, since the bug tracker may be migrated soon. >> "Most stdlib modules have no maintainer and past >> maintainers are gone for a long time." > - I'm flabbergasted. I don't know what to say. > Can't you not see how bad that is?! I can, but it is also true of almost every long-term project I have worked on for pay. -jJ ___ 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/AEVOUI6SAMFRK2VA5C6E3XMINRYWWRE3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks
Antoine Pitrou wrote: > On Sat, 8 May 2021 02:58:40 + > Neil Schemenauer nas-pyt...@arctrix.com wrote: > > It would be cool if we could mmap the pyc files and have the VM run > > code without an unmarshal step. > > What happens if another process mutates or truncates the file while the > CPython VM is executing code from the mapped file? Crash? Why would this be any different than whatever happens now? Just because it is easier for another process to get (exclusive) access to the file if there is a longer delay between loading the first part of the file and going back for the docstrings and lnotab? -jJ ___ 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/ONMS26WLPIT35H5VX4Z6STPYWSXXBQVJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
Nathaniel Smith (in a conversation with Irit) wrote:
> ... suggested having each
> 'except Blah as exc' clause be executed once, receiving an
> ExceptionGroup containing all the Blah exceptions. Guido pointed out
> that this broke typing -- 'exc' would not longer have type 'Blah' --
> and I was like... okay yeah that's a fatal flaw, never mind.
The fact that "Blah as exc" could return either a single Blah or a collection
of Blahs would be annoying, but not fatal -- that seems well within the level
of ambiguity typing can deal with.
> never seriously raised the 'execute a single clause multiple times'
> option, because of the issue where in the nested design, taking
> individual exceptions out of an ExceptionGroup breaks tracebacks.
This also seems like something that isn't hard to work around. The obvious way
would involve shared (parts of) tracebacks, but even that isn't required.
> multiple-except-executions option should be rejected because users
> have written code like 'except SomeError: ...' with the expectation
> that the 'except' clause would run exactly once.
That is indeed a problem, because some error handlers would do bad things if
rerun.
> The problem is, *all* our options for how 'except' should interact
> with ExceptionGroups will somehow break previous expectations.
agreed.
> Concretely: imagine you have a pre-existing 'except SomeError', and
> some new code inside the 'try' block raises some number of
> 'SomeError's wrapped in an ExceptionGroup. There are three options:
> - Execute the 'except' block multiple times. This breaks the
> expectation that it should be executed at most once.
Do we know how bad this really is? A second rollback or cancel or
endConnection won't do what is expected, but they normally won't do much harm
either. A second logError does the right thing.
> - Execute the 'except' block exactly once. But if there are multiple
> SomeError's, this require they be grouped and delivered as a single
> exception, which breaks typing.
I'm not worried about typing, but I am worried about silently dropping all but
the "first" SomeError.
On the other hand, in practice were they all (including the "first") dropped
before, in favor of some sort of superseding asyncCancelledError?
> - Execute the 'except' block zero times. This is what the current PEP
> chooses, and breaks the expectation that 'except SomeError' should
> catch 'SomeError'.
To me, this seems the worst of the three options, but ... maybe it is
effectively the status quo often enough that it becomes the least bad?
> > I'm confused about the flattening suggestion - above you talk about "flat
> > EG", but below about tracebacks. It's not clear to me whether you want EG
> > to be flat (ie no nesting of EGs) or just the traceback to be flat (but you
> > can still have a nested EG).
> > Hmm, I was thinking about making both of them flat, so no nested EGs.
> In all my designs, the only reason I ever had nesting was because I
> couldn't figure out any other way to make the tracebacks work. Do you
> have some other motivation for wanting nesting? If so that would be
> interesting, because it might point to why we're talking past each
> other and help us understand the problem better...
When I view this as strictly a typing problem, it matters which exceptions got
joined at which junction; the shape of the tree is part of the type.
When I view this as a production support programmer, I really don't care about
that ... I only care what triggered each SomeException so that I can account
for all the bad data instead of just one piece. Having to dig through multiple
layers of grouping to get to each original SomeException separately is just an
annoyance that *will* cause juniors to sometimes miss part of the bad data.
("Open the door and check for problems" is a lot easier to learn and remember
than a recursive "Open the door and check for problems or other doors, and then
repeat on each door you find.")
-jJ
___
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/VO5I7DMRYAB7EPUYSYEHHQFLGZAYWUB4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 563 and 649: The Great Compromise
Christopher Barker wrote: > ... folks don't want annotations to hurt run-time performance, > particularly when they are being used primarily for > pre-run-time static type checking. So are we looking for three separate optimization levels at compile time? Base level: evaluate everything, keep it however the original annotations PEP said to keep it. String level: Characters in an annotation are not evaluated; they just get stored in a string. The string (rather than its value) is then kept however the original annotations PEP said things would be kept. Removal level: Annotations are used only with source code (perhaps by static analyzers before compilation); they are dropped entirely during compilation. This might go well with the old compilation mode that drops docstrings. -jJ ___ 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/6S2CALLLQPDOI2WQFIINW37CXIO5J7VR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2
Larry Hastings wrote: > On 4/14/21 1:42 PM, Baptiste Carvello wrote: > > Are there specific annoyances associated with quoting always, apart > > from the 2 more characters? > Yes. Since the quoted strings aren't parsed by Python, syntax errors in > these strings go undetected until somebody does parse them (e.g. your > static type analyzer). This is a real problem. But in theory, your code editor (and python) *could* parse the strings. They generally don't, but I'm not sure asking them to do that is much harder than asking them to deal with new syntax. -jJ ___ 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/JR2RKEEUI3WSIUBZOJ4J3EVRTVYGLXSU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2
Baptiste Carvello wrote: > Le 14/04/2021 à 19:44, Guido van Rossum a écrit : > > No, what I heard is that, since in *most* cases the string quotes are > > not needed, people are surprised and annoyed when they encounter cases > > where they are needed. > Well, I had assumed quotes would be used in all cases for consistency. That does seem like a reasonable solution. Redundant, ugly, and annoying, but safe and consistent. Sort of like using type constraints in the first place. :D > > ... the rule for finding the end of > > an annotation would be very simple -- just skip words until the next > > comma, close paren or colon, skipping matching brackets etc. > ... But the hypothetic "def foo(prec: > --precision int):" is already less readable. Will finding the closing > comma or colon always be obvious to the human reader? Nope. "--" sometimes means "ignore the rest of the line, including the ")". At the moment, I can't remember where I've seen this outside of SQL, but I can guarantee that if I read it late enough at night, the *best* case would be that I notice the ambiguity, guess correctly and am only annoyed. -jJ ___ 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/MV3HQASUSAEKC332UFUDWQNONLCXZDRZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?
Paul Moore wrote: > What's wrong with Version(module.__version__)? And if the __version__ > attribute isn't a valid version, raise an exception? I don't have a deep answer, but I do think __version__ should be specified (or at least mentioned) at https://docs.python.org/3/reference/datamodel.html At the moment, I can't even find a listing of possible __dunder__ attributes, though I'm almost sure I've seen one in the past. -jJ ___ 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/AG344CLSKM7BDOYP3CWGXGBNFSPWVQU4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
Looking at the following PEP example, I'm still not sure what he should do to handle some but not all OSError instances: ...raise ExceptionGroup( ... "eg", ... [ ... ValueError(1), ... TypeError(2), ... OSError(3), ... ExceptionGroup( ... "nested", ... [OSError(4), TypeError(5), ValueError(6)]) ... ] except *OSError seems to get him an ExceptionGroup that he still has to manually tree-walk to handle the OSErrors that he can actually handle. Once he has manually tree-walked, he has to manually re-raise the other OSErrors that he hasn't filtered out, and they become a sibling of the original ExceptionGroup, because they're (now) being raised at a different location. (Or, not *really* the original ExceptionGroup, but one that looks like it without any OSErrors.) This new sibling relationship is there to show that a failed or incomplete attempt was made at resolving the OSErrors, but no such attempt was made at the ValueErrors or TypeErrors. Alternatively, he *might* be able to just grab Exception, then use a complicated callback to subgroup only the OSErrors that he will be able to handle, and raise the complement of that. It will still add another layer of ExceptionGroup, but won't split the remainders. This seems like an awful lot of work to preserve and elaborate structural relations between different exceptions that were originally accidental. (I am assuming that the original relation was "these all happened, probably in different execution threads" and the new relations are just accidents of what got partially handled along the way, or maybe the order in which different execution threads got merged.) I can't imagine ever needing to care about the full tree structure unless I'm re-implementing asycio/trio/curio. Even if that structural information is important to my own framework, that just means I should create more intermediate tasks to handle it more quickly, before the next level of aggregation. I would much prefer an API that let me pattern-match (even just by class of the exception instances, though preferably also by attributes), process each exception (as though it were the only one) within the code block that match selects, and indicate whether that one exception should be raised further or not. -jJ ___ 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/WTZUGBFWFXMGAFHNTTBMUYFGMQCPV5N6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?
> And unlike a venv, "python -m" doesn't let you ensure > that the code executed is the version installed in user site-packages I have had enough problems with this that when I do modify/replace something, I put in a marker that I can check for explicitly. Expecting this marker to run automatically at import (and the results not to be swallowed) turned out to be insufficient. > it could be coming from a directory earlier in sys.path. The obvious solution is to put the current directory in front of sys.path. Alas, security folks didn't like that idea. ___ 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/M3U72J6OR53LF5REA7LOZBIQUUXXHV65/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
> In fact, if you're happy with RuntimeError here, making > ExceptionGroup inherit from Exception (instead of > BaseException) would do just as well -- after all RuntimeError > is pretty arbitrary Agreed, and I think it should inherit from Exception. > (in fact, it's wrong, because the problem is a static bug in the > code, not something that went wrong at run time). Something went wrong deep inside an individual task. The only clear static bug is that the async library changed how it reported that, and my except clause hasn't done the make-work to keep in step. > Let's see how this compares to the alternatives. First let's define > three key examples. > Example 1: > try: >raise ExceptionGroup(ValueError) > except Exception: > Example 2: > try: > raise ExceptionGroup(ValueError) > except ValueError: Example 2(a) : try: raise ExceptionGroup(ValueError,OtherError) except ValueError: > Example 3: > try: >raise ExceptionGroup(asyncio.CancelledError) > except Exception: I would prefer that the except clause be executed in all of the examples, but I admit that 2a is a problem, because it could end up silently losing OtherError. And I admit getting example 2 to do the right thing if 2a doesn't might be too much of a contortion. For example 3, I may be missing a subtle point, but I feel that by the time you get to code which doesn't expect asyncio.CancelledError, then you have already cancelled as far as you should. Cancelling may want to bubble up through several other tasks, but it shouldn't kill the whole server, just because the trampoline got sloppy. -jJ ___ 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/RHL3E2IBCIW2SP5L5W3BHWIWB4DV6U55/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?
[They are not CS students] > Why is that relevant? Because for many users, python is NOT a programming language; it is an application like any other. It happens to be very powerful and flexible, but the point isn't to program; it is to produce better reports. If the hurdle to get started (either initially, or after a while away) is too high, then it is not a useful tool. It is OK to have all sorts of power-user knobs, but the default instructions should just work ... they shouldn't have to say "ensure you have proper settings for these 6 things you don't care about or understand", because the default install should just choose reasonable default settings and take care of them. > there are some basic fundemental skills that every amateur or > professional programmer needs to know, such as: My point is that plenty of python users have no intention of being a programmer. > how to edit files and save them (fair ... but plenty of programs don't even *let* you do this with an external editor; there is no reason the _default_ should force people to pick and configure an external editor. IDLE tends to do OK here.) > which file am I actually running? > which interpreter am I actually running? > how do I tell the computer to use a different interpreter? If you need to care about any of these, then the environment is fighting you -- and the application probably stinks. Programmers have to deal with it because of bootstrapping, but there is no reason that we should assume all python users need that flexibility or want that responsibility. > Writing code to run on any platform is a hard problem that > requires complex solutions. Thus the preference for solving it once in the library/official documentation/reference installer. Experts can build on it or opt out, but non-programmers shouldn't have to worry about cross-platform issues just to use python. -jJ ___ 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/FPPE35KUME5JDDRSZ44RXRDN366EJNAC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
> Why would you want a different flavor of ExceptionGroup? The easiest example you took care of by saving the exceptions in a list instead of a set. Next would be the ExceptionGroup vs BaseExceptionGroup that I *don't* like, but someone might. There are also libraries that promise to raise only exceptions derived (possibly through multiple inheritance) from a particular marker exception. But honestly, my biggest concern is that it just seems wrong for any class to be final, and it has sometimes been an irritant even for such obvious cases cases as Boolean. So why is this so special? -jJ ___ 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/2AJJIOLL4RB2TKLYDA2Y7HGDRWEBUD5J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
ValueError("Partner: 3 File: 127 record: 93 is missing field: currency") tells
the production support people who to contact and what to say.
I'm not sure what additional context would be helpful, let alone how it might
have been available "at the time", but lost now that the ValueAttribute is
collected into an ExceptionGroup.
-jJ
___
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/GXUJTE25TWR5AKAYCTETKL4YWXQC2FR5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
> Thank you for turning to what happens with 'except ValueError' when an
> ExceptionGroup[ValueError] is raised, this is important.
> I'm not sure it's safe to assume that it is necessarily a > programming
>error, and that the interpreter can essentially break the program in this
> case.
I'm betting it means a ValueError was raised, but then something (probably an
asynchronous framework) aggregated it. I won't swear you would never want to
distinguish the two cases, or to distinguish them both from
ExceptionGroup[ExceptionGroup[ExceptionGroup[ValueError]]], but ... normally
you wouldn't.
> Is this not allowed?
>try:
>try:
>obj.func()# function that raises ExceptionGroups
>except AttributeError:
>logger.info("obj doesn't have a func")
>except *(AttributeError, SyntaxError):
>logger.info("func had some problems")
Allowed, but probably in error ... no AttributeError will get through to the
except * unless it happened inside the except AttributeError handler. Did you
mean:
try:
try:
obj.func# function that raises ExceptionGroups
except AttributeError:
logger.info("obj doesn't have a func")
obj.func()
except *(AttributeError, SyntaxError):
logger.info("func had some problems")
I see this as an argument that the except/except* split is tricky, but I don't
think it says anything about whether except* clauses should be able to see into
nested ExceptionGroups ... nor am I at all confident that I understood your
intent.
-jJ
___
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/XOAB7IJNXOHRL3HRVZ5VZON6MVHOPXB3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
You still need except* for the (unusual?) case where the ExceptionGroup contains multiple individual Exceptions, and you want them all to be processed. (This possibility is the justification for the PEP, but the difficulty of associating an exception with the specific task that raised it suggests that exceptions are still intended to be rare, rather than a back-channel communications band.) As written, you also need except* to unwrap, so that ExceptionGroup(ValueError) can be handled by "except ValueError" instead of "except RuntimeError" (or except ExceptionGroup) followed by cause-unwrapping. -jJ ___ 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/B6JKV2JIFA76CMDOK2IBVBA2MIQKYDVR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
FWIW, the only situation I can think of where you would care that the enclosed exception instances are BaseException but not regular Exception is interactive debugging, and even then there are enough other ways to kill the whole process that I think most people would use one of them instead of wanting a different BaseExceptionGroup that breaks the server instead of just the servlet. I suppose you could argue that the distinction encourages the "good practice" of defensively wrapping "except Exception" in an "except BaseException" that is itself wrapped in a bare except. I suspect it would actually just push people to replace that "except Exception" with the bare except and give up on the logging, because that is a quicker adjustment. ___ 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/IDVNUNBAMFKZVT64TFV5QYLB3BJTABBD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
> We keep the ability to wrap any exception, while we lose the "fail-fast if > you forget to handle an ExceptionGroup" feature, which was intended as a > kindness towards those who abuse "except Exception". How is this a kindness? Whenever I've used except Exception or stronger, it was a sanitary barrier around code that might well do unpredictable or even stupid things. Adding a new kind of exception that I hadn't predicted -- including ExceptionGroup -- would certainly fit this description, and I want my driver loop to do what I told it. (Probably log an unexpected exception, and continue with the next record. I honestly don't even want a page, let alone a crash, because data from outside that barrier ... is often bad, and almost never in ways the on-call person can safely fix. And if they don't have time to find it in the logs, then it isn't a priority that week.) > If we adopt this solution then letting an ExceptionGroup escape from code > that is not supposed to raise it, is not a fatal error, it's just some > exception like any other. Good! If we're not coordinating so closely that I already know to handle the ExceptionGroup in advance, then that is exactly what should happen (and except Exception with a log and log analysis is the right way to deal with it). > So there is no longer a distinction between code that raises > ExceptionGroups and code that doesn't. Any code can propagate them, like > any code can raise any other exception. Good; special cases and all. > Does this mean that more code needs to be aware of the possibility of them > showing up? Is that a problem? Honestly, no. You seem to be assuming a very well-controlled environment where any potential problems would be caught long before production. My experience is that such optimism is never warranted, *particularly* at places that claim to have a heavy process to ensure such early (or in-time) bug-catches. > What would we have done here if we were building Python from scratch? Raise anything you want. Or maybe only strings and exceptions. Or maybe only stuff inheriting from a marker class named BaseException ... but we probably wouldn't add a parallel base marker that catch-all code *also* needs to be aware of. (And since we would be starting from scratch, the catch-all wrapper code would certainly not have to be deployed on a conservatively managed server, before lightweight exploratory less-centralized client code could start using it.) -jJ ___ 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/TEBYSGMMT3SJRVTPCZQFMHJQPBOV6Q74/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?
I think his point is that most of his students (economics or business, rather than comp sci) will never need to use Perl or C or Java. Python is friendly enough to be useful, but this is still a major pain point. The problem is made worse because it often hits at the beginning instead of 7 lessons in, when they would have some reason to think it is worth struggling through and will eventually work. ___ 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/XWBEK2Q3DBY3M7HV7BN2GJPJCMPXJPQB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
Ideally, (at least) trivial subclasses could be declared, and the class itself
would serve as the marker. I would prefer regular subclasses, so that they
could offer methods as well. Alternatively, at least copy the instance
__dict__ to the new ExceptionGroup instance.
By compatible __init__ and __new__, I mean "whatever you do in
ExceptionGroup.subgroup to create a new instance with fewer contained
Exceptions ... do the same with MyExceptionGroup." I'm assuming that
"whatever" is to call __new__ and __init__ with "a message string and a
sequence of the nested exceptions, for example: ExceptionGroup('issues',
[ValueError('bad value'), TypeError('bad type')])."
-jJ
___
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/SFE46EGTGLXLCJDXZ4EI6HOEATYREOL4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
If it (compatible __new__ and __init__) needs to be checked at definition time, just try create an instance passing the same arguments you would pass to the base class. If the creation it doesn't raise an exception, that is good enough. This isn't about theoretical type safety against malice; it is about defining the minimal protocol for an ExceptionGrouping that has to be supported by someone who wants something other than the default flavor. ___ 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/JW4BFAR7SN23NF7S6TRGOROJIMPDGQEJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
Are you saying that except *ValueError as e: will catch ValueError and ExceptionGroup(ValueError) but miss ExceptionGroup(ExceptionGroup(ValueError)) ? ___ 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/VLPYAILCWTGG25WYJXUA47LIQPULQ7ZM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
By the time a KeyboardInterrupt or SystemExit is being grouped into an ExceptionGroup, it already isn't being treated as an immediate interruption ... it has (presumably) already killed its own execution path, but it should not kill the program as a whole. Whether ExceptionGroup inherits from Exception or BaseException shouldn't matter for deciding what it can group. -jJ ___ 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/XSEL22SDNEX2BWT7GS7OUPDAA2UVMH42/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
Please include an example for: except *ExceptionGroup: pass I *think* it swallows all exceptions, instead of re-raising. I *think* it also catches (and then swallows) bare exception that were not initially part of an ExceptionGroup. I *think* it catches anything that gets raised, not just subclasses of Exception (or even BaseException). ___ 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/NTQ22LUIKNRNA2YHKOLVPR5GI2KW6TLW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
The "no subclasses" seems pretty severe, particularly if you can't even use marker attributes because it isn't clear when a different instance of container ExceptionGroup will be substituted. The justification for this restriction was that .split() had to be be able to instantiate ... wouldn't it be enough to just say that subclasses need a compatible __init__ and __new__ for that reason, and then leave it to consenting adults? -jJ ___ 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/5OLFDKJCNKLIJJQMNYYLQGV53Z7ZTRC5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
Petr: What about except *(TypeError, ExceptionGroup):? Irit: Good question. We should block that as well. But https://www.python.org/dev/peps/pep-0654/#backwards-compatibility seems to explicitly recommend the very similar: except (Exception, ExceptionGroup): ___ 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/N22HZBABDVM2GCEIWHOCTPGJDRSRVGS5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Security releases of CPython
Looking at the other replies, I'm wondering if you fully understand python's variant of version numbering. I suggest we change the announcement template from: "Python 3.9.2 is the newest major release of the Python programming language, and it contains many new features and optimizations." to: "Python 3.9 was the newest major release of the Python programming language, and it contains many new features and optimizations. Python 3.9.2 is a bugfix and security release; it has no new features relative to 3.9." 3.9.1 (and 3.9.27, if that ever happens) are supposed to the be the same as 3.9.0, except with bugs fixed. Because "a feature is just a bug with tenure", there comes a time when non-security bugs stop being fixed. There isn't a hard-and-fast rule on when that is, but within a year or two. Looking back, a .6 release was unlikely to contain much beyond security. Even before that time, CPython still tries to err on the overly-cautious side of "can this bug-fix be backported", because of an overly-optimistic assessment ~20 years ago. (A harmless feature was added in a backwards-compatible way, but for a while instructions had to specify a bugfix version as well.) In theory, someone could release 3.9.0s1, 3.9.0s2, ... 3.9.1s1 ... but what would be the point? 3.9.1s2 would have contained exactly the same changes as 3.9.2rc, which apparently didn't get picked up much. The difference between 3.9.2rc and 3.9.2 does include a non-security bugfix -- a part of the Windows API that was advertised as working will now actually work. Is that really adding much extra upgrade risk? Of course, to get these extra releases, someone will have to be more careful about deciding what counts as a security fix vs a regular bugfix, which is already sometimes fuzzy. And realistically, it is *only* the security fixes that are likely to be a problem for working code ... Even if the releases were trivial, how much value would that actually provide? -jJ ___ 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/WDBRC4WSOYSHMQVYDWHWSO2ITH4YGRQC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 647 (type guards) -- final call for comments
Eric Traut wrote: """It must be possible to express the type guard within the function signature. In other words, the implementation should not need to be present. This is important for compatibility with type stubs and to guarantee consistent behaviors between type checkers.""" Can type stubs include a docstring? If so, then adding subsequent lines that are only parameter annotations doesn't seem like a problem. And frankly, allowing subsequent lines (possibly restricted to first-except-docstrings) doesn't seem any more invasive than adding another magic type that has to be interpreted differently. (I understand it might be more coding in practice, based on one solution having already been written.) def is_str_list(val: List[object]) -> bool: """Determines whether all objects in the list are strings""" val: NarrowsTo[List[str]] I agree that Greg's suggestion of def is_str_list(val: Constrains[List[object]:List[str]) -> bool: also meets the criteria you list, but ... as a human reader, that signature is getting too heavy. I'll also note that I don't think TypeScript is a good model for "this won't be a problem." It is probably a good model for "this will work for the people who *want* to go whole hog on explicit typing", but for people who are at best agnostic about typing ... they would stick with JavaScript, instead of using TypeScript. Alas, this change isn't being proposed just for TypedPython; it is being proposed for baseline python. -jJ ___ 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/DXVRLPGFUYQ2CDNMQSS66M7RITSGIB3R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 647 (type guards) -- final call for comments
Another advantage of annotating the variable is that it moves some stuff out the signature line. def is_str_list(val: List[object]) -> TypeGuard[List[str]]: is probably OK on length, but if there were even a second typed and defaulted parameter, it would start to get unwieldy. And if the answer is "there won't be, these are simple functions", then that sort of screams that these are a special kind of function that should be decorated to alert readers to the restriction. def is_str_list(val: List[object]) -> bool: val: NarrowsTo[List[str]] is still near the top (like a docstring), and doesn't require a change in how to interpret existing syntax. Someone who doesn't care about typing can wonder why you bothered to quote/assert val, just as they can wonder why you did that to a docstring, but it will be (almost) as obvious that the line doesn't *do* anything -- so at least they won't assume it is doing something else (such as returning some custom type that you happen to call TypeGuard). -jJ ___ 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/IZULNMCU6SHAFDO4BFGWEDE3ZNUHWPFZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597: Add optional EncodingWarning
In the documentation (not sure whether it should be the documentation for "open" or for encoding), include at least a link to instructions on how to (try to) verify that your codebase is using the encoding parameter properly. Those instructions would say something like "Add the following lines to end of Lib\site.py: _origopen=open def open(...): if ... warnings.warn(...) _origopen(...) " -jJ On Fri, Feb 12, 2021 at 6:28 PM Inada Naoki wrote: > > On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett wrote: > > > > Offering encoding="locale" (or open.locale or ... ) instead of a long > > function call using False (locale.getpreferredencoding(False)) seems like a > > win for Explicit is Better Than Implicit. It would then be possible to say > > "yeah, locale really is what I meant". > > > > Err... unless the charset determination is so tricky that it ends up just > > adding another not-quite-right near-but-not-exact-synonym. > > > > Adding a new Warning subclass, and maybe a new warning type, and maybe a > > new environment variable, and maybe a new launch flag ... these all seem to > > risk just making things more complicated without sufficient gain. > > > > Would a recipe for site-packages be sufficient, or does this need to run > > too early in the bootstrapping process? > > > > -jJ > > What does "a recipe for site-packages" mean? > > -- > Inada Naoki ___ 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/MSK5HN4IGUMBRF4PM7IZYMI7OJGD4KJC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 647 (type guards) -- final call for comments
Current PEP 647 draft says: "Some built-in type guards provide narrowing for both positive and negative tests (in both the if and else clauses)" Should there be a separate (sub-?) type for those TypeGuards that *do* allow narrowing even on a False? Leaving it as an implementation detail available only to (some) built-in types seems to confuse the issue in both directions. -jJ ___ 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/PRRQQLGEO3IKERM6QDGYBMGCYKTM2GAG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597: Add optional EncodingWarning
Offering encoding="locale" (or open.locale or ... ) instead of a long function call using False (locale.getpreferredencoding(False)) seems like a win for Explicit is Better Than Implicit. It would then be possible to say "yeah, locale really is what I meant". Err... unless the charset determination is so tricky that it ends up just adding another not-quite-right near-but-not-exact-synonym. Adding a new Warning subclass, and maybe a new warning type, and maybe a new environment variable, and maybe a new launch flag ... these all seem to risk just making things more complicated without sufficient gain. Would a recipe for site-packages be sufficient, or does this need to run too early in the bootstrapping process? -jJ ___ 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/VUVVGVCBLVR55ELDLX44SFLBK7ED7WGG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597: Add optional EncodingWarning
On Thu, Feb 11, 2021 at 7:35 PM Inada Naoki wrote: > The PEP helps developers living on UTF-8 locale to find missing > `encoding="utf-8"` bug. > This type of bug is very common, and many Windows users are suffered > by the bug when reading JSON, YAML, TOML, Markdown, or any other UTF-8 > files. I think this is where we have been talking past each other. You seem to be assuming that the programmer knows the correct encoding, presumably because they (or their program) wrote it. You then assume that they neglected to mention the encoding out of forgetfulness, perhaps because on their system, everything is always UTF-8. This clearly does happen, but the people who would make this mistake most often -- they probably wouldn't think to test their code under a special mode that catches only this. (They might run a linter that looked for all sorts of problems, including this.) I instead assume that the programmer really doesn't know the encoding, because the file is supplied by the user. (The user may not know either, since it is really supplied by some other program, but ... neither python nor the programmer knows for sure.) In this case, the warning is not just a false alarm, but is actively misleading. -jJ ___ 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/LHMFNFIOATO46NVOVCUOKFQCRWCZLY7M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597: Add optional EncodingWarning
(I apologize if my summaries distort what Inada Naoki explained.) He said that some people use the default None when they really want either UTF-8 or ASCII. My concern is that the warning will be a false alarm if they really do need whatever locale returns, and that case may still be common. (If web browsers had stopped bothering to sniff for other charsets, then maybe that situation really was getting rare.) I asked when encoding=None is actually different from encoding=locale, currently spelled encoding=locale.getpreferredencoding(False) They can be different on Windows console, presumably because the environment settings that control locale may differ from the charset actually used by the console. Even then, it only differs for open() when PYTHONLEGACYWINDOWSSTDIO is set, and for TextIOWrapper() When the file is not _WindowsConsoleIO To me, that sounds narrow enough to be a windows issue, rather than an issue with open. Is there some way to write an encoding that sniffs for charsets, particularly on windows, and to use that as the default instead of assuming that locale will be correct? -jJ ___ 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/SSALFO3RTPX7QZ7B2MOWTZKYCJ5XKWK4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597: Add optional EncodingWarning
Who will benefit from this new warning?
Is this basically just changing builtins.open by adding:
if encoding is None and sys.flags.encoding_warning: # and not Android and
not -X utf8 ?
warnings.warn(EncodingWarning("Are you sure you want locale instead of
utf-8?"))
Even for the few people with the knowledge, time, interest, and authority to
fix the code, is that really helpful?
Helpful enough to put it directly in python as an optional mode, separate from
the dev mode or show all warnings mode? Why not just add it to a linter, or
write a 2to3 style checker? Or at least emit or not based on a warnings filter?
-jJ
___
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/GXZFCYFK7VOUSVZ5BVDCUW3JNJG6KPRS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597: Add optional EncodingWarning
Inada Naoki wrote: > Default encoding is used for: > a. Really need to use locale specific encoding > b. UTF-8 (bug. not work on Windows) > c. ASCII (not a bug, but slow on Windows) > I assume most usages are (b) and (c). This PEP can reduce them soon. Is this just an assumption, based on those times being visible to someone who installs a lot of packages, or has the use of any locale other than UTF-8 and ASCII really gone down a lot? Have browsers stopped using charset sniffing? > Additionally, encoding="locale" will be backward/forward compatible What would be the problem with changing the default from None to locale? (I think you mentioned that they are the same 99% of the time; is that other 1% likely to be cases where locale is wrong but None is right? Would there be a better way to represent that 1%?) -jJ ___ 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/NGAF753ALAPMUKNJWFBYLDOTYTUJH6ZG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 647 (type guards) -- final call for comments
If a TypeGuard returns false, does that mean "it doesn't match", or just "I can't prove it matches, but it still might"? That seems relevant to the else clause ... and seems to have changed since the last version I looked at. -jJ ___ 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/KCJ2IIF4BUXGQEBLBPFNKPXZCGUHVIPD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 647 (type guards) -- final call for comments
(1) Is it really a TypeGuard, or more of a TypeAssertion?
(2) Does this push too hard on "annotations only have one meaning"? If it has
to imported from typing, then probably not, but I think that is worth adding to
the PEP.
(3) Why can't the falsey case of an Optional String narrow to a set of
literals {"", None} Are you worried that a subclass of str might have its own
empty string, or just that you don't want to promise this? As written, it
sounds like such a narrowing is forbidden.
-jJ
___
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/XRE57ARQFY7IR7GGZH5EKQZMYD3NM3OY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 597: Add optional EncodingWarning
I just reread PEP 597, then re-reread the Rationale. The PEP helps when the locale is ASCII or C, but that isn't enforced in actual files. I am confident that this is a frequent problem for packages downloaded from mostly-English sites, including many software repositories. It does not seem to be a win when the locale is something incompatible with utf-8, such as Latin-1, or whatever is still common in Japan. The surrogate-escape mechanism allows a proper round-trip, but python itself will stop processing the characters correctly. For interactive use, when talking to another program (such as a terminal) instead of an already existing file, the backwards compatibility problem seems worse. Changing the default to utf-8 (after a deprecation period showing how to make locale an explicit default) may be reasonable, but claiming that it is backwards compatible ... I didn't get that impression from the PEP. -jJ ___ 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/RA5SLRB4M7IDLVZKQ3NWVACBLHII2BTR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?
The last time I noticed this question (probably around python 2.4?), it was considered a deliberate decision. There are languages with more open classes, such as (IIRC) Ruby and Smalltalk, but Python chose to remain somewhat closed, because monkey-patching is undesirable, and can be a problem for security audits. Whether it would really open additional attack vectors or crash possibilities ... wasn't judged worth the time to analyze or the risk of being wrong. Maybe those tradeoffs have changed, but if you don't get any other answers, that (and the bias for status quo) is the likely explanation. -jJ ___ 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/H3TLXXUEFZMKD4A7RBGUSILSQ6TSMCOI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules
I see a bunch of similar -- but not quite the same -- use cases. I feel like instead of a set, it should be a dict pointing to an object with attributes that describe the module in various ways (top-level vs subpackage, installed on this machine or not, test module or not, etc). I'll understand if this seems like scope creep, but try not to rule it out as a future enhancement. (e.g., don't promise it will be precisely a set., as opposed to the keys of a map.) ___ 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/VZ5NSCXXHRE63477ANQXJHD3U2YDFU3J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules
I probably wouldn't think of that on my own, but the need is rare enough that having the recipe in the documentation (preferably including the docstring) might be enough. (Or it might not.) ___ 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/BFSS7QXGT3PA6TKSC55JLLUFO5AXUTOC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
Paul Sokolovsky wrote: > Ok, let's take "module attribute" as an example. Why do you think > there's anything wrong with this code: > == > import config > from .types import * > if config.SUPPORT_BIGINT: > var: bigint = 1 > else: > var: int64 = 1 "Wrong" is too strong, but it would be better as mybigint = bigint if config.SUPPORT_BIGINT else int64 ... var:mybigint = 1 so asking people to rewrite it that way over the course of a major release is probably an acceptable price. -jJ ___ 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/FGZ4YK63MIZ6XVLQ4OMVJU7HUJPG73CD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
Larry Hastings wrote: > The control-flow exclusion is for /module//attribute/ or /class > attribute/ annotations: > class C: > if random.random() > 0.5: > my_attr:int=3 > else: > my_attr2:float=3.5 That very example would be helpful in the FAQ, though I understand if you're concerned about making a minor sub-section seem too long. If I understand correctly, the problem is that you can't store multiple alternative annotations on my_attr. Therefore: class C: my_attr:(int if random.random > 0.5 else float) should be OK, because there is only a single annotation. What about optional attributes, like: class C: if random.random() > 0.5: my_attr:int=3 Also, would (conditionally defined) function variable attributes become a problem if they were actually stored? (Take Larry's class example, and make if a def instead of a class statement.) My (weakly held, personal) opinion is that these restrictions would be reasonable, and a single release of deprecation would be enough, but it would be better if that code could trigger a deprecation warning during that release, even for code that hasn't done the future import. It would also be OK to just say "implementation-defined behavior; CPython 3.x ignores the annotation" instead of banning them. -jJ ___ 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/TRX23XWZ3NGROVQRC6DXLIU7NPPNEZRB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
Could you be more explicit about what is banned by the control-flow exclusion? I'm assuming that: class A: bar=float if FOO: bar=int def a(x:int, y:int)->int # function defined with annotations inside control flow return x+y def b(x:bar) # function annotated with value that depends on control flow is OK, and you're just talking about direct access to (the unfinished class or module).__annotations__ but I'm not certain. -jJ ___ 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/VMPMQWCGWR7LRFCEK57VJTQVV6TCQOQN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Pattern Matching Scope
[Steven D'Aprano st...@pearwood.info responding to Paul Sokolovsky] wrote: > > Let us be clear: failed matches do not affect > > surrounding > > namespaces unless you declare capture variables as global or > > nonglobal. They might affect the current namespace, but not > > surrounding namespaces. Failed matches will not leak out to > > surrounding namespaces. > > The problem is that intuitively (just like with "for"), > "case a, b if a != b:" opens a new namespace for "a" and "b". That's why > I talk about "surrounding namespace". Then if a particular case > matching succeeds, weak of us (myself including) expect "a" and "b" > to magically appear outside the "case" too. But if the case didn't > match, nope, I don't expect "a" and "b" to appear there, it's not > intuitive at all ;-). I'm getting a bit confused over when people mean "the PEP currently says" vs "the implementation probably should" vs "the PEP should additionally require" vs "the PEP should instead say". To be more specific, I'm not sure what is intended for the 2nd or 3rd case below, which reuse a variable "bound" by the first (failed) match. Nor am I sure whether it matters that the first match fails on the guard predicate, instead of immediately on the match. case (a, b, c) if f(): # assume f() returns false case (a, b) if a == c: # is a still bound from case above? Is that implementation-dependent? case (d = a): # is a still bound from case above? Is that implementation-dependent? Is it even still possible to put restrictions in before the guard clause, like d=4? My previous belief was that this was implementation defined, because the cases could be processed in parallel, so that the first case might not have finished by the time variable a was needed in the later cases. My reading of PEP 634 suggests that there is a linearization, but only of the guards, so ... now I am not sure. -jJ ___ 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/F5KRIPR4HUDG6TIUWLYBD6CBUFKPLYVF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The semantics of pattern matching for Python
I think your changed constructor:
class Car:
def __init__(self, manufacturer, variant):
self.brand = manufacturer
self.model = variant
is a particularly good example, and the PEP should specify whether:
Car("Chrysler", "PT Cruiser")
is matched by:
Car(brand="Chrysler", mod:=model)
or:
Car(manufacturer="Chrysler", mod:=variant)
or both, or possibly even Frankenstein combinations like:
Car(brand="Chrysler", mod:=variant)
-jJ
___
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/HBHBYOG56E75ET732WM7ZBDRTWGBVA25/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Questions about about the DLS 2020
I suppose that does follow from treating _ specially by not binding to it at all; I just hadn't thought through it. (I think my mental model had it wiping out the previous binding even if the "new" one wasn't available.) So I would prefer that this be stated explicitly in the PEP. (And maybe it is by now; the last draft I read was a few versions ago.) -jJ ___ 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/JDBIZCC4TONZWJPVO2HXXITBNPWFR7EQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Matching syntax and semantics
I don't love the way it moves the variable name away from the capture location, but it does offer a decent solution for anonymous placeholder variables (other than _ or __), and makes it clear which variables are being bound (only those in front of an = sign) vs limiting potential matches (anything after the = sign) -jJ ___ 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/MXVOGT7GSFBRY22OX7RV55ECWPV7FO2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Questions about about the DLS 2020
Not being able to use a particular variable name (such as match or case) in the limited context of matching is only a minor wart. Unfortunately, _ for internationalization is already a well-established convention for something that you might well want to do within each separate case. It isn't just that you can't call your variable match; it is that you can't do output without renaming what seems like a standard library function. Not insurmountable, but also not trivial. ___ 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/PVETCKEWNZI5LCI7BSXKRIHYD77734MJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
Nick Coghlan doesn't want to ever be having conversations about why "case True:" doesn't behave the same way as "case some.attr.referring.to.true:". Guido thinks that it strange enough that you won't see it. I agree that it is odd to define a complicated alias for True, but it isn't so odd to have a config variable that is boolean, or even one that is essentially always defined to the same value. I'm not sure this is worth bending over backwards for, but it does exist. -jJ ___ 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/YJUNHA72NIOYNVTSLNAMSCEEWHGAXB37/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
case mylib.STATUS_OK, >result: case mylib.STATUS_OK, >>result: case mylib.STATUS_OK, ->result: The second problem with those is that ">" has a very strong tie to "greater than". I think -> or even >> *might* be enough to overcome that, but I'm not comfortable. (The first problem, of course, is that the PEP authors are still reluctant to require any sigil at all, for what they assume will quickly become the default case.) -jJ ___ 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/KK7ECGM2SMV3ZUV2QGHY65IRTSZS76TH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
Matching *should* look like instantiation ... case Point(2, 4) *should* mean "Does it match the object that Point(2, 4) would create?". case Point(2, y=4) is less crucial, because they *could* rewrite the call -- but why should they have to? Changing from constants, and case Point(x=a, y=b) suddenly means x is the already externally bound name and *a* is being assigned to, so it doesn't need to have been defined previously? What advantage can there be in re-using syntax to mean something opposite to what it normally does? Others have objected to both case Point(x as a) and case Point(a:=x) # I dislike it, but it isn't as bad as the raw = but I am missing the problem, other than the confusion binding always brings. To me, they do both seem to say "It matches the object that would be created by Point(x) for *some* x, and an example/witness x that works is now stored in a. If there is no way to resolve this, I would honestly prefer to require nested matching, vs using call signatures in a way opposite to their normal usage. -jJ ___ 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/ETWGXN3QMKFK6E2LNSAVMZATT625QJ74/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
I *hope* this was a typo! If case Point(x=a, y=b): assigns to a and b (instead of x and y, as in a normal call), then that is ... going to be very easy for me to forget, and to miss even when I'm aware of it. -jJ ___ 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/F66J72JUEAUKBM5VDSMG4HRHUEQBWI5M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
Emily Bowman wrote: > If you can update to a breaking Python version, but aren't allowed one > single point version of an external module, you have a process problem. Agreed. Does it surprise you to know that many large organizations have a process problem? ___ 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/MBQJQTENT5HIPUJRWZEBLB5AZ4VBR7AZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization
Raihan Rasheed Apurbo wrote: > In CPython we have reference counting. My question is can we optimize current > RC using > strategies like Deferred RC and Coalescing? You might also look at some of the older attempts to remove reference counting entirely in favor of (usually) the Boehm tracing collector. The "problem" is that adding 1 to an integer that is already in cache is pretty quick. The same goes for subtracting 1. So to beat the current system, you need something very fast *and* you need to take out some cost that isn't directly part of reference counting. If you're assuming multiple threads (or processes) on different cores, that is possible. You know about the Gilectomy by now. I suspect that splitting the reference count away from the object itself could also be profitable, as it means the cache won't have to be dirtied (and flushed) on read access, and can keep Copy-On-Write from duplicating pages. On the other hand, it also means that you'll (eventually, after your optimization strategies) have to issue extra loads for the reference count, instead of getting it into cache for free when you load the data. > If no then where would I face problems if I try to implement these sorts of > strategies? The current system is really very fast, particularly in a single-threaded environment. You probably won't see enough gains to make up for the complexity unless you do also reorganize memory. That isn't easy to do in incremental steps, or in a backwards-compatible way. But looking at how PyPy organizes its memory models may provide a rough map of something that works. (Or warn you of what doesn't work, if they say "can't use this model when using extension modules.") > These strategies all depend on the concept that we don't need the exact value > of > reference count all the time. So far in my observation, we only need exact > value before > running a cycle collector. We also need to be sure the estimate is never too low, or at least that it never goes negative, and that it never hits 0 when it shouldn't. Being too high is fine, but it may lead to using a surprisingly large amount of extra memory, and breaking out of cache more often. ___ 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/CRRUXXHEULAH4YXMYOJNZEPU5U6LUUSH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 and variadic positional-only args
Oscar Benjamin's study of sympy is part of what prompted this, and does provide a concrete example of why constructors should be echoed. I think in general, the matching has fallen into two categories: (1) Simple literal-like matching, that mostly works OK. There is still some concern over what is a bind variable vs a match constraint, but it mostly works. And everyone agrees that it isn't the important or interesting part of the proposal. (2) Object destructuring matches, that ... are not as close to resolution. It occurs to me that object creation is also a function call (albeit with an implicit self), so this may be a good place to build on Bound Signatures. (Think inspect.Parameter, but also containing the value.) I hope (and think) that the result for sympy would be about what Oscar asked for (below), so I'll fill in with the more generic Point-based example. class Point: def __init__ Point(self, x, y, z=0, *, color=Color.BLACK): ... case Point(23, y=y, oldcolor=color): # z doesn't matter I have weak opinions on whether to require y=y to (or y= or :=y or ...) to capture one of the variables when it isn't being renamed. Oscar Benjamin wrote: > I've taken a look through PEP 622 and I've been thinking about how > it could be used with sympy. > ... The key feature of Basic instances is that they have an .args > attribute which can be used to rebuild the object ... > All Basic classes are strictly constructed using positional only > arguments and not keyword arguments. In the PEP it seems that > we can handle positional arguments when their number is fixed > by the type. ... The main problem though is with variadic positional > arguments. ... > From a first glimpse of the proposal I thought I could do matches like this: > match obj: > case Add(Mul(x, y), Mul(z, t)) if y == t: > case Add(terms): > case Mul(coeff, factors): > case And(Or(A, B), Or(C, D)) if B == D: > case Union(Interval(x1, y1), Interval(x2, y2)) if y1 == x2: > case Union(Interval(x, y), FiniteSet(p)) | Union(FiniteSet(p), > Interval(x, y)): > case Union(*sets): > Knowing the sympy codebase each of those patterns would look quite > natural because they resemble the constructors for the corresponding > objects (as intended in the PEP). It seems instead that many of these > constructors would need to have args= so it becomes: > match obj: > case Add(args=(Mul(args=(x, y)), Mul(args=(z, t if y == t: > case Add(args=terms): > case Mul(args=(coeff, *factors)): > case And(args=(Or(args=(A, B)), Or(args=(C, D if C == D: > case Union(args=(Interval(x1, y1), Interval(x2, y2))) if y1 == x2: > case Union(args=(Interval(x, y), FiniteSet(args=p))) | > Union(args=(FiniteSet(args=p), Interval(x, y))): > case Union(args=sets): > Each of these looks less natural as they don't match the constructors > and the syntax gets messier with nesting. ___ 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/T2C2KI5DSXJ63MC2XMTXXC6E65VZ5FZK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
ah... we may have been talking past each other. Steve Dower wrote: > On 25Jul2020 2014, Jim J. Jewett wrote: > > But it sounds as though you are saying the benefit [of storing the line numbers in an external table, I thought, but perhaps Pablo Galindo Salgado and yourself were talking only of the switch from an lnotab string to an opaque co_linetable?] > > is irrelevant; it is just inherently too expensive to ask programs that are > > already dealing > > with internals and trying to optimize performance to make a mechanical > > change from: > > code.magic_attrname > > to: > > magicdict[code] > > What have I missed? > You've missed that debugging and profiling tools that operate purely on > native memory can't execute Python code, so the "magic" has to be easily > representable in C such that it can be copied into whichever language is > being used (whether it's C, C++, C#, Rust, or something else). Unless you really were talking only of the switch to co_linetable, I'm still missing the problem. To me, it still looks like a call to: PyAPI_FUNC(PyObject *) PyObject_GetAttrString(PyObject *, const char *); with the code object being stepped through and "co_lnotab" would be replaced by: PyAPI_FUNC(PyObject *) PyDict_GetItem(PyObject *mp, PyObject *key); using that same code object as the key, but getting the dict from some well-known (yet-to-be-defined) location, such as sys.code_to_lnotab. Mark Shannon and Carl Shapiro had seemed to object to the PEP because the new structure would make the code object longer, and making it smaller by a string does seem likely to be good. But if your real objections are to just to replacing the lnotab format with something that needs to be executed, then I apologize for misunderstanding. -jJ ___ 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/WUEFHFTPVTOPA3EFHACDECT3ZPLGGTFJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
I certainly understand saying "this change isn't important enough to justify a change." But it sounds as though you are saying the benefit is irrelevant; it is just inherently too expensive to ask programs that are already dealing with internals and trying to optimize performance to make a mechanical change from: code.magic_attrname to: magicdict[code] What have I missed? ___ 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/TDCJFNHIAFEH5NIBEPP2GFP4C2BYR2DP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
I think this example should be in the PEP. ___ 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/Z6TNMC7HKRQHQMEDHXKM2PAAKE233KUO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.
In theory, this table could be stored somewhere other than the code object, so that it doesn't actually get paged in or occupy cache unless tracing is on. Whether that saves enough to be worth the extra indirections when tracing is on, I have no intention of volunteering to measure. I will note that in the past, taking out docstrings (not even just moving them to a dict of [code:docstring] -- just taking them out completely) has been considered worthwhile. ___ 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/HEXSSC35MFWFKFRK6TO4N5SBJDTZAZOS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching (version 2)
Mark Shannon wrote: > In future, could you avoid editing emails when replying to them? > A lot of context can get lost. I'll add another voice to Ethan's saying that I appreciate having as much as possible trimmed. As long as people are arguing in good faith (and I assume that they are here), the loss of context is usually pretty small, and outweighed by being able to find the newly important part more quickly. (I say this as someone reading and replying through the archives, in a way that seems to mangle quoted portions -- but they are usually still good enough to be useful.) > ... Yes, the pattern matching syntax is more concise in some > circumstances, but there still needs to be justification why a > combination of simpler language changes is insufficient. Code that fits on a single small (24x80) screen (without getting too dense) is much easier to understand, because I can see it all at once, instead of needing to remember things while I flip back and forth. A combination of simpler changes might be fine, but shorter really is very valuable, all by itself. > Saves two lines of code, but introduces two bugs! > (Assuming that the original behavior should be preserved) That is a pretty big assumption. I'm guessing that at least one of the "bugs" is that sequences other than the built-in list and tuple are now also accepted. Maybe there are good reasons to exclude other sequences, but ... in my experience, the reason is usually that someone didn't think of it, and no one felt strongly enough to fix it yet. That would mean pattern matching led to a bug *fix*. Closed source code tends to be even more fragile, though it also tends to not see as many surprising input types in the first place. > If you don't have access to the original source, then it can be made a > function, not a method. Even when I have read access, I may not have write access. Creating and naming a separate match function every place I need to match isn't quite boilerplate, but it adds enough code to feel that way. Trying to use a single match function with parameters gets ugly in a different way. I'm not quite convinced that this PEP has found the magic solution, but the goal is clearly worthy. > On 14/07/2020 5:25 pm, Tobias Kohn wrote: > > match response.status: > > case HTTP_RESPONSE.UPGRADE_REQUIRED: > Are you suggesting that all constants live in a separate module? The limit to dotted names is a possibly temporary wart. But even with that restriction, there is no reason you can't gather constants on an object first, and use its attributes. > For a PEP to succeed it needs to show ... > That the proposed change is the best known solution for the > problem being addressed. I think the bigger barrier is "although never is often better than right now," and hope that a better solution will be found later, and fear that backwards compatibility with this would block that better solution. (To be very explicit, I personally abstain on this, because I am not sure whether this is "good enough", nor am I confident a better solution can ever be found.) > I worry that the PEP is treating pattern matching as an ideal which we > should be striving towards. That is a bad thing, IMO. Fair. Like annotations as a typing system, you can personally ignore it if it isn't helpful, but there is still some ecosystem cost. I would like to see more old/new comparisons to judge how intrusive this will be, but eventually there will be (or not be) a leap of faith. In the past, most of those have worked out. > Pattern matching is well suited to statically typed functional languages. and statically typed data domains and communications protocols -jJ ___ 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/4S75QY4FVVXW7YGTSFRHEXBK5OXXJM6Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
Larry Hastings wrote: > As for leveraging the convention of using '_' for values you don't care > about in Python--that's actually why I /don't/ like it as the wildcard > pattern. To date, everyone who uses '_' understands it's just an > identifier, no different from any other identifier. Not quite... I understand it more like a file in /tmp I don't use it for anything I will want later, just in case. > However, if I understand PEP 622 correctly, the places you use '_' as > the wildcard pattern are also places where you could put an identifier. > But in this one context, '_' doesn't behave like the other identifiers, > even though in every other context in Python it still does. This is the > "special case" that "breaks the rules" I alluded to above. > Consistency with the longstanding semantics of '_', and consistency with > other identifiers, is much more important to me than consistency with > other languages for the pattern matching wildcard token. If a normal variable name is re-used, I would expect it to have the same meaning. I know that "case x, x:" as shorthand for "case x, __x if x == __x:" has been postponed, but it could still happen later, and it would be a problem if that ever became legal without requiring the two bindings to match. I do NOT assume that they will match if the variable happens to be _, though I suppose others might. -jJ ___ 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/E3BMB3BWC7NXKAQKY33EVLTPWCIU7RAS/ Code of Conduct: http://python.org/psf/codeofconduct/
