[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 3/04/20 10:33 am, Victor Stinner wrote: I also like the fact that PEG is deterministic, whereas LL(1) parsers are not. Where do you get that LL(1) parsers are not deterministic? That's news to me! -- Greg ___ Python-Dev mailing list -- python-dev@

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 3/04/20 2:13 pm, Victor Stinner wrote: "Unlike LL(1) parsers PEG-based parsers cannot be ambiguous: if a string parses, it has exactly one valid parse tree. This means that a PEG-based parser cannot suffer from the ambiguity problems described in the previous section." That paragraph seems r

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 3/04/20 3:22 pm, Guido van Rossum wrote: This allows more freedom in designing a grammar. For example, it would let a language designer solve the "dangling else" problem from the Wikipedia page, by writing the form including the "else" clause first . I'm inclined to think that such problem

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 4/04/20 9:29 am, Brett Cannon wrote: I think "needs" is a bit strong. It would be nice, though. Regardless, as long as this is a net improvement over the status quo I don't see this being rejected on the grounds that an LR or LALR parser would be better since we have a working PEG parser to

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 6/04/20 2:08 am, Jelle Zijlstra wrote: The current CPython parser usually just produces "SyntaxError: invalid syntax" for any error, while other languages that I work with usually say something more precise like 'expected x, got y'. What will the error messages in the PEG parser look like? M

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 6/04/20 4:48 am, Guido van Rossum wrote: There's no need to worry about this: in almost all cases the error indicator points to the same spot in the source code as with the old parser. I'm curious about how that works. From the description in the PEP, it seems that none of the individual pa

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 7/04/20 5:43 am, Guido van Rossum wrote: The biggest difference is that the `|` operator is no longer symmetrical (since if you have alternatives `A | B`, and both match at some point in the input, PEG reports A, while the old generator would reject the grammar as being ambiguous. I'm stil

[Python-Dev] Re: PEP 617: New PEG parser for CPython

On 7/04/20 6:54 am, Guido van Rossum wrote: I'm not sure that that was the conclusion. At the time the point was that we *wanted* all keywords to be reserved everywhere, an `as` was an ugly exception to that rule, which we got rid of as soon as we could -- not because it was a bad idea but bec

[Python-Dev] Re: PEP 617: New PEG parser for CPython

Another point in favour of always-reserved keywords is that they make life a lot easier for syntax highlighters. -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python

[Python-Dev] Re: PEP 554 comments

On 19/04/20 5:02 am, Antoine Pitrou wrote: * How hard would it be, in the current implementation, to add buffering to channels? * In the same vein, I think channels should allow adding readiness callbacks Of these, I think the callbacks are more fundamental. If you have a non-buffered ch

[Python-Dev] Re: PEP 554 comments

On 21/04/20 8:29 am, Eric Snow wrote: * Would a low-level channel implementation based on callbacks or locks be better (simpler, faster, etc.) than one based on buffering? Depends on what you mean by "better". Callbacks are more versatile; a buffered channel just does buffering, but with callba

[Python-Dev] Re: PEP 554 comments

On 21/04/20 10:23 am, Eric Snow wrote: with the current spec channels get automatically closed sooner, effectively as soon as all wrapping objects *that were used* are garbage collected (or released). Maybe I'm missing something, but just because an object hasn't been used *yet* doesn't mean it

[Python-Dev] Re: PEP 554 comments

On 21/04/20 10:35 am, Eric Snow wrote: For the event loop case, what is the downside to adapting to the API in the existing proposal? If you mean the suggestion of having async send and receive methods, that's okay. My point was that before responding to requests to add individual features suc

[Python-Dev] Re: PEP 554 comments

On 21/04/20 10:47 am, Eric Snow wrote: On Mon, Apr 20, 2020 at 4:23 PM Eric Snow wrote: As I've gone to update the PEP for this I'm feeling less comfortable with changing it. I don't get this whole business of channels being associated with interpreters, or why there needs to be a distinction

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On 21/04/20 11:24 am, Edwin Zimmerman wrote: Socket connections could be passed off from the main interpreter to sub-interpreters for concurrent processing that simply isn't possible with the global GIL I would need convincing that the processing involved things that are truly held up by the GI

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On 21/04/20 8:34 pm, Ronald Oussoren via Python-Dev wrote: As far as I understand proper support for subinterpreters also requires moving away from static type definition to avoid sharing objects > between interpreters (that is, use the PyType_FromSpec to build types). Which means updating eve

[Python-Dev] Re: PEP 554 comments

On 22/04/20 3:57 am, Eric Snow wrote: The main difference is that the PEP also provides an way to explicitly release or close a channel. Providing just "close()" would mean one interpreter could stomp on all other interpreters' use of a channel. What I'm suggesting is that close() should do wh

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On 22/04/20 4:21 am, Sebastian Berg wrote: Sure, but this is very different. You can still use NumPy in a project using asyncio. You are _not_ able to use NumPy in a project using subinterpreters. To put it another way, the moment you start using subinterpreters, the set of extension modules yo

[Python-Dev] Re: PEP 554 comments

On 29/04/20 2:12 pm, Eric Snow wrote: One of the main inspirations for the proposed channels is CSP (and somewhat relatedly, my in-depth experience with Go). Channels are more than just a thread-safe data transport between interpreters. It's a while since I paid attention to the fine details o

[Python-Dev] Re: Adding a "call_once" decorator to functools

On 30/04/20 3:29 pm, Raymond Hettinger wrote: Do you think it is safe to hold a non-reentrant lock across an arbitrary user function? I think what's wanted here is to block if it's locked by a different thread, but raise an exception if it's locked by the same thread. -- Greg _

[Python-Dev] Re: PEG parser and raw strings

On 29/05/20 7:26 am, Vito De Tullio wrote: Hi. Just a question about the new PEG parser: will it support lone slash in raw strings? Even if it could be made to, it presumably won't, because that would be a language change (e.g. the meaning of r'foo\'bar' would change). In any case, this is a f

[Python-Dev] Re: How to specify optional support of arguments

Instead of a bunch of ad-hoc mechanisms for finding out about platform-dependent arguments, maybe there should be a function in the inspect module for testing whether a function has a given argument. Then you could say something like if inspect.hasargument(glob.glob, 'dir_fd'): ... -- G

[Python-Dev] Re: REPL output bug

On 16/06/20 12:20 pm, Steven D'Aprano wrote: The whole point of the REPL is to evaluate an expression and have the result printed. (That's the P in REPL :-) Still, it's a bit surprising that it prints results of expressions within a compound statement, not just at the top level. -- Greg __

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 24/06/20 5:20 am, Antoine Pitrou wrote: suddently `Point(x, 0)` means something entirely different (it doesn't call Point.__new__, it doesn't lookup `x` in the locals or globals...). This is one reason I would rather see something explicitly marking names to be bound, rather than making the

[Python-Dev] Re: PEP 622: Structural Pattern Matching

  2) Use comma as the separator - this is already legal syntax too, but IMO it reads more naturally.   (And IIRC there are already contexts where brackets are necessary to indicate a tuple.) This would be my preferred option. Another possibility would to be allow cases to share the same

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 24/06/20 9:31 am, Chris Angelico wrote: I can't find it among the rejected alternatives, but was it considered to use "..." as the wildcard, rather than "_"? It currently has a value as an expression, so you might want to match against it. (I don't think the syntax in the PEP currently allow

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 24/06/20 11:57 am, Guido van Rossum wrote: Matched key-value pairs must already be present in the mapping, and not created on-the-fly by ``__missing__`` or ``__getitem__``.  For example, ``collections.defaultdict`` instances will only match patterns with keys that were already present when

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 24/06/20 11:26 am, Guido van Rossum wrote: A design pattern where a group of record-like classes is combined into a union is popular in other languages that support pattern matching and is known under a name of algebraic data types [2]_ or ADTs. Whoo, that's confusing! I read "ADT" as "Abstr

[Python-Dev] Re: PEP 622: Structural Pattern Matching

I had another thought about a way to make the bound names explicit. # Keyword case Point(x -> px, y -> py): # Positional case Point(-> x, -> y): # Sub-pattern, positional case Line(Point() -> p1, Point() -> p2): # Sub-pattern, keyword case Line(start: Point() -> p1, end

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 3:31 am, Taine Zhao wrote: https://thautwarm.github.io/Site-32/Design/PEP622-1.html In your AND pattern example, you seem to envisage there being a Urlopen class whose __match__ method has the side effect of opening the URL. This makes it much more than just a pattern to be matched

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 6:36 am, Brandt Bucher wrote: Another option I've considered is using the `keys` method, since most non-dict mappings would get this called anyways for patterns with `**rest`. All the more reason why we should allow the implementation some flexibility. ;) My concern was only that

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 8:49 am, Tim Peters wrote: Spell it, e.g., "or", and then I wonder "what does short-circuiting have to do with it?". Well, it does short-circuit -- if one alternative matches, it doesn't bother with any subsequent ones. Which could be considered an argument for using "or" instead of

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 4:24 pm, Emily Bowman wrote: There's always making everyone equally annoyed, and allowing 'case else:' Visual Basic does actually use "case else". (And "select case" at the beginning, just to be as annoying as possible.) -- Greg ___ Pytho

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 7:50 pm, Anders Munch wrote: Pascal is a precedent for this placement of 'case', Yes, but it doesn't use it with "match". In fact it doesn't have any keyword in front of the values to be matched; it goes like case n of 1: ...; 2: ...; 3: ...; end If we did

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 26/06/20 1:18 am, Rhodri James wrote: I will quickly and regularly forget that in this one place, "_" is special. You don't have to remember that it's special to understand what 'case _' does. Even if it were treated as an ordinary name, it would still have the effect of matching anything.

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 26/06/20 5:07 am, MRAB wrote: How do you indicate that you want it to match anything and don't care about the value? case Spam(-> _): Or if that's considered too verbose and we're willing to make _ even more special, it could be just case Spam(_): In that case we would be regarding

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 26/06/20 12:31 pm, Brandt Bucher wrote: I'd imagine that we either find some straightforward way of > opting-in to the current default behavior Maybe special-case 'self' in __match_args__ to mean the object being matched? -- Greg ___ Python-Dev m

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 26/06/20 1:08 pm, Paul Svensson wrote: We already allow (x, x) = (1, 2) So, why do we need to disallow binding several values to the same name ? I think it was done because people might expect that to match only if the *same* value appears in both places. Some other languages have pattern ma

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 26/06/20 2:10 pm, Gregory P. Smith wrote: match get_shape() as shape:   case start, end := Line@(shape): This looks just as inscrutable to me in its own way. -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an emai

[Python-Dev] Re: The Anti-PEP

On 26/06/20 2:18 pm, Gregory P. Smith wrote: Regardless i don't see how an anti-pep would work much better, but I also don't see anything stopping anyone from trying one.  I worry that it'll fragment conversation even more and separate discussions so that everyone is even more confused about ov

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 26/06/20 5:45 pm, Ned Deily wrote: Hasn't "|" been used in a similar way for decades in Unix/POSIX shell patterns, including with the shell case statement? Yes, but I regard Unix shell syntaxes as just plain weird and not a good model for designing a language on. -- Greg __

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 26/06/20 6:21 am, Pablo Galindo Salgado wrote: Which means that users can do a positional match against the proxy with a name pattern: match input:     case datetime.date(dt):         print(f"The date {dt.isoformat()}" I think that would be an incorrect way for matching on datetime to be

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 29/06/20 8:47 am, Daniel Moisset wrote:  . You seem to be trying to shoehorn all Python data structures into looking like alebraic types, for the sole purpose of being able to claim that PEP 622 is real

[Python-Dev] Re: Recent PEP-8 change

Sorry for fanning the flames, but this whole thread is so over the top I'm finding it kind of entertaining. On 1/07/20 2:23 am, Piper Thunstrom wrote: The grammarian movement, in general, was built on elevating a very specific form of English over others. It specifically was chosen to avoid "low

[Python-Dev] Re: PEP 622 (match statement) playground

On 2/07/20 4:54 am, Brandt Bucher wrote: It sounds like you want to add "global z" to the top of the function definition. Or more likely, change the last case to 'case _'. -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe se

[Python-Dev] Re: PEP 622 (match statement) playground

On 2/07/20 9:25 am, Matthias Bussonnier wrote: It's still weird user experience as if you swap case .z and case z you don't get the Unbound error anymore. It also won't work as intended, because 'case z' will always match and it will never get to 'case .z'. -- Greg ___

[Python-Dev] Re: Recent PEP-8 change

On 2/07/20 10:53 pm, MRAB wrote: Alternatively, it could be an auxiliary language like Esperanto. Maybe Esperanto in particular wouldn't be the best choice -- I gather it's rather European-oriented. Maybe we should standardise on Klingon? Humans of all cultures would find it equally difficult.

[Python-Dev] Re: Recent PEP-8 change

On 3/07/20 1:52 am, Paul Moore wrote: What *is* the correct inclusive way to refer to an unidentified person in a technical document... My impression is that commonly accepted language rules and usage are lagging behind, I don't know if "lagging behind" is the right term, seeing as there seems

[Python-Dev] Re: Recent PEP-8 change

On 3/07/20 5:37 am, Rhodri James wrote: It was in Latin classes that I learned how sentences are put together, and that's what I default to when I'm not thinking hard enough. For me it's French -- I learned much more about English grammar while studying French than I ever did from English clas

[Python-Dev] Re: Recent PEP-8 change

On 3/07/20 5:09 am, David Mertz wrote: "they" has long been used in that "indeterminate-not-inanimate" way since 14th century (different from "it").  "He" has often been used that as well, but really with the implication that a generic person is male. Maybe the indeterminate use of "he" was i

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

On 4/07/20 4:52 am, Jim J. Jewett wrote: Specifying British English "British English" is woefully underspecified -- there are probably more variants of English used in Britain than in the rest of the world put together. -- Greg ___ Python-Dev mailing

[Python-Dev] Re: Recent PEP-8 change

On 4/07/20 4:33 am, Jim J. Jewett wrote: If Bob and Alice seem neutral to you, would you do a double-take on Kehinde or Oladotun? Maybe we should use randomly generated names for hypothetical persons? -- Greg ___ Python-Dev mailing list -- python-de

[Python-Dev] Re: Recent PEP-8 change

On 5/07/20 3:26 am, Stephen J. Turnbull wrote: Greg Ewing writes: > Maybe we should use randomly generated names for hypothetical > persons? Randomly generated according to what character repertoire and lexical rules (I'm not talking about British v. American)? Randomly se

[Python-Dev] Re: Recent PEP-8 change

On 5/07/20 8:23 am, MRAB wrote: On 2020-07-04 19:23, Paul Moore wrote: Surely the obvious thing to do would be to use Monty Python characters? True, but if they were all called Eric it could be confusing. Also the Monty Python team were all white, so it wouldn't really solve the problem. --

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On 5/07/20 8:30 am, MRAB wrote: On 2020-07-04 21:07, Martin Dengler wrote: How do you spell "regionalism"? As far as I'm aware, there's only one way to spell it, I suppose there could be some planet where it's spelled "regionalizm". -- Greg ___ Pyt

[Python-Dev] Re: [Suspected Spam]Re: Recent PEP-8 change

On 5/07/20 3:24 am, Stephen J. Turnbull wrote: Amusingly, Strunk (1918) was perfectly happy with split infinitives, though he noted it centered whiteness. (Obviously he didn't put it that way, more along the lines of "some people will look down on you.") Um... what? Are you saying that people

[Python-Dev] Re: [Suspected Spam]Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

On 6/07/20 2:56 am, Stephen J. Turnbull wrote: Thing is, I'm sure I've used Americanisms and even the dreaded Academic Register, but I sure never noticed them! :-) Or, in non-American, "surely never noticed them". :-) -- Greg ___ Python-Dev mailing l

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On 8/07/20 2:31 am, Henk-Jaap Wagenaar wrote: Would it be possible here to use a syntax/symbol that is illegal instead of _? I think this has been mooted but my favourite (so far) would be "?" so you have "case ?:" and "Point(?, ?)". Would ?name then work instead of ".name" as well? It would

[Python-Dev] Re: PEP 622 railroaded through?

On 8/07/20 12:24 pm, Daniel Moisset wrote: Many people in this thread have argued that the double meaning in the PEP might be confusing, but Python already has a double meaning in other places. But assignment targets have always been clearly separated by being on the left of an assignment oper

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On 8/07/20 5:30 am, Paul Sokolovsky wrote: from __future__ import const FOO: const = 1 match val: case FOO: # obviously matches by constant's value This would make it *more* difficult to distinguish constants from assignment targets when looking at the match statement, unless you choose

[Python-Dev] Re: PEP 622 railroaded through?

On 8/07/20 12:48 pm, Chris Angelico wrote: "for x[0] in iter:" uses x[0] as an assignment target, You're right, there are some others, but I think they're equally clear -- all the ones I can think of are directly after a keyword ("for", "as", "import", etc.) But in match statements, they can b

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 9/07/20 3:26 am, Brandt Bucher wrote: match : case | : ... case | if : ... case | : ... ``` It's safe to use the same decision tree for through , but it must be rebuilt for and , since could have done literally *anything*. I think you're being overly cautious here. To

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 9/07/20 3:30 am, Luciano Ramalho wrote: I strongly favor the option of aligning the `else` clause with `match`, because `else` is a special clause therefore it should look special. But on the other hand, it's semantically equivalent to 'case _:', so it's not all that special. -- Greg __

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

A thought about the indentation level of a speculated "else" clause... Some people have argued that "else" should be at the outer level, because that's the way it is in all the existing compound statements. However, in those statements, all the actual code belonging to the statement is indented

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 11/07/20 10:35 am, Federico Salerno wrote: I feel all those who aren't directly arguing against it are working off the assumption that it is needed for match and case to have different levels of indentation, but is this really true? Is there anything (bar tradition or other subjective argume

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 11/07/20 11:20 pm, Paul Sokolovsky wrote: On Sat, 11 Jul 2020 22:49:09 +1200 Greg Ewing wrote: or like this: switch (x) { case 1: ... case 2: ... default: ... } Oh really, you never saw that? Well, they say that any programmer should

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Just had another thought about marking assignment targets. The PEP currently forbids repeating bound names in a pattern to avoid raising expectations that case Point(x, x): would match only if the two arguments were equal. But if assignment targets were marked, we could write this as

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 12/07/20 7:03 am, Federico Salerno wrote: On 11/07/2020 12:49, Greg Ewing wrote:    switch (x) {    case 1:   ...    case 2:   ...    default:   ...    } > I think that last one would be perceived as ok if it weren't for the brackets: everyone naturally indents an

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 12/07/20 7:13 am, Eric Nieuwland wrote: match poly: p0 = Point(x0, y0) p1 = Point(x1, y1) p2 = Point(x2, y2) case Polygon(p0, p1, p2): … Interesting idea, but what happens if you *don't* need any setup? D

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/11/2020 10:29 AM, Jim J. Jewett wrote: To me, "else:" has a slightly different meaning than "case _:" case _:  essentially a default, ensuring that the match logic is complete. else:  OK, the subject of this match failed, here is our fallback logic. Is there anywhere el

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/20 7:12 am, Larry Hastings wrote: I dimly recall a precedent where the presence of locals() in a function body affected code generation, The presence of exec used to do that, which is why it was a statement rather than a function. But I don't think locals() ever did -- how would the co

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/20 3:28 pm, Devin Jeanpierre wrote: The compiler changes what local variables exist if there is a read from a variable named 'super', That's fairly harmless if there's a false positive. But accidentally getting all your locals de-optimised would be annoying. -- Greg __

[Python-Dev] Re: PEP 622: capturing into an explicit namespace

On 18/07/20 4:34 am, Richard Levasseur wrote: match get_point() into m:   case Point(m.x, m.y):     print(m.x, m.y)   ...etc... Personally, I thought this was a rather elegant solution to the load-vs-store problem for names. This is because, essentially, it changes the mental model from "so

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

On 2/09/20 8:32 am, Neil Schemenauer wrote: The most obvious approach is to adopt a multi-threaded model like is done by modern Java. I.e. no GIL and non-thread safe core data structures. That sounds a bit scary but based on Java experience it seems programmers can manage it. I think that dep

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

On 2/09/20 6:11 pm, Neil Schemenauer wrote: Weird things would include unexpected exceptions. I don't mind unexpected exceptions, but I would mind core dumps. -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email t

[Python-Dev] Re: Hygenic macros PEP.

On 16/09/20 9:34 am, Pablo Galindo Salgado wrote: The first is that deleting a deep tree currently is just freeing the arena block, while if the nodes were PyObjects it will involve recursive destruction. That could potentially segfault Not sure why that would be a concern. It's theoretically

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

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

[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

[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] yield * (Re: Missing operator.call)

Guido van Rossum wrote: It would be way too confusing to have "a different form of call" with totally different semantics that nevertheless used the same *terminology* as is used for regular calls. I expect you're right, so I won't argue for calling it "call" any more. I'd still like to find

Re: [Python-Dev] yield * (Re: Missing operator.call)

Willem Broekema wrote: Function g violates the current limitation that generators can't return with a value. So can g only be used using "yield *" then, or would that limitation be removed? The limitation would be removed, in the interests of making it easier to use generators as coroutines.

Re: [Python-Dev] yield * (Re: Missing operator.call)

Guido van Rossum wrote: We already have yield expressions and they mean something else... They don't have a "*" in them, though, and I don't think the existing meaning of yield as an expression would carry over into the "yield *" variant, so there shouldn't be any conflict. But if you think th

Re: [Python-Dev] yield * (Re: Missing operator.call)

gl...@divmod.com wrote: has anyone considered the syntax 'yield from iterable'? That would be reasonable, too. I don't really have any strong feelings about the syntax at the moment, except that I'd like it to be something reasonably short so that embedding it in an expression is a feasible th

[Python-Dev] Small misleadingness in docs

I've discovered something slightly misleading in the docs for PyObject_IsInstance: When testing if B is a subclass of A, if A is B, PyObject_IsSubclass returns true. If A and B are different objects, B‘s __bases__ attribute is searched... This suggests that issubclass(A, A) will always be

Re: [Python-Dev] Small misleadingness in docs

Raymond Hettinger wrote: This smells like a bug that brings issubclass() out of sync with isinstance(). No, it affects both isinstance() and issubclass(). They both raise a TypeError if the purported class object doesn't have a __bases__ attribute that is a tuple. This isn't necessarily wrong

Re: [Python-Dev] Wow!

Brett Cannon wrote: Is there a Python connection I'm missing? http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story Well, the front page of python.org does say "NASA uses Python"... Also it sounds like they could do with a really good garbage collect

Re: [Python-Dev] Small misleadingness in docs

Georg Brandl wrote: Since I cannot imagine a scenario where you would want to have non-classes as the arguments of issubclass(), I had one today, which is what led me to discover this. I'm working on a Python-Ruby bridge that wraps Ruby objects and classes in Python objects. I wanted to make

Re: [Python-Dev] Small misleadingness in docs

Terry Reedy wrote: The new (in 3.0 and maybe 2.6, but undocumented) special methods __instancecheck__ and __subclasscheck__ let one overload the default behavior of isinstance and issubclass. That's fine for 3.0, but I don't think the current behaviour should be removed from any 2.x version,

Re: [Python-Dev] Wow!

Leif Walsh wrote: If only we had a second Earth to mess with, we could just copy and swap. Or we could use a generational approach, doing all our messy stuff around the moon and copying to earth when we've got our traffic control issues sorted out. -- Greg

Re: [Python-Dev] Duck-typing self

Sebastian Rittau wrote: Is it a design decision that duck-typing self does not work or is there a technical reason? There's no technical reason as far as user-defined classes are concerned. I think it was introduced to help catch errors due to making inherited method calls to the wrong class,

Re: [Python-Dev] Duck-typing self

Christian Heimes wrote: In 2.x a class objects wrap their functions in a method wrapper. The method wrapper does the type check. You can get around the type check by using the im_func attribute of the method wrapper. You could probably also create a decorator that gives you something behaving

Re: [Python-Dev] IO implementation: in C and Python?

Steven D'Aprano wrote: Currently, if I want to verify that (say) cFoo and Foo do the same thing, or compare their speed, it's easy because I can import the modules separately. Also, won't foo.py be wasting time in most cases by defining python versions that get overwritten? Instead of defini

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

Brett Cannon wrote: So while this alleviates the worry above, it does mean that anything that gets rewritten needs to have a name that does not lead with an underscore for this to work. You can use an __all__ list to explicitly say what is to be exported. -- Greg _

Re: [Python-Dev] Choosing a best practice solution for Python/extension modules

Daniel Stutzbach wrote: No, I'm afraid Brett is quite right. Globals are looked up when the function is executed, true, but they are looked up within the module that defined the function. I was thinking you could fix that by going over the imported functions and stuffing the current globals

Re: [Python-Dev] Silencing IO errors on del/dealloc?

Antoine Pitrou wrote: I would like to change this behaviour so that the "try/except" enclosure above is removed, letting __del__ at least print those (unraisable) errors on the console. Of course I also advocate doing so in the C version of the IO lib. I would hope that the C version could at

Re: [Python-Dev] Reviving restricted mode?

Guido van Rossum wrote: Tav is interested in using this on app engine, which doesn't care about segfaults -- the process is simply restarted, nobody gains access to information they shouldn't have. App engine does care about overwriting memory, That doesn't make sense -- how can something not

Re: [Python-Dev] Challenge: Please break this! [Now with blog post]

tav wrote: But that doesn't invalidate the model or the possibility of using it in Python. However, there's also the matter of whether it's *practical* to use the model in Python. The custom-string exploit illustrates that you have to be extremely careful what you do with, and what you assume

Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement

Giovanni Bajo wrote: Just today, I was talking with a colleague (which is learning Python right now) about "ordered dict". His first thought was a dictionary that, when iterated, would return keys in sorted order. I wonder whether "indexed list" would be a more appropriate name for what we're

<    2   3   4   5   6   7   8   9   10   11   >