[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant
On 29/11/22 12:51 pm, Guido van Rossum wrote: "Sets weren't meant to be deterministic" sounds like a remnant of the old philosophy, where we said the same about dicts -- until they became deterministic without slowing down, and then everybody loved it. I got the impression that there were some internal language reasons to want stable dicts, e.g. so that the class dict passed to __prepare__ preserves the order in which names are assigned in the class body. Are there any such use cases for stable sets? -- Greg ___ 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/3TEOQMV2UXOKWMHVYA63JLPLAZ2TNX55/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How about using modern C++ in development of CPython ?
On 17/10/22 10:13 pm, Denis Kotov wrote: For example, PyObject is much better to implement using C++ class, I used to think this. Python has OO features, C++ has OO features, should be a good match, right? Well, no. Python's OO is very flexible and dynamic, C++'s is very rigid and static. CPython uses various low-level tricks that rely on structs being just "plain old data". The OO features of C++ wouldn't help nuch with that at all, and would often get in the way. If you want a Python implementation that's less prone to memory management errors, I would suggest having a small kernel written in C, and write the rest using a tool similar to Cython that will take care of all the tricky reference counting for you. -- Greg ___ 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/7SHARSLCRFH4XOJAQOOBG4O5XVQE2CH7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 689 – Semi-stable C API tier
On 30/04/22 5:25 am, MRAB wrote: I was going to suggest "metastable". Too late? :-) What, the API is balanced on a knife edge and likely to collapse into something else if you sneeze too hard? -- Greg ___ 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/CUWORBXDLOK74M7H6HZSXSMC5ZKMCFFY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 27/04/22 1:26 pm, Chris Angelico wrote: On Wed, 27 Apr 2022 at 11:18, Greg Ewing wrote: The proposed feature is analogous to forward declaring a struct in C. Would you call what C does monkeypatching? No, because C doesn't have first-class types, much less mutable ones. The purpose of a forward declaration, in any language, is to allow a name to be used before it's fully defined. Mutability or first-classness of types has nothing to do with it. According to this proposal, it is entirely possible to continue a class more than once, with just some fiddling with dunders. No, it's not. As has been explained upthread, stuff is done when finalising a class that can't be repeated. But what you're saying is that sometimes that's monkeypatching and a bad thing, and other times it's a good thing and not monkeypatching. No, I'm saying that the proposed feature is not monkeypatching because it does not and cannot be used to modify an existing class. -- Greg ___ 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/SVZPAEBDIGHR2TADKCOXND4S3RPKXAMY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 27/04/22 11:07 am, Chris Angelico wrote: You're saying that it's somehow different when the original dev intends for it, and that that makes it "not monkeypatching". I dispute that, and I consider that the feature would be helpful whether the original dev meant for it or not. The forward declaration and continuation both have to be specially marked, so you *can't* use it for monkeypatching. Would subclassing therefore become legitimate if the original author intended for it, and be called "method stealing" if it were not? You seem to think I have something against monkeypatching. Personally I don't, but someone else seems to as they objected that they don't want monkeypatching to be encouraged. I was just pointing out that (1) I don't think it's the same thing as monkeypatching and (2) you can't use it to modify an existing class in an ad-hoc manner anyway. -- Greg ___ 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/6HOFAR3TKR62YFPUZ4OIBY5DJBNV374V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 27/04/22 2:01 am, Chris Angelico wrote: That would be the case if monkeypatching were illegal. Since it's not, wherein lies the difference? The proposed feature is analogous to forward declaring a struct in C. Would you call what C does monkeypatching? -- Greg ___ 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/5DRJG3CGCLHJSXBD6ILPHROX6LBIDCHK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 27/04/22 1:04 am, Joao S. O. Bueno wrote: MonkeyPatching in Python is not illegal in this sense. I'm not suggesting it is. You're seizing on the wrong part of the analogy. The point is that what you call something doesn't change its nature. -- Greg ___ 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/WFVAWIKBQF72KW2IHOERP2DIKD5ECO7N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 26/04/22 12:33 pm, Chris Angelico wrote: That's exactly what I mean though: if the only difference between "monkeypatching" and "not monkeypatching" is whether it was intended, then the only difference is what you call it. No, it's not just a matter of what you call it. If I lose my keys and have to break into my house, it's not illegal. But if someone else breaks into my house without my permission, that is illegal. It doesn't matter if the thief *calls* it legal, there's still a difference. -- Greg ___ 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/HE7Z6VDDYN7RE3YIIWUKZDYBBCQCPWEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 23/04/22 6:41 pm, Mehdi2277 wrote: If it's allowed that a forward class may be continued in a different module I do not see how type checker like mypy/pyright could handle that. Classes are generally viewed as closed and fully defined within type checker. The way this kind of thing works in a statically typed language is that the "forward" part of the definition contains all of the interface information, so the type checker doesn't need to see the "continue" part -- that only contains implementation. What's being proposed here is to split the *interface* between two class statements, and possibly different modules. That's very different. The nearest thing I can think of in a statically typed language is the "extension methods" of C#. The way it works there is if you want to use any extension methods, you have to import both the module defining the class and the module defining the extension methods. Maybe here the client code should import the class from the module containing the "continue class", and that module should import the one containing the "forward class"? Would that still work to resolve circularities? -- Greg ___ 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/BOO3TJ5V3LOXC2MMNFBUWIEGCNMZLKET/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 23/04/22 5:44 pm, Chris Angelico wrote: On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote: Still, it's not the intent of my PEP to condone or facilitate monkeypatching. The only difference is that you call it something different. To me, monkeypatching means modifying the definition of something after the fact in a way that it wasn't designed for. Here, the modification is fully intended, so it's not monkeypatching. Also, as long as you can only 'continue' a class that was previously declared 'forward', and only do it once, and can't use a forward class until it has been continued, it doesn't make monkeypatching any easier than it currently is. -- Greg ___ 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/V6VXIX4SWIRMN5GJRCN35M3OMKXQDWEF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 23/04/22 10:10 pm, Terry Reedy wrote: 'forward class' for an incomplete class is not at all clear to me. It is not clear to me which part of speech you intend it to be: noun, verb, adjective, or adverb. You must have some experience with 'forward' in a different context that makes it clearer to you. Pascal has a "forward" keyword[1] for declaring functions, and the term is often used for the same concept in other languages even if it's spelled differently. So I think it would be fine here, although "def" would also work if you want to reuse an existing keyword. [1] Actually it's a context-sensitive pseudo-keyword, which is an unusual thing to find in Pascal; maybe Wirth added it as an afterthought? -- Greg ___ 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/6M4MEEMNAFM6H2ST75XVNNUUSO5MY7MY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On 23/04/22 7:22 pm, Steven D'Aprano wrote: He said that could be used as a very primitive form of separation of interface and implementation, by putting the `forward class` in one module and the `continue` in another. But that only works if there is some way to define the interface of the class's public attributes in the "forward" part without also supplying their definitions. If I remember rightly the "forward" part was only going to include the class name and base classes. -- Greg ___ 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/SIK3RXO4ESGQLF5KOB6OEROH2MWTWBS6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: About PEPs being discussed on Discourse
On 8/04/22 12:13 pm, Gregory P. Smith wrote: And for lurkers and subscribers here to enable email notifications for categories of interest over there. Is it possible to participate in a Discourse discussion entirely by email, without having to visit the web site? If not, then if python-dev becomes discourse-only, I will no longer be able to follow or participate in it. I don't have the time or energy to chase around visiting a bunch of clunky web interfaces every day. -- Greg ___ 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/ANKS4G2QXS5FJ2UZJ52RZWVFXHT76QG7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Descriptions in unittest and avoiding confusion
On 5/04/22 4:27 am, Coyot Linden (Glenn Glazer) wrote: On 4/4/22 09:25, Paul Moore wrote: I'm confused, what's wrong with """..."""? Triple quoted strings are not exclusively for docstrings... Paul That isn't my reading of PEP 257, I would be happy to be wrong about this. PEP 257 recommends that all docstrings be triple quoted, not that all triple quoted strings be docstrings. There is a difference! -- Greg ___ 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/KZ2RJE7REYOYPVLOTACILLTYRJXIBPKP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
On 2/02/22 12:32 pm, Christopher Barker wrote: I can make a "thick" high performance wrapper, e.g. if I want to call an expensive C function on each item in a sequence, I can do that in Cython, removing a lot of the overhead of Python. "Not as fast as possible" doesn't necessarily mean *slow*. Even using the stable ABI, the code you get will still be a lot more efficient than a Python wrapper. Sure, but this thread is not just about users like me, that can choose the more stable way or the faster way, but specifically about numpy, which is going to use the fast way -- and we don't want to break that any more than absolutely necessary. I'm skeptical about how much difference it would actually make. Numpy gets its speed from tight loops in C and calling out to C and Fortran libraries. None of that is affected by which CPython API is being used. In any case, if numpy explicitly chooses speed over compatibility, that's an issue between CPython and numpy, not CPython and Cython. -- Greg ___ 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/UJOVLMM4OJVSGZAEVVTTNQJCNB4GWTYS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
On 2/02/22 11:53 am, Christopher Barker wrote: As a long time Cython user, but not a Cython developer, I think (2) is the primary purpose, with (1) as a handy side benefit (otherwise we'd just use ctypes, yes?) Personally, no, I would not "just use ctypes". The main reason I created Pyrex was to avoid the extreme amounts of pain involved in doing things like that. That being said a not-quite-as-fast-as-possible mode would be fine. Though I'm not sure it would buy much, as long as projects (including major ones like numpy) are using as-fast-as-possible mode. That's why I think compatible mode should be the default. Then those who choose otherwise will be aware of what they are doing. It would also mean that CPython developers needn't have as many qualms about changing internals. Cython users would be in the same position as someone writing an extension module by hand and choosing whether to stick to the stable API or not. If they rely on internals, they do so at their own risk. -- Greg ___ 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/WTDYDJYNS7XXMXI7LVN5GOE4CVAKUIZ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
On 2/02/22 8:48 am, Guido van Rossum wrote: It seems to me that a big part of the problem is that Cython feels entitled to use arbitrary CPython internals. I think the reason for this is that Cython is trying to be two things at once: (1) an interface between Python and C, (2) a compiler that turns Python code into fast C code. To address this there could be an option to choose between "compatible code" and "fast code", with the former restricting itself to the stable API. -- Greg ___ 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/EACB7ZZVDDNL4QAIODYDNWLKI455QDKP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
On 2/02/22 5:42 am, Victor Stinner wrote: There is an on-going effort adding getter and setter functions on two structures which are causing most troubles on Python updates: * PyThreadState: https://bugs.python.org/issue39947 * PyFrameObject: https://bugs.python.org/issue40421 In the case of PyFrameObject, as far as I know the only reason Cython needs to mess with it is to get filename/lineno information into tracebacks. If that's still true, I think it would be better to make it possible to add that information directly to traceback objects so that fake frame objects are not needed. -- Greg ___ 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/VNNASOMXNFHRJYCUZLPWRWMXVNUIKEOU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
On 1/02/22 5:47 am, Lrupert via Python-Dev wrote: This gives a bad impression to others about their intentions (constant contribution of trivial / low quality stuff with little-to-no-gain to achieve a higher number of commits, since it is a visible metric). Or they may just feel that it's better to organise their changes into a number of small, independent commits rather than one large one. I wouldn't be too quick to jump to conclusions about people's motives here. -- Greg ___ 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/4GZX7RHJKRRNAQSA45P7RNLHYB7F6Z6Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On 9/01/22 2:46 pm, Steven D'Aprano wrote: if you can read expressions: spam(eggs | cheese, aardvark) then you can read type expressions: Spam[Eggs | Cheese, Aardvark] That's like me saying that I can read Greek just because I know how to pronounce the letters. I do, but that doesn't mean I know what any of it means! Most of the effort of learning to read type expressions, in any language, is learning their semantics, which is very different from value expressions. Whether they happen to superficially resemble other parts of the language is pretty much irrelevant to me. -- Greg ___ 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/AXDVYGAUCKKWOMDDHGEMEIA6PUKDCHVT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
On 17/12/21 6:58 pm, Steven D'Aprano wrote: Or a Doctor Who episode. Doctor Who and the Immortal Instances of Doom. Hmmm... and Guido has a time machine... Is it possible he's secretly a Time Lord? -- Greg ___ 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/XVMGJRQNRCIXHAIVYNVP2HPDZVXQU7T5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
On 17/12/21 6:52 am, Eddie Elizondo via Python-Dev wrote: I've just updated the original Immortal Instances PR Is it just me, or does Immortal Instances sound like a video game franchise? -- Greg ___ 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/OCO5D53ACVM7CAOIXCPC4FPKIDGDSUXR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 674: Disallow using macros as l-value
On 8/12/21 4:36 am, Antoine Pitrou wrote: Is there a way to emit a compilation warning when those macros are used as l-values? Even if only enabled on some compilers. Maybe the macro could be written so that it expands to something with a cast around it? I think gcc has an option for warning about casts used as l-values. -- Greg ___ 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/DG6GBX6OFCK4D2G6CGQFW5QX5JXQPAZO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The current state of typing PEPs
On 26/11/21 4:15 am, Stephen J. Turnbull wrote: My understanding is that optional, incremental type hints are and have always been considered the primary use case for annotations by the BDFL I'm not sure that's true. The way I remember it, back when annotations were first introduced, the BDFL didn't say that, or at least didn't say it very clearly. It sounded more like type hints were just one of many possible uses, and he encouraged people to experiment. There were even discussions about coming up with a convention to manage conflicting uses of annotations in the same code. That wouldn't have happened if typing were considered the only supported use. -- Greg ___ 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/R5TWU6HTOKLCTY2QZDGEAR74TGHZHQQ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: containment and the empty container
On 9/11/21 7:29 pm, Ethan Furman wrote: I've had a couple people tell me that they think of flags as sets, and use set theory / set behavior to understand how flags and groups of flags should interact. If you're going to think of flags as sets, then 'i in flags' should be equivalent to '((1 << i) & flags) != 0'. -- Greg ___ 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/43SHTKMYRYSRK6P2DPG4XVZMRPOSB42E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The list.sort(reverse=True) method not consistent with description
On 31/10/21 5:47 am, Raymond Bisdorff wrote: Should the tuples comparison is in this case, I thought, not be solely based on the first tuple component? Whether you think it should or shouldn't, the fact is that it's not. This is documented in Section 5.6 of the Library Reference: "tuples and lists are compared lexicographically by comparing corresponding elements. This means that to compare equal, every element must compare equal and the two sequences must be of the same type and have the same length." -- Greg ___ 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/PJ75PNVTHPIOZ5I4HLNU67YJT2NP7FRD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: What is __int__ still useful for?
On 14/10/21 11:19 am, Greg Ewing wrote: Not really -- __int__ is expected to return something of type int, whereas __trunc__ is expected to return the same type as its operand. Scratch that, it seems __trunc__ also returns an int, at least for floats. Not sure what the logic behind that is. There are differences between the functions int() and trunc() though: >>> int("42") 42 >>> trunc("42") Traceback (most recent call last): File "", line 1, in TypeError: type str doesn't define __trunc__ method Conceptually, I would say that int() is a type conversion, whereas trunc() is an operation on numbers. A type would be entitled to implement them both but differently. -- Greg ___ 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/OM5UB5LRMOSKTVGJWV3G7TP7Z7DNFE2M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: What is __int__ still useful for?
On 14/10/21 6:10 am, Antoine Pitrou wrote: It seems that __int__ has now become a strict equivalent to __trunc__. Not really -- __int__ is expected to return something of type int, whereas __trunc__ is expected to return the same type as its operand. -- Greg ___ 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/5XD26XS2WW7H2I3KZBY5EZLNV64RX6VM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 except* formatting
On 6/10/21 7:15 am, sascha.schlemmer--- via Python-Dev wrote: except (*E1, *E2) as error: ... Then we would have to decide whether to allow except (E1, *E2) as error: ... and if so, what it would mean. -- Greg ___ 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/O7V4G4DWEOXNWZB6MP4PKOXV46XKVT67/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 except* formatting
On 4/10/21 6:23 pm, Guido van Rossum wrote: On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble <mailto:jcgob...@gmail.com>> wrote: Therefore my vote is for requiring `except* E` and keeping `except *E` as a SyntaxError. You can't do that with our current lexer+parser. I don't think it would be desirable in any case. The separation of tokens into alphanumeric and non-alphanumeric is deeply embedded in every Python programmer's brain by now, and we shouldn't mess with it. -- Greg ___ 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/XQXJEGYAWBTAUQI3BEIXDZO4SERAJYWF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Making code object APIs unstable
On 2/09/21 7:46 pm, Antoine Pitrou wrote: Tracebacks are linked in a single direction, to go the other direction you need to walk the frames attached to the traceback. So a (fake or not) frame object is still desirable, IMHO. Could we at least remove the necessity for a fake code object? -- Greg ___ 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/TDLCJHNQSPNE7UXEJ33PV2VNQOPUFUT7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Making code object APIs unstable
On 2/09/21 4:46 am, Victor Stinner wrote: If creating a fake frame is a common use case, we can maybe write a public C API for that. For example, I saw parser injecting frames to show the file name and line number of the parsed file in the traceback. The way I would like to see this addressed is to make it possible to attach a filename and line number directly to a traceback object, without needing a frame or code object at all. Creating a fake frame and code object just to do this is IMO an ugly hack that should not be necessary. -- Greg ___ 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/XWX7EXJQ3JJRAL26YFR3GSSMLGSCEH2V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Dropping out of this list
On 19/08/21 7:23 pm, Antoine Pitrou wrote: The whole thing is ridiculous enough to read like a Monty Python skit by now, but the trout-slapping ending is still missing. Just have the police come in and arrest everyone, that usually works. -- Greg ___ 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/NRVEWJUUVGYLKQDAUQ4R5PFFNRX7KR5L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)
On Wed, May 26, 2021 at 8:55 AM Ammar Askar <mailto:am...@ammaraskar.com>> wrote: most recently if your topic mentioned libera.chat, the new freenode owners will take it over, ban anyone from chatting in it and change the topic My goodness. Let's hope the new owners eventually learn that behaving like spoilt 7-year-olds is no way to run a successful company. -- Greg ___ 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/BOUNCG5BAMXND5LXDH553F6TEHJGZ4MM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: In what tense should the changelog be written?
On Fri, Apr 30, 2021 at 02:22 Steven D'Aprano <mailto:st...@pearwood.info>> wrote: Without a subject of the sentence, that's not present tense, it is the imperative mood. "Fix buffalo.spam ..." is a command or suggestion. While it could be read that way, I don't think that's the intention. I'm not sure it fits any of the usual grammatical categories. It might be best understood as an abbreviated infinitive, i.e. there's an implied "The purpose of this commit is to..." in front of it. -- Greg ___ 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/LWB7RV67BIYZILBYDPNZC7INS2RFMMM4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Boundaries between numbers and identifiers
On 14/04/21 8:54 am, Guido van Rossum wrote: On Tue, Apr 13, 2021 at 12:55 PM Serhiy Storchaka > >>> [0x1for x in (1,2)] I would totally make that a SyntaxError, and backwards compatibility be damned. Indeed. Python is not Fotran! -- Greg ___ 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/WBZ2IQFNL2ICZ6WCMURCXXHDDTWWCWIY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
On 7/04/21 5:22 am, Brandt Bucher wrote: we might consider updating those templates if the term "Reference Implementation" implies a higher standard than "we've put in the work to make this happen, and you can try it out here" Maybe "prototype implementation" would be better? I think I've used that term in PEPs before. -- Greg ___ 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/HLDVEIN5EKTE3KJOZRXZMPOOIUAE4VFB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
While we're talking about compelling use cases, does anyone have an actual, concrete use case for the proposed "except *" feature that's strong enough to justify new syntax? I'm fine with having ExceptionGroup as a built-in type. I'm not fine with adding new syntax that will apparently be used only in rare circumstances. Can code that's aware of the possibility of getting an ExceptionGroup not simply catch it as a normal exception and then pick it apart? Do we really need a whole new piece of machinery for this? -- Greg ___ 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/EIW6JGXRWKEEIY72CGZ7BMKU3LHJIZQK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
On 4/03/21 5:37 am, Paul Moore wrote: frameworks and libraries typically have to interact with other users' code, and there the contract has changed from "do what you like in your code and I'll cope" to "do what you like in your code as long as you don't let an exception group escape, and I'll cope"... And I have to change *my* code to get the old contract back. Seems to me this whole issue would go away if the ordinary except statement were to look inside ExceptionGroups. In other words, the only difference between except and except* would be that multiple except* clauses can be run, whereas only one except clause will run (the first one that matches something in the ExceptionGroup). Is there any good reason not to do things that way? -- Greg ___ 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/NDIO4533M4OQZZWT65EKPPIXZU6ZJQUY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission
While I don't particularly mind if we get ExceptionGroup, giving it special magical semantics, and especially new syntax, seems like bringing a massively overpowered weapon to bear on something that will only be used rarely. Handling multiple exceptions from an ExceptionGroup could be done using a loop with pattern matching, so is except* really justified? -- Greg ___ 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/BRQDP4KNRYU6UCKQBHRAUAHWWCENNIVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 647 (type guards) -- final call for comments
On 14/02/21 8:48 am, Eric Traut wrote: def is_str_list(val: Constrains[List[object]:List[str]) -> bool: ... Maybe something like this? def is_str_list(val: List[str] if True else List[object]) -> bool: ... -- Greg ___ 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/GLHQVM7NIYO2GZHGREJ5FE2KJ7AI3DTQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python standardization
On 13/02/21 9:03 am, Paul Bryan wrote: What if PSF were to undertake codifying a language specification? We have the Language Reference and Library Reference. Do they not count as specifications? -- Greg ___ 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/EUYJ6W3TKQNSE6EOBQL4W4F2UJDUIDL6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Concerns about PEP 634
On 7/02/21 9:58 am, Steve Holden wrote: My suggestion that it be introduced via __future__ due to its contentious nature met immediate resistance. __future__ is for things that are changing in incompatible ways. This is an entirely new feature that doesn't conflict with anything existing, so it doesn't need __future__. -- Greg ___ 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/T3CJQWO7DQEJPECHUYJH655D75LMVOVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: What's up with assignment expression and tuples?
On 5/02/21 8:51 pm, Paul Sokolovsky wrote: a = 0 while a < 5: a += 1 becomes: a0 = 0 while (a1 := phi(a0, a2)) < 5: a2 = a1 + 1 SSA seems to be something intended for compilers to use as an intermediate representation, not something to actually write code in. So I'm puzzled as to why you would want to do this. Also, what definition do you have in mind for phi? It doesn't seem to be something you can implement as a real function. -- Greg ___ 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/UBXNDF4QL7I2IWQSUTIPCNLZXGOCG23D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Understanding "is not safe" in typeobject.c
On 3/02/21 10:35 pm, Phil Thompson wrote: On 02/02/2021 23:08, Greg Ewing wrote: you have no idea what kind of C struct it expects to get. I had assumed that some other magic in typeobject.c (eg. conflicting meta-classes) would have raised an exception before getting to this stage if there was a conflict. "No idea" is probably an exaggeration -- there is checking to ensure that all the C structs involved form a sequence of extensions. But they still need to be initialised in the right order, because __new__ methods for later ones assume that the struct they're extending has already been initialised. -- Greg ___ 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/N54L3266FSMKEQPFPH3YS3XZ6GVJMGAU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Understanding "is not safe" in typeobject.c
On 3/02/21 11:05 am, Martin Teichmann wrote: class MyClass(B, Mixin): "whatever" this leads to an MRO of MyClass -> B -> Mixin -> A -> object. If you do the tp_new stuff correctly at the C level, you can still create such a class. The only limitation is that if Mixin has a __new__ method written in Python, it won't get called. So if Mixin needs to do any initialisation, it will have to be in __init__, *and* all the __init__ methods in the chain will need to be designed for cooperative calling. -- Greg ___ 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/YOMFSCDKYYFNV4IRGFAMLQU7WQYNTO6C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Understanding "is not safe" in typeobject.c
On 3/02/21 4:52 am, Phil Thompson wrote: Thanks - that's fairly definitive, although I don't really understand why __new__ has this particular requirement. The job of tp_new is to initialise the C struct. To do this, it first has to initialise the fields of the struct it inherits from, then initialise any fields of its own that it adds, in that order. Initialising the inherited fields must be done by calling the tp_new for the struct that it inherits from. You don't want to call the tp_new of some other class that might have got inserted into the MRO, because you have no idea what kind of C struct it expects to get. Cooperative calling is a nice idea, but it requires rather special conditions to make it work. All the methods must have exactly the same signature, and it mustn't matter what order they're called in. Those conditions don't apply to __new__, especially at the C level where everything is much more strict type-wise. -- Greg ___ 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/5AGXKE35LDQA6JP6EKXW7FUFR7YCC3RR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Understanding "is not safe" in typeobject.c
On 3/02/21 12:07 am, Phil Thompson wrote: On 01/02/2021 23:50, Greg Ewing wrote: At the C level, there is always a *single* inheritance hierarchy. Why? Because a C struct can only extend one other C struct. I want my C-implemented class's __new__ to support cooperative multi-inheritance I don't think this is possible. Here is what the C API docs have to say about the matter: --- Note If you are creating a co-operative tp_new (one that calls a base type’s tp_new or __new__()), you must not try to determine what method to call using method resolution order at runtime. Always statically determine what type you are going to call, and call its tp_new directly, or via type->tp_base->tp_new. If you do not do this, Python subclasses of your type that also inherit from other Python-defined classes may not work correctly. (Specifically, you may not be able to create instances of such subclasses without getting a TypeError.) --- (Source: https://docs.python.org/3.5/extending/newtypes.html) This doesn't mean that your type can't be used in multiple inheritance, just that __new__ methods in particular can't be cooperative. -- Greg ___ 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/KVUEGIRAXWPVD6BZLHPKUI5X7UBH3G2M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Understanding "is not safe" in typeobject.c
On 2/02/21 12:13 am, Phil Thompson via Python-Dev wrote: TypeError: object.__new__(B) is not safe, use B.__new__() It's not safe because object.__new__ doesn't know about any C-level initialisation that A or B need. At the C level, there is always a *single* inheritance hierarchy. The right thing is for B's tp_new to directly call A's tp_new, which calls object's tp_new. Don't worry about Python-level multiple inheritance; the interpreter won't let you create an inheritance structure that would mess this up. -- Greg ___ 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/IW3OX6Y324VSF4WLQHGA7EFHJQ6XEBH4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 19/01/21 1:13 pm, Inada Naoki wrote: I don't want to import modules used only in type hints. I don't want to import even "typing". How about having a pseudo-module called __typing__ that is ignored by the compiler: from __typing__ import ... would be compiled to a no-op, but recognised by type checkers. If you want to do run-time typing stuff, you would use from typing import ... -- Greg ___ 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/24MR5KVWP7LR3PCE7V44OTLJNXDLLNZX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally
On 17/01/21 12:31 pm, Larry Hastings wrote: Consider the best practice for getting class annotations, example here from Lib/dataclasses.py: cls_annotations = cls.__dict__.get('__annotations__', {}) Isn't that going to get broken anyway? It won't trigger the calling of __co_annotations__. -- Greg ___ 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/PPDBI3J4SUJ6NCWRORWYAOKYW4IM3HMQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 16/01/21 2:09 pm, Guido van Rossum wrote: Yeah, that wasn't very clear, and I'm not 100% sure I got it right. But consider this: ``` class Outer: foo = 1 class Inner: print(foo) That's true. So maybe the user should have to be explicit in cases like this: class Outer: class Inner: def f(x: Outer.Inner): ... However, I think cases like this should work: class C: t = List[int] def f(x: t): ... even though the closure placed in C.__co_annotations__ wouldn't normally have access to t without qualification. -- Greg ___ 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/YTZ3QRG3V6URZ3FDOZ6QON5DSYC52HGI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 16/01/21 9:38 am, Guido van Rossum wrote: On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings <mailto:la...@hastings.org>> wrote: class OuterCls: class InnerCls: def method(a:OuterCls.InnerCls=None): pass We've turned the local reference into a global reference, and we already know globals work fine. I think this is going too far. A static method defined in InnerCls does not see InnerCls (even after the class definitions are complete). E.g. ``` class Outer: class Inner: @staticmethod def foo(): return Inner ``` If you then call Outer.Inner.foo() you get "NameError: name 'Inner' is not defined". I'm not so sure about that. Conceptually, annotations are evaluated in the environment existing when the class scope is being constructed. The fact that we're moving them into a closure is an implementation detail that I don't think should be exposed. What if we want to refer to something defined /after/ the annotation? def outerfn(): class OuterCls: class InnerCls: def method(a:zebra=None): pass ... We haven't seen the definition of "zebra" yet, so we don't know what approach to take. I don't think that should be a problem. The compiler already knows about all the assignments occurring in a scope before starting to generate code for it. -- Greg ___ 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/SX66DYOEZSQCLY6JJMIDBS4LFHPB76Y3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 16/01/21 7:56 am, Larry Hastings wrote: As mentioned previously in this thread, typing.get_type_hints() is opinionated in ways that users of annotations may not want. This brings us back to my idea of introducing a new annotations() function to hide the details. It wouldn't be the same as get_type_hints(), since it wouldn't make any assumptions about what the annotations mean. -- Greg ___ 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/OHMQLQXGJDZLYTACJBGZIPJV45H2LF5H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On 14/01/21 3:32 pm, Terry Reedy wrote: I say 'yes', because the purpose of logging is to document what happens, and if nothing happens, there is nothing to document. Wrapping a .__bool__ in a logging decorator might be part of testing it. Or it might be something else. It would be fine to *define* __bool__ as something the compiler is allowed to optimise away. But that's a different thing from "purity" (which is hard to pin down in an imperative language). -- Greg ___ 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/FKQSB6SVOAO2Y3BOQSXSHEN5LM2KBETR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On 14/01/21 1:13 pm, Paul Sokolovsky wrote: But nobody talked about optimizing away generic "pure"-annotated functions (which would differ from "mathematical" definition of purity), only about optimizing "pure" *dunder* methods The same thing applies. If we decide that print() is pure, then a __bool__ that calls print() is also pure, so there's nothing wrong with optimising it away, right? -- Greg ___ 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/KFP2TZXVJAQROMILOOM3CJT24DJESBHJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On 14/01/21 6:17 am, Paul Sokolovsky wrote: For example, print() would be considered "pure", as its purpose is to provide program output, not arbitrarily change program state That definition of purity wouldn't really help with optimisations, though, because optimising away a print() call would still cause a visible change in the program's behaviour. -- Greg ___ 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/B6VDVU7UOB5QNILEJ44J7JOSVBF7WDBF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.10 change (?) for __bool__
On 14/01/21 5:29 am, Steven D'Aprano wrote: No, I don't think it is possible to enforce lack of side-effects. Not without rebuilding the language from the ground up with a clear, definitive and enforcable distinction between pure and impure functions. (I think Haskell does something like that. All functions are pure in Haskell -- not sure if that counts as "doing something like that". Retrofitting it into Python would turn it into a very different language. -- Greg ___ 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/7BOWX7N54CA6FPGJDCQSEH73MQZKJEEE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally
On 13/01/21 3:31 pm, Larry Hastings wrote: Let's say we put those behind a from __future__ import. Now we're gonna write library code that examines annotations. A user passes in a class and asks us to examine its annotations. The old semantics might be active on it, or the new ones. How do we know which set of semantics we need to use? This implies that __future__ is the wrong mechanism to use. It's only appropriate when the changes it triggers are confined to the module that uses it, which is not the case here. -- Greg ___ 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/3R3U2DSRVJRPFCXFCGMZG7KRK53THSGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 13/01/21 5:47 am, Larry Hastings wrote: instead of the compiler storing a code object as the annotations argument to MAKE_FUNCTION, store a tuple containing the fields you'd need to /recreate/ the code object at runtime--bytecode, lnotab, names, consts, etc. Would that tuple be significantly smaller than the corresponding code object, though? -- Greg ___ 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/2NHFIGK55XN4U77V6V2KTBRGJ7TSGAAB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 13/01/21 6:54 am, Larry Hastings wrote: Note that this only works in the current version of the PEP / prototype, where annotations are strictly evaluated in module scope. If we start supporting closures, those need "cell" objects, which IIUC can't be marshalled. The cells belong to the enclosing scope, not the function that uses them. I don't think they would interfere with sharing parts of code objects between identical annotations. -- Greg ___ 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/QKMYWGBSQKNFUNBHXXWFJZ7WIRHGTEWI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 12/01/21 2:56 pm, Larry Hastings wrote: In PEP 649 I think every reference of "binding" is talking about binding a code object to a globals dict to produce a function object. The process of binding a function to an object instance to make a method is conceptually very similar, but distinct. Maybe "bare code object" would be a less confusing term? -- Greg ___ 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/EMVOMYUEQN3ZV5Y2P5B4NEZEJ2KMJTLM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally
On 12/01/21 2:21 pm, Larry Hastings wrote: Slots intelligently support inheritance, too. Are you sure about that? My experiments suggest that it has the same problem as __annotations__: Python 3.8.2 (default, Mar 23 2020, 11:36:18) [Clang 8.1.0 (clang-802.0.42)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... __slots__ = ['a', 'b'] ... >>> class D(C): ... __slots__ = ['c', 'd'] ... >>> class E(D): ... pass ... >>> C.__slots__ ['a', 'b'] >>> D.__slots__ ['c', 'd'] >>> E.__slots__ ['c', 'd'] >>> -- Greg ___ 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/L3OFSRVV6DGB4LXO6GY3WW7PBC2VY7AD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally
On 12/01/21 2:46 pm, Larry Hastings wrote: Using an 64-byte empty dict per object with no defined annotations seems so wasteful. And anything short of an empty dict, you'd have to guard against. If __annotations__ were to return a read-only mapping object instead of a dict, the same empty object could be used for all annotationless objects. -- Greg ___ 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/FEFCXJY52F67R6XEHS4NA3HL6MB4X3I2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 12/01/21 11:32 am, Łukasz Langa wrote: EdgeDB uses stringified annotations exclusively which minimizes runtime memory usage of annotations because those strings are pretty much all ASCII and many can be interned. 946 -> s_schema.Schema 362 -> str 298 -> sd.CommandContext Seems to me the code objects for those would be identical wherever they're used, and so could be cached and re-used the same way as interned strings. -- Greg ___ 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/MYI2JXMBR52HGVL46DRM2KW5T34GC7OP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 12/01/21 10:41 am, Larry Hastings wrote: So: if you're using annotations for something besides "type hints", Didn't Guido decree that using annotations for anything other than type hints is no longer supported? -- Greg ___ 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/GP5PHEAGY4USPDLLMWUG52CGQQ3K4AKI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 12/01/21 10:16 am, Larry Hastings wrote: This is addressed in PEP 563, when it rejected the idea of using "function local state when defining annotations": This would be prohibitively expensive for highly annotated code as the frames would keep all their objects alive. That includes predominantly objects that won't ever be accessed again. I'm not sure what that's supposed to mean. Firstly, functions that reference nonlocal names don't keep whole frames alive, only the particular objects they reference. Secondly, if an annotation references something at module level, that something will also be kept alive unless it is explicitly removed from the module -- which could also be done at a local level if you didn't want to keep those things around. So I don't really see any difference between global and local state when it comes to things being kept alive by annotations. -- Greg ___ 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/GEO6SQL2ZN4KR5A72RK3OGEN4SZQM4TK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally
On 12/01/21 6:22 am, Larry Hastings wrote: * The language will set __annotations__ to a dict if the object has annotations, or None if it has no annotations. That sounds inconvenient -- it means that any code referencing __annotations__ has to guard against the possibility of it being None. If we're changing things, I'm wondering if the best thing would be to introduce an annotations() function as the new best practice for getting an object's annotations. It would know how to handle all the type-specific pecularities, and could take care of things such as manufacturing an empty dict if the object doesn't have any annotations. -- Greg ___ 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/DXQJ2V32YIV5KZQNFSPFVGKKVHIZDFPD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors
On 12/01/21 6:21 am, Larry Hastings wrote: Unbound code objects ...The "annotation code object" is then stored *unbound* as the internal value of ``__co_annotations__``; it is then bound on demand when the user asks for ``__annotations__``. This seems like premature optimisation. Function objects are tiny compared to the code object, which is already a fairly complicated thing composed of a number of sub-objects. -- Greg ___ 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/H7VGQG5YS6LUJGRQH5RHTC7HUUMH64NG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Story behind vars() vs .__dict__
On 9/01/21 9:12 am, Chris Barker wrote: (though I notice that if you create __slots__ in pure Python, its names show up in dict anyway -- so clearly I'm confused...) Descriptors for the slots get added to the *class* dict. But that's not the dict that vars() looks at. -- Greg ___ 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/IVGKEFTRXTSS7MHLH6G4RMJ4INM4LYZT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enhancement request for PyUnicode proxies
Rather than a full-blown buffer-protocol-like thing, could we get by with something simpler? How about just having a flag in the unicode object indicating that it doesn't own the memory that it points to? -- Greg ___ 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/UJTXHTVGG63F6GMGIL4TW6KKLHU7V4DN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Story behind vars() vs .__dict__
On 22/12/20 12:36 am, Paul Sokolovsky wrote: Expected clarification on ".__dict__ breaking object encapsulation": Encapsulation is not something that Python has ever been big on. There are plenty of places where implementation details are exposed, and we don't regard that as a problem. -- Greg ___ 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/BFK7LTKHZ5JLEKUPZXF5AQ3WMGODL4F5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: macOS issues with 3.8.7rc1
On 10/12/20 10:28 am, Guido van Rossum wrote: In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS often needs more memory, which can be a problem Another problem, for me at least, is that OS updates often seem to remove functionality that I like and rely on. I stuck with 10.6 for a very long time, because it did everything I wanted, and there were some third party extensions I used that stopped working in 10.7 and there were no good replacements available. -- Greg ___ 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/57DWVZDDJNXBNT6UKGSFH5STJHYREAHO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis
On 24/11/20 9:44 am, David Mertz wrote: m = Matcher(arbitrary_expression) if m.case("StringNode(s)"): process_string(m.val) elif m.case("[a, 5, 6, b]"): process_two_free_vars(*m.values) elif m.case("PairNone(a, b)"): a, b = m.values process_pair(a, b) elif m.case("DictNode"): foo = {key, process_node(child_node) for key, child_node in m.values.items()} How does the Matcher object know the meanings of "StringNode", "PairNode", etc.? Presumably they're bound to classes in the namespace of the caller, but the Matcher doesn't know anything about that namespace. -- Greg ___ 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/DVEMPPHHVZORWBNWVWJOJZHJMKYYEJ2H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis
On 24/11/20 9:31 am, Brian Coleman wrote: In my opinion, the object oriented solution to this problem is to use the visitor pattern. Which is a good thing only if you believe that OO solutions are always better than non-OO ones. IMO, the visitor pattern is a workaround for when your language doesn't permit introspection on types. It's unnecessary in Python and better avoided. -- Greg ___ 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/XZ2EKVMQXZ5DEV5TWLBKGNU5JWFMIX4Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching
On 23/11/20 7:49 am, Daniel Moisset wrote: Look at the following (non-pattern-matching) snippet: event = datetime.date(x, month=y, day=z) The only names that are treated as lvalues there are to the left of an '='. The rules are a lot simpler. One of the Zen lines says "If it's hard to explain, it's probably a bad idea." I think the proposed rules for match cases are objectively harder to explain than those for other expressions, because they're more complicated. -- Greg ___ 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/AVXFD6J2LGGTJH5LZKBJ3EAGUPV6QPGX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching
On 22/11/20 1:07 pm, Henk-Jaap Wagenaar wrote: On Sat, 21 Nov 2020 at 19:58, Glenn Linderman <mailto:v%2bpyt...@g.nevcal.com>> wrote: Don't () already indicate an expression to be evaluated? Does it? [(a, b)] = [(0, 1)] Presumably a comma would be needed to match a 1-tuple. case (x): # matches the value of x case (x,): # matches any 1-tuple and binds x -- Greg ___ 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/4T3OFJEIGMZEW5QJ3WXFAICK6LZD3P5Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching
On 22/11/20 6:47 am, David Mertz wrote: I'm convinced by Guido, Brandt, and others that the binding use will be far more common, so adding extra characters for the 90% case does not feel desirable Minimising the number of characters is not the only consideration. Readability counts too, and I think the proposed DWIM rules suffer in the readability area. There are about five different contexts in which a bare name can appear as part of a match case: * As a constructor name * As a bare name in an argument position * As part of a dotted expression * On the left of an = * On the right of an = Only in some of those contexts is it treated as a name to be assigned. That's a fairly complex bit of mental parsing to do when reading a case. -- Greg ___ 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/LMALNSPBLL3MHFOJHBGGO24IDS6CI5R3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
On 18/11/20 5:29 pm, Stephen J. Turnbull wrote: Glenn Linderman writes: > Mathematics never came up with separate symbols for equality and > assignment. Mathematics doesn't need them, until we come to an age where we do mathematics on algorithms. Even then, when mathematicians describe algorithms they often use subscripts to disinguish different values of a variable on different iterations, effectively making them into different variables. So they still don't need a symbol for assignment. -- Greg ___ 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/H7KT3RGEJACTHPLL6DFQRHDWHZHZAX33/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?
On 18/11/20 4:36 pm, Larry Hastings wrote: But, the thinking went, you'd never want to examine the last value from a list generator, so it was more convenient if it behaved as if it had its own scope. List comprehensions used to leak, but apparently that was considered surprising by enough people that it was changed. Generator expressions are a bit different -- the only sane way to implement them was to make the body implicitly a separate function, and non-leaking behaviour naturally fell out of that. Making them leak would have taken extra work just to get something that nobody really had a good use case for. The desire to make list comprehensions and generator expressions behave consistently may have contributed to the decision to change list comprehensions to be non-leaking. So yes, it's all a bit messy, for reasons that are partly historical and partly pragmatic, but things seem to work out okay in practice most of the time. If there's anything I would change, it would be to have the for statement create a new binding on each iteration, so that capturing it with a def or lambda inside the loop works as expected. I even came up with a way to do that while still allowing the last-bound value to be seen afterwards, but the idea didn't gain any traction. -- Greg ___ 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/FC7WYLN7C54ZK2FRQSLH5GFA4P2OHBBC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
On 15/11/20 10:48 pm, Paul Sokolovsky wrote: > [from PEP 635] Pattern matching is complimentary to the object-oriented paradigm. BTW, there seems to be a typo here -- I think it's meant to be "complementary". please explain why you chose to proceed anyway (and apply workarounds), instead of first introducing the concept of constants to the language. (Given that amount of work to implement pattern matching is certainly an order of magnitude larger than to introduce constants)." That's not certain at all, and moreover it's not just a matter of work, it's a language design issue that would require its own extensive investigation and debate. Members of the intended audience (people very familiar with Python and its technicalities) can be expected to understand this, so the PEP doesn't need to spell it out. How to support multiple variable scopes in one stack frame is not a rocket science at all. One just need to remember how C did that We can't just do it "like C does" because C requires variables to be declared and Python doesn't. The only reasons for not implementing the same solution in Python would be intertia of thought and "but it's not done anywhere else in Python". No, other reasons include that it would require making unrelated language changes that open various other wormcans. nobody del'eted local variables behind users' backs either, before somebody started to do that for exception clause variables. There was a good reason for that having to do with reference cycles. Nobody liked it much, but we didn't really have a choice. There is no such pressing need for special scope rules in match statements. -- Greg ___ 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/MUCUIUF5LSQOBJDZW3OVHH253GIJBVDN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
On 14/11/20 9:33 am, Jim J. Jewett wrote: 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. I don't think it is a typo, unfortunately. I share this concern, and it's one of the reasons I would prefer assignments to be explicitly marked. With case Point(x=?a, y=?b): then if you get it wrong and write case Point(?a=x, ?b=y): at least you'll get a syntax error. -- Greg ___ 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/JOMGBETRPYWVMRIM3UXZVG422J5TCBCT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
On 14/11/20 7:45 am, Brandt Bucher wrote: with (using your own syntactic flavor): ``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b) I think this is a case where syntax matters. To my eyes this looks far less confusing: case ?first, *?middle, ?last: rebuilt = first, *middle, last case {"key": ?value, **?rest}: rebuilt = {"key": value, **rest} case Point(x=?a, y=?b): rebuilt = Point(x=a, y=b) > (I had to stop and think *hard* where exactly the `>` should go in >`*middle` and `**rest`. There's a simple rule -- the "?" goes directly in front of the thing being assigned. You're assigning to 'middle', not '*middle', so it's '*?middle', not '?*middle'. I know the same rule applies whatever sigil is being used, but to my way of thinking, '>' is too easily confused with a comparison operator. Also it's tempting to interpret '=>' as a single token, which accidentally happens to make sense here, but could mislead people into writing '*=>middle' instead of '*>middle'. -- Greg ___ 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/EQQ4Z4YZ7DCSHTMPUL4P33W4VKXWPZ65/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
On 13/11/20 9:19 am, MRAB wrote: I'd still want to list "as" as another possibility, the advantage being that it's already used for binding elsewhere. Only where it makes English grammatical sense, though, which it doesn't unless there's something on both sides. -- Greg ___ 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/CPXF3P2Y6GJFU2NFBAYKZDH56QQA3NQM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
On 13/11/20 8:21 am, Paul Sokolovsky wrote: The current stage is to accept the fact that "mark capturing terms" is *very viable* alternative to "mark terms to use as values" ... But people behind PEPs keep ignoring that choice - silently, or with minimal consideration/commentary. Their stated justification for this is that capturing will be used much more often than value matching. I'm not convinced about that -- how do they know? This is a feature unlike anything Python has had before. I don't think we can predict how people will use it. Even if it's true, this seems to be prioritising writability over readability. Marking the captures would be my preferred choice. I don't like the idea of DWIM heuristics for distinguishing values from captures, I'd prefer everything to be explicit. And it seems more logical to me to mark the captures rather than the values. The vast majority of expressions in Python are interpreted as values, and assignment targets only occur in a few specially marked places -- on the LHS of an assignment, after "as", etc. I think the same principle should apply in match statements. The only real disadvantage I can see is that it would make pattern matching substantially different from unpacking, but it's been stated that making these compatible is a non-goal, maybe even an anti-goal, and I'm fine with that. -- Greg ___ 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/GURVGWAILH2BAJOEBQU33DVDV4I2ZYCC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: My thoughts on Pattern Matching.
On 7/11/20 4:03 am, Thomas Wouters wrote: It's also why I'm not in favour of PEP 642 and other proposals for solving some of the problems in the Structural Pattern Matching proposal (sigils, etc): it widens the gap instead of closing it. Does that mean you're against *any* proposal that involves sigils, or just PEP 642 in particular? Also, I'm very confused about why you're against PEP 642. It seems to do a good job of meeting your stated goals -- syntax in common between unpacking and matching has the same meaning, and the way is left open for making them more like each other in the future. Can you elaborate on what you don't like about it? -- Greg ___ 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/2X3IME7SD6HOA6D5HRHWR3VSSDKEOGUZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On 6/11/20 4:54 am, Steven D'Aprano wrote: On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote: If "_" is a non-binding wildcard, linters will have to allow "case _, _" otherwise it might as well not be there. And then if it is later changed to be binding, Why would we want to do that? I'm not suggesting we should. I was replying to a post proposing to not treat "_" specially, and pointing out that if we don't make it special now we can't change our mind later. -- Greg ___ 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/3TJC6U7LQOTOZGZVMTP4XXVMGQK6NQP3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On 4/11/20 4:36 am, Paul Svensson wrote: On Tue, 3 Nov 2020, Greg Ewing wrote: once people start using "_" as a wildcard in patterns, it will be too late to go back. But will it, really ? It seems to me, that if we leave the "_" magic out, and leave "case x, x" to the linters, that leaves a clear path forward for whatever can be decided whenever it can be decided. If "_" is a non-binding wildcard, linters will have to allow "case _, _" otherwise it might as well not be there. And then if it is later changed to be binding, "case _, _" will either become invalid or start forcing the two occurrences to be equal, depending on which change is made, thus breaking existing code. The only way I can see to keep our future options open in this area is not to have a wildcard at all, and make people use a different throwaway name for each don't-care position in a pattern. -- Greg ___ 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/RVTWRZ7NM2OWLCXFXJLNYA66GKXYHADN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On 3/11/20 11:01 am, Ethan Furman wrote: I believe supporting case x, x # look ma! no guard! is a possible future enhancement. In which case there will be a need for *some* kind of true "don't care" placeholder. If it's not "_" then it will have to be something else like "?". And we need to decide about it now, because once people start using "_" as a wildcard in patterns, it will be too late to go back. -- Greg ___ 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/CIMR47FNVET4427SUXYWM46LGRAO7JQH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)
On 31/10/20 7:22 am, Mark Shannon wrote: On 30/10/2020 4:09 pm, Brandt Bucher wrote: Anyone who reduces pattern matching to "a fancy switch statement" probably isn't the right person to be discussing its semantics and usefulness with. Pattern matching is a fancy switch statement, if you define "fancy" appropriately ;) I think Brandt's point is that it sounded as though you were making a derogatory remark about the statement option, and that people are likely to stop listening to someone who does that kind of thing. OOI, what is the reasoning for choosing a statement, not an expression? Which is a *much* better way to say what I think you were trying to say. -- Greg ___ 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/RDGU4WSVWVSW7GD3SDAA6W7U6ZXKEZ4E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: os.scandir bug in Windows?
On 27/10/20 8:24 am, Victor Stinner wrote: I would rather want to kill the whole concept of "access" time in operating systems (or just configure the OS to not update it anymore). I guess that it's really hard to make it efficient and accurate at the same time... Also it's kind of weird that just looking at data on the disk can change something about it. Sometimes it's an advantage to *not* have quantum computing! -- Greg ___ 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/GPWWYOB3EQKDLELTYTE4IWGQ726BCPSY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
On 24/10/20 7:52 am, Umair Ashraf wrote: class MyTest(unittest.TestCase): def test_this_and_that(self): """ Given inputs When action is done Then it should pass """ fail def fail(): raise Exception("It didn't work!") Not every one-line function needs to be a keyword! I feel this *fail* keyword is needed to write a test first which fails and then write code and then come back to the test and fill its body. Um, that's not quite how TDD is supposed to work. You don't explicitly write the *test* so that it fails. You write a proper test, and it fails initially because you haven't yet written the code that it tests. -- Greg ___ 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/5PHQ6FMCOF7LSBYLIP5KWMEPSDEUU7MM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Speeding up CPython
A concern I have about this is what effect it will have on the complexity of CPython's implementation. CPython is currently very simple and straightforward. Some parts are not quite as simple as they used to be, but on the whole it's fairly easy to understand, and I consider this to be one of its strengths. I worry that adding four layers of clever speedup tricks will completely destroy this simplicity, leaving us with something that can no longer be maintained or contributed to by ordinary mortals. -- Greg ___ 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/6XBJ2OA46KNMJ6FFI3B6RFYRTTD4HYOI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: os.scandir bug in Windows?
On 20/10/20 4:52 am, Gregory P. Smith wrote: Those of us with a traditional posix filesystem background may raise eyeballs at this duplication, seeing a directory as a place that merely maps names to inodes This is probably a holdover from MS-DOS, where there was no separate inode-like structure -- it was all in the directory entry. -- Greg ___ 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/QJVZ2EXFKCMZ4YHERFI2FXJTWWPFCFSA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Changing Python's string search algorithms
On 17/10/20 3:26 pm, Tim Peters wrote: Tal Einat posted earlier that he was keen to try to work up a clear explanation, and I look forward to that. All the expositions I've found of this algorithm so far are hard to approach. Maybe Mathologer or 3blue1brown could be persuaded to help? They seem to have a knack for making tricky stuff understandable. -- Greg ___ 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/BE3B7K5BTKCJQ63L6RFHW6ZPSQEG67OQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Changing Python's string search algorithms
On 15/10/20 1:45 pm, Chris Angelico wrote: So it'd be heuristics in the core language that choose a good default for most situations, and then a str method that returns a preprocessed needle. Or maybe cache the results of the preprocessing? -- Greg ___ 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/EH26IH753UX3PSURGN5GUKEKX6QDANEZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Understanding why object defines rich comparison methods
On 23/09/20 12:20 am, Steven D'Aprano wrote: Presumably back when rich comparisons were added, the choice would have been: - add one tp_richcompare slot to support all six methods; or - add six slots, one for each individual dunder in which case the first option wastes much less space. I don't know the exact reasons, but it might also have been because the implementations of the six dunders are usually very closely related, so having just one function to implement at the C level is a lot easier for most types. Also remember that before tp_richcompare existed there was only tp_compare, which also handled all the comparisons, so tp_richcompare was likely seen as a generalisation of that. -- Greg ___ 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/SD2YPQSBV3MQ3GGNHVGRM3QM7WEBCTKG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Tagged pointer experiment: need help to optimize
On 22/09/20 10:06 pm, Victor Stinner wrote: I wrote a simple implementation which leaves the code as it is, but "unbox" tagged pointers when a function access directly object members. Example in listobject.c: vl = (PyLongObject*)_Py_TAGPTR_UNBOX(v); wl = (PyLongObject*)_Py_TAGPTR_UNBOX(w); v0 = Py_SIZE(vl) == 0 ? 0 : (sdigit)vl->ob_digit[0]; w0 = Py_SIZE(wl) == 0 ? 0 : (sdigit)wl->ob_digit[0]; I think you're using the terms "box" and "unbox" the opposite way from most people. Usually a "boxed" type is one that lives on the heap, and an "unboxed" one doesn't. My first goal was to write a *correct* (working) implementation, not really an optimized implementation. That's why I'm calling for help to attempt to optimize it ;-) What are you trying to achieve by using tagged pointers? It seems to me that in a dynamic environment like Python, tagged pointer tricks are only ever going to reduce memory usage, not make anything faster, and in fact can only make things slower if applied everywhere. We already have ways of efficiently storing collections of ints and floats -- array.array, numpy, etc. -- and you only pay for the overhead of those if you need them. -- Greg ___ 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/QWWQA2U6M3JLQHQNCWJ4MROISHBDNW3I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Hygenic macros PEP.
On 16/09/20 4:54 pm, Guido van Rossum wrote: I'm not entirely sure how this would preserve the hygiene of the macros though, Despite the title of the PEP, it doesn't actually propose to enforce hygiene either, it just gives some suggested guidelines for macro processors to do it themselves. -- Greg ___ 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/QP2W7V425357MKFJ3R7J3M3V42MIE5MN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Hygenic macros PEP.
On 16/09/20 12:37 pm, Guido van Rossum wrote: IMO if we were to standardize the AST for times immemorial this would have to be a separate PEP. Perhaps, but a stable AST seems to be a prerequisite for this kind of feature. Preferably one that corresponds as closely as possible to the language syntax so that users can keep it in their heads. Maybe the PEP should propose an AST of its own, which would initially be a third thing separate from either of the existing ones, with the possibility of adopting it as the ast module representation some time in the future. -- Greg ___ 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/4HPFUMTERAFB6M3CKE7GJOD2JWOWZTIU/ Code of Conduct: http://python.org/psf/codeofconduct/