[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

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

[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] 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

[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

[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] 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] 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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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] 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

[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

[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

[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

[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

[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

[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] 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] 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 > 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

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

[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

[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] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

On Wed, May 26, 2021 at 8:55 AM Ammar Askar > 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

[Python-Dev] Re: In what tense should the changelog be written?

On Fri, Apr 30, 2021 at 02:22 Steven D'Aprano > 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

[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] 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

[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

[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

[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

[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

[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] 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

[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

[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

[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

[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

[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

[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

[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

[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

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

[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 > wrote: class OuterCls:     class InnerCls:         def method(a:OuterCls.InnerCls=None): pass We've turned the local reference into a global

[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

[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

[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

[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

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

[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

[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

[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

[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

[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",

[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

[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

[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

[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

[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

[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

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

[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

[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"):

[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

[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

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

[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

[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

[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

[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

[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,

[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

[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] 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

[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

[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

[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&quo

[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

[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

[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

[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

[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

[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

[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

[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] 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

[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 =

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

[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

  1   2   3   4   5   6   7   8   9   10   >