[Python-Dev] Re: Should Python typing leverage PEP 263 as a pre-processor step?

Hello, On Tue, 20 Apr 2021 11:08:56 +0200 Victor Stinner wrote: > I proposed PEP 511 "API for code transformers" for Python 3.6 (in > 2016) and it was rejected: > https://www.python.org/dev/peps/pep-0511/#rejection-notice Well, it wasn't rejected, it was self-rejected on the thought-crime

[Python-Dev] Re: Should Python typing leverage PEP 263 as a pre-processor step?

Hello, On Mon, 19 Apr 2021 20:23:08 -0700 Guido van Rossum wrote: [] > > How does this "similar thing" compare to the recently announced > > imphook module? > > > > For one, pyxl is a better name. :-) I would humbly disagree ;-). > Seriously, as long as the purpose is to allow using a

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

Hello, On Sat, 27 Mar 2021 20:01:27 + Irit Katriel wrote: [] > > you gentlemen come up with the "ultimate" way to deal with multiple > > errors, > > I've been mistaken for a man before, but no-one has ever confused me > for gentle. I'll take that as a compliment. Sorry, was just a

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

thing that "works better". Again, I wanted to mention that point, as between the initial PEP version and the latest one, I don't see that alternative to have been mentioned in the PEP (which might mean that it wasn't mentioned enough by other reviewers). > > Irit > > On Sat, Mar

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

ehavior. Where complex and magic behavior in exception handling is itself of concern, so making it more explicit may be a good idea. (A good "how other languages deal with it") review would mention that Go, Rust, Zig, etc. don't have and condemn exception handling at all (normal simple

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

Hello, On Fri, 26 Mar 2021 16:19:26 -0700 Guido van Rossum wrote: > Everyone, > > Given the resounding silence I'm inclined to submit this to the > Steering Council. While I'm technically a co-author, Irit has done > almost all the work, and she's done a great job. If there are no > further

[Python-Dev] Re: [Python-ideas] Inadequate error reporting during function call setup stage

Hello, On Mon, 22 Feb 2021 19:47:04 + Barry Scott wrote: > > On 22 Feb 2021, at 10:15, Paul Sokolovsky wrote: > > > > It looks like: > > > > Traceback (most recent call last): > > File "pseudoc_tool.py", line 91, in > > File "..

[Python-Dev] Re: [Python-ideas] Re: Inadequate error reporting during function call setup stage

Hello, On Mon, 22 Feb 2021 10:44:19 +0100 Peter Otten <__pete...@web.de> wrote: > On 21/02/2021 23:06, Terry Reedy wrote: > > On 2/21/2021 12:04 PM, Paul Sokolovsky wrote: > > > >> Traceback (most recent call last): > >

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

Hello, On Mon, 22 Feb 2021 09:20:46 +0100 Michał Górny wrote: > On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote: > > The main thing from a project maintenance perspective is for > > platforms to > > not become a burden to other code maintainers.  PRs need to be > > reviewed. > > Every

[Python-Dev] Inadequate error reporting during function call setup stage

Hello, Here's example: Traceback (most recent call last): File "pseudoc_tool.py", line 91, in first_class_function_value(func, **pass_params) TypeError: print() got an unexpected keyword argument 'noann' Ok, which "print" do you mean, dear CPython? I have a dozen of print functions

[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

Hello, On Fri, 19 Feb 2021 06:29:35 -0300 Luciano Ramalho wrote: > On Fri, Feb 19, 2021 at 4:08 AM Guido van Rossum > wrote: > > Can you try this? > > > > async def __sleep(self): > > await None > > That didn't work*, but this does: > > async def __sleep(): > return None > > Was

[Python-Dev] Re: Python 0.9.1

Hello, On Wed, 17 Feb 2021 18:53:46 -0600 Skip Montanaro wrote: > > If we can get a clean copy of the original sources I think we > > should put them up under the Python org on GitHub for posterity. > > Did that earlier today: > > https://github.com/python/pythondotorg/issues/1734 I think

[Python-Dev] Re: Python 0.9.1

Hello, On Tue, 16 Feb 2021 18:22:00 -0600 Skip Montanaro wrote: > > If someone knows how to get the original Usenet messages from what > > Google published, let me know. > > Seems the original shar is there buried in a Javascript string toward > the end of the file. I think I've got a handle

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Hello, On Sat, 13 Feb 2021 19:48:10 - "Eric Traut" wrote: [] > Paul said: > >...to work around deficiencies in the current generation of Python > >typecheckers > > It sounds like you're implying that this functionality will be no > longer needed at some point in the future when type

[Python-Dev] Re: Python standardization

Hello, On Sat, 13 Feb 2021 23:10:59 +0900 "Stephen J. Turnbull" wrote: > Chris Angelico writes: > > > Can you explain what would be improved by having a formalized > > standard? > > The Language Reference together with the Library Reference *already* > constitute a formalized standard.

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

Hello, On Sat, 13 Feb 2021 18:08:30 +1100 Steven D'Aprano wrote: > On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote: > > > It impairs readability, because it muddles the return type. > > The function in the example returns a bool. > > The annotation is also misleading as the

[Python-Dev] Re: [python-committers] Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642

Hello, On Tue, 9 Feb 2021 08:56:02 +1000 Nick Coghlan wrote: > > After much deliberation, the Python Steering Council is happy to > > announce that we have chosen to accept PEP 634, and its companion > > PEPs 635 and 636, collectively known as the Pattern Matching PEPs. > > We acknowledge that

[Python-Dev] Re: What's up with assignment expression and tuples?

" on the language level is still first on my list, and I'm pretty far from a PEP for it either ;-). > > On Sun, Feb 7, 2021 at 23:58 Paul Sokolovsky > wrote: > > > Hello, > > > > On Sun, 7 Feb 2021 13:10:55 -0800 > > Guido van Rossum wrote: > >

[Python-Dev] Re: What's up with assignment expression and tuples?

g within index expression useful, up to reporting it, and then other people ack it and fix it, then why not fix parallel assignment case? Implementation-wise they *seem* to be of the similar effort/complexity - just a one-term grammar change. (I still need to run the testsuite, yeah). > > --Gui

[Python-Dev] Re: Concerns about PEP 634

Hello, On Sun, 7 Feb 2021 20:02:48 +1100 Chris Angelico wrote: > On Sun, Feb 7, 2021 at 7:54 PM Paul Sokolovsky > wrote: > > > > So, you're saying that, by the benevolence of divine providence, > > most (can you truly vouch for "all" and provide ev

[Python-Dev] Re: Concerns about PEP 634

Hello, On Sun, 7 Feb 2021 19:09:14 +1100 Chris Angelico wrote: > On Sun, Feb 7, 2021 at 6:25 PM Paul Sokolovsky > wrote: > > > > Hello, > > > > On Sat, 6 Feb 2021 23:05:19 -0800 > > Guido van Rossum wrote: > > > > > That

[Python-Dev] Re: Concerns about PEP 634

Hello, On Sun, 7 Feb 2021 04:53:43 +0300 Ivan Pozdeev wrote: > On 07.02.2021 0:24, Paul Sokolovsky wrote: > > Hello, > > > > On Sun, 7 Feb 2021 00:00:41 +0300 > > Ivan Pozdeev via Python-Dev wrote: > > > >> Who said "__future__"? > &

[Python-Dev] Re: Concerns about PEP 634

there could be small incompatible changes going forward"). > > On Sat, Feb 6, 2021 at 22:44 Paul Sokolovsky > wrote: > > > Hello, > > > > On Sun, 7 Feb 2021 01:17:31 + > > Paul Bryan wrote: > > > > > On Sat, 2021-02-06 at 22:00

[Python-Dev] Re: Concerns about PEP 634

Hello, On Sun, 07 Feb 2021 13:32:17 +1300 Greg Ewing wrote: > 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. >

[Python-Dev] Re: Concerns about PEP 634

Hello, On Sun, 7 Feb 2021 13:21:08 +1100 Steven D'Aprano wrote: > On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote: > > On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico > > wrote: > > > How will a __future__ import help here? Are there syntactic or > > > behavioural changes that

[Python-Dev] Re: Concerns about PEP 634

Hello, On Sun, 7 Feb 2021 01:17:31 + Paul Bryan wrote: > On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote: > > > A __future__ import would make clear to all that the feature is > > experimental, and maybe there could be __future__ imports for > > different parts of the proposal.

[Python-Dev] Re: Concerns about PEP 634

Hello, On Sun, 7 Feb 2021 00:00:41 +0300 Ivan Pozdeev via Python-Dev wrote: > Who said "__future__"? Other people said __future__. And yet other said "it's ok the way it is, it's better to have it like that then keep not having it". And yet other said something else (multiple else's). > I

[Python-Dev] Re: What's up with assignment expression and tuples?

Hello, On Sat, 6 Feb 2021 10:46:54 +0200 Serhiy Storchaka wrote: > 05.02.21 09:51, Paul Sokolovsky пише: > > a0 = 0 > > b0 = 10 > > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: > > a2 = a1 + 1 > > b2 = b1 + 1 > > Such code quickly beco

[Python-Dev] Re: What's up with assignment expression and tuples?

Hello, On Sat, 06 Feb 2021 12:35:09 +1300 Greg Ewing wrote: > On 5/02/21 8:51 pm, Paul Sokolovsky wrote: > > a = 0 > > while a < 5: > > a += 1 > > > > > > becomes: > > > > > > a0 = 0 > > while (a1 := phi(a

[Python-Dev] Re: What's up with assignment expression and tuples?

Hello, Thanks for the reply. On Fri, 5 Feb 2021 13:32:25 -0500 Terry Reedy wrote: > On 2/5/2021 2:51 AM, Paul Sokolovsky wrote: > > > https://www.python.org/dev/peps/pep-0572/ > ... > > >>>> ((a, b) := (1, 2)) > >File "", line 1 &

[Python-Dev] What's up with assignment expression and tuples?

Hello, Everyone knows how hard to find a compelling usecase for the assignment expression operator (":=", colloquially "walrus operator"). https://www.python.org/dev/peps/pep-0572/ examples never felt compelling and we all remember the split it caused. I finally found a usecase where *not* using

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

Hello, On Tue, 19 Jan 2021 14:31:49 +1300 Greg Ewing wrote: > 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

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Thu, 14 Jan 2021 22:05:37 +1100 Steven D'Aprano wrote: > On Wed, Jan 13, 2021 at 08:17:26PM +0300, Paul Sokolovsky wrote: > > > > Besides, we probably don't want to prohibit side-effects in > > > `__bool__`. That would prohibit useful tricks such as put

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Thu, 14 Jan 2021 23:00:06 +1300 Greg Ewing wrote: > 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

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Thu, 14 Jan 2021 12:45:11 +1300 Greg Ewing wrote: > 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 > &g

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Thu, 14 Jan 2021 03:29:35 +1100 Steven D'Aprano wrote: > On Wed, Jan 13, 2021 at 02:08:01AM -0800, Emily Bowman wrote: > > Even if you define __bool__() as returning a bool, and > > error/undefined behavior otherwise, that doesn't eliminate side > > effects. Is it even possible to

[Python-Dev] Re: 3.10 change (?) for __bool__

ions to be a part of Python's nature, so wanting to use them more shouldn't come as surprise). > > -Em > > On Wed, Jan 13, 2021 at 12:18 AM Paul Sokolovsky > wrote: > > > Hello, > > > > On Wed, 13 Jan 2021 18:27:07 +1100 > > Chris Angelico wrote: >

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Wed, 13 Jan 2021 18:27:07 +1100 Chris Angelico wrote: [] > > Optimizations are an implementation detail, and implementation > > details should not change the language. > > The language can also be defined in an optimization-friendly way, > though. Consider how we got

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

Hello, On Wed, 13 Jan 2021 05:04:36 - "Jim J. Jewett" wrote: > Paul Sokolovsky wrote: > > Ok, let's take "module attribute" as an example. Why do you think > > there's anything wrong with this code: > > == > > import config > &

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

Hello, On Mon, 11 Jan 2021 13:44:45 -0800 Larry Hastings wrote: > The control-flow exclusion is for /module//attribute/ or /class > attribute/ annotations: > > class C: >   if random.random() > 0.5: >     my_attr:int=3 >   else: >     my_attr2:float=3.5 Ok, let's take

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Hello, On Tue, 12 Jan 2021 00:11:33 +1000 Nick Coghlan wrote: > On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky, > wrote: > > > And I patiently continue this thread, hoping that people whose > > argument would be along the lines of "I teach Python, and I don't >

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Hello, On Sun, 10 Jan 2021 12:08:05 +1000 Nick Coghlan wrote: [] > PEP 634 doesn't have that feature for class patterns in general, only > for classes like data classes, where the constructor signature is > carefully aligned with the match arguments. You see, if PEP622/PEP634 contained clause

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Hello, On Sun, 10 Jan 2021 01:42:25 +1000 Nick Coghlan wrote: > On Sat, 9 Jan 2021, 8:50 pm Paul Sokolovsky, > wrote: > > > > > > > The key difference relative to PEP 634 is that even when the code > > > author uses the shorthand form, *readers* will still

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Hello, On Sat, 9 Jan 2021 14:49:19 +0100 Antoine Pitrou wrote: > On Sat, 9 Jan 2021 12:17:32 + > Paul Moore wrote: > > > On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky > > wrote: > > > > case {"host" as host, "port"

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Hello, On Sat, 9 Jan 2021 12:27:45 +1000 Nick Coghlan wrote: > On Sat, 9 Jan 2021, 7:07 am Joseph Martinot-Lagarde, > wrote: > > > Paul Sokolovsky wrote: > > > Hello, > > > On Tue, 5 Jan 2021 20:37:27 +1000 > > > Nick Coghlan ncogh...@gmail.com

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Hello, On Tue, 5 Jan 2021 20:37:27 +1000 Nick Coghlan wrote: > > > object(host=as host, port=as port}:", but that couldn't ever be I'd like to point out the weirdness of the "as" syntax when applied to positional arguments, e.g.: case [as x, as y]: case Cls(as x, as y): That feels unnatural,

[Python-Dev] Re: [Python-ideas] Re: Add venv activate command to the venv modules

Hello, On Mon, 4 Jan 2021 21:07:23 +0400 Abdur-Rahmaan Janhangeer wrote: > @Christopher Barker > > You nailed it! I've used the conda activate command many times. > It should in theory be possible in Python > > @Chris Angelico > > Yes mere shell commands passing via Py does not work, >

[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching

Hello, On Sun, 3 Jan 2021 16:50:33 + Paul Moore wrote: > On Sun, 3 Jan 2021 at 16:26, Barry Scott > wrote: > > I read the above and believe I know what it meant without needing > > to read the PEP in detail. I like that a lot. > > Personally, I read it and was horribly confused. I

[Python-Dev] Re: Thoughts on PEP 634 (Structural Pattern Matching)

Hello, On Sun, 27 Dec 2020 14:10:59 +0100 Dave Halter wrote: > I'm late, but I still wanted to add that I share some of the criticism > that Mark has brought up. > > I'm in love with Rust's pattern matching, so I feel like I'm not > against pattern matching generally. However I feel like while

[Python-Dev] Re: Story behind vars() vs .__dict__

Hello, On Tue, 22 Dec 2020 01:10:17 +1300 Greg Ewing wrote: > 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

[Python-Dev] Story behind vars() vs .__dict__

Hello, I would easily bet 10 bucks that vars() is the least known, and least used, of the Python builtin functions. My mental model of it was: it was introduced (perhaps in Python3) to "harmonize" all the existing .__dict__ stuff, and provide more abstract interface for it, with .__dict__

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, On Fri, 4 Dec 2020 15:52:01 -0800 Guido van Rossum wrote: > I hope more of the regulars here jump on this bandwagon. It will be a > great day when Paul posts one of his offensive posts and there is > just deafening silence. And I maintain my hopes where they always were - that there

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, On Mon, 30 Nov 2020 14:45:26 +0900 "Stephen J. Turnbull" wrote: > Paul Sokolovsky writes: > > > Also to clarify, [cowboy attitude] referred to difference in > > approaches in response to particular issue(s) raised. One thing is > > to say

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, On Mon, 30 Nov 2020 01:54:53 +0900 "Stephen J. Turnbull" wrote: > Paul Sokolovsky writes: > > > Well, I'd call that "cowboy attitude in programming language > > design" ;-). > > That was uncalled for, especially since you're selling an id

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, On Sun, 29 Nov 2020 11:36:45 +1100 Steven D'Aprano wrote: > On Sun, Nov 29, 2020 at 12:10:39AM +0300, Paul Sokolovsky wrote: > > > And we don't speak about some obscure "innovative" idea. Const'ness > > aka immutability is well-known and widely used feature

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, On Mon, 16 Nov 2020 12:21:35 +1300 Greg Ewing wrote: [] > > 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

[Python-Dev] constants in Python: Starting simple and gradually adding more features, was: Re: Pattern Matching controversy

Hello, On Mon, 16 Nov 2020 08:39:30 +1100 Steven D'Aprano wrote: [] > > The baseline of my version is much simpler: > > > > # This makes "const" a kind of hard keyword for this module > > from __future__ import const > > > > FOO: const = 1 # obviously, this is constant > Oh, well, To

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, On Sun, 15 Nov 2020 16:58:09 + MRAB wrote: [] > >> Pattern matching is complimentary to the object-oriented > >> paradigm. > > > That looks like a mistake to me; it should be "complementary". This way or that, my point is that even the word "orthogonal" wouldn't give it

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

ead the academic > paper.  Since its focus is somewhat complementary to the PEPs, it > might highlight some ideas behind our design that might not be made > clear enough in the PEPs.  But while doing so, please keep in mind > that the paper is a vision of a bigger picture and as suc

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, On Sun, 15 Nov 2020 22:05:46 +1100 Steven D'Aprano wrote: > On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote: > > > Just to give one example, literally at the very beginning, at the > > "Pattern Matching and OO" section (3rd heading) it sa

[Python-Dev] Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Hello, As was mentioned many times on the list, PEP634-PEP636 are thoroughly prepared and good materials, many thanks to their authors. PEP635 "Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/) stands out among the 3 however: while reading it, chances that you'll get a feeling

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Sun, 15 Nov 2020 00:22:01 -0500 Kyle Stanley wrote: [] > FWIW, I'd like to add my +1 to usage of "as" for spelling class > capture patterns. If you want to use "as" in spelling of class capture patterns, you don't need to worry about anything, because PEP634 already allows that:

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Fri, 13 Nov 2020 18:45:55 - "Brandt Bucher" wrote: > Paul Sokolovsky wrote: > > Use punctuation ("sigils") to mark as-binding terms. This choice > > still seems to be under-considered. (As in: it doesn't seem like > > many people, includ

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

Hello, On Thu, 12 Nov 2020 19:38:38 -0400 David Mertz wrote: [] > One idea that I cannot recall seeing, but that seems to make sense to > me and fit with Python's feel is using a WORD to distinguish between a > variable value and a binding target. That is, instead of a special > case

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Fri, 13 Nov 2020 21:51:49 +1100 Steven D'Aprano wrote: > > match foo: > > case ("foo", >val1): > > ... > > case ("bar", >val2): > > ... > > > 1. Much more intuitive for beginners. (If Python adopts it, I see > > other "user-friendly" languages adopting the

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Thu, 12 Nov 2020 12:51:19 -0800 Guido van Rossum wrote: > I have a meta-observation. Clearly there are too many cooks here. The > same suggestions keep getting brought up. We will never converge on a > design this way. Right, it's not a Python decision unless it's forced thru like

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Thu, 12 Nov 2020 20:19:13 + MRAB wrote: [] > > Question of "what to mark with sigils - terms-used-as-values or > > terms-used-for-capturing" is orthogonal to the question of "what to > > use as match-all symbol", though I understand the desire to > > repurpose the same symbol for

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, [Re-routed back to python-dev.] On Thu, 12 Nov 2020 20:04:57 +0100 Piotr Duda wrote: [] > > match foo: > > case ("foo", >val1): > > ... > > case ("bar", >val2): > > ... > > > > I agree with that, though I would prefer using other symbol than > (? > or $), one

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Thu, 12 Nov 2020 09:55:10 -0800 Guido van Rossum wrote: > The position of PEP 622/634/535/636 authors is clear: we see this as a > necessary feature to support using enums (e.g. Color.RED) or constants > defined in other modules (e.g. re.I) when simple switch functionality > is being

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Hello, On Tue, 3 Nov 2020 10:30:22 +0100 Federico Salerno wrote: > Re: symbol for lookup > > Whatever happened to the proposal of using . as prefix? I guess, the same that happened with the proposals to use "+" as a prefix, or proposals to change sides and use "->"

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

Hello, On Sat, 31 Oct 2020 18:53:57 +1000 Nick Coghlan wrote: > On Sat, 31 Oct 2020 at 18:20, Paul Sokolovsky > wrote: > > I blame it on my Saturday's hazy mind, but also for the interest of > > other readers, could you elaborate on "`==` interacts poorly with > >

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Hello, On Sat, 31 Oct 2020 12:16:09 + Paul Moore wrote: > On Sat, 31 Oct 2020 at 11:25, Steven D'Aprano > wrote: > > > > Thank you for the well-written PEP, although I don't agree with it. > > My response below is quite long. Here is my opinionated TL;DR: > > For what it's worth, I find

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

Hello, On Sat, 31 Oct 2020 18:01:16 +1000 Nick Coghlan wrote: > On Sat, 31 Oct 2020 at 17:49, Paul Sokolovsky > wrote: > > Alternatively, can add "inline guard sigils" for the most common > > guard conditions, which would be equality, period: > > &g

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

Hello, On Sat, 31 Oct 2020 02:37:14 +0100 Tin Tvrtković wrote: [] > async def ws_proxy(client: WebSocket): > await client.accept() > async with ClientSession() as session: > async with session.ws_connect("wss://echo.websocket.org") as > s: c =

[Python-Dev] Re: PEP 640: Unused variable syntax.

Hello, On Tue, 20 Oct 2020 00:00:49 +0200 Thomas Wouters wrote: > One of the problems I have with the Pattern Matching proposal (PEP 622 > originally, now PEPs 634, 635, 636) is the special-casing of '_' to > not actually assign to the name, which is a subtle but meaningful > divergence from

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

Hello, On Sat, 11 Jul 2020 22:49:09 +1200 Greg Ewing wrote: [] > For the most part, Python indentation follows what people > would naturally do even if they didn't have to. So I think it's > worth looking at what people typically do in other languages > that don't have mandatory indentation. >

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

Hello, On Sat, 11 Jul 2020 00:35:39 +0200 Federico Salerno wrote: [] > A few emails ago I proposed something like this (and I'm probably > only the last one to do so amongst many), but if anyone made an > argument against it I must have missed it: The PEP itself in "rejected" ideas makes an

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

Hello, On Wed, 8 Jul 2020 13:15:19 -0400 David Mertz wrote: > On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky > > > Right. So, if someone would like to add something to this thread, > > I'd humbly suggest to concentrate on the lack of, and need for, of > > const-ness in

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

Hello, On Wed, 8 Jul 2020 12:37:05 -0400 David Mertz wrote: > On Wed, Jul 8, 2020, 12:22 PM Paul Sokolovsky > > > popular VHLL/scripting languages which doesn't support defining of > > constants in the core language: > > > > JavaScript has "const foo = 1;&quo

[Python-Dev] Re: Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

Hello, On Thu, 9 Jul 2020 01:22:48 +1000 Steven D'Aprano wrote: > Whenever someone says "Python is the only language..." it really Yeah, the original message in this sub-thread was https://mail.python.org/archives/list/python-dev@python.org/message/YPP2TWYONFL4BOR3MJHGTHWSPMQNP7J7/ , and

[Python-Dev] Python is the only language with lack of const'ness in core, also affects: Re: PEP 622: Structural Pattern Matching

Hello, On Wed, 08 Jul 2020 12:45:09 +1200 Greg Ewing wrote: > 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 &

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

Hello, On Tue, 7 Jul 2020 17:22:28 +0100 Henk-Jaap Wagenaar wrote: [] > > >> I don't like the .name syntax (grit on Tim's monitor; does [] > "PEP 622: Ditch leading dots for name loads": this is now an > ex-syntax, it is bereft of life (for this, draft, of the PEP, might > come back

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

Hello, On Mon, 29 Jun 2020 06:21:36 -0700 Nathaniel Smith wrote: > On Mon, Jun 29, 2020 at 5:04 AM Paul Sokolovsky > wrote: > > > > Hello, > > > > On Mon, 29 Jun 2020 14:35:08 +0300 > > "Jim F.Hilliard" wrote: > > > > &g

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

Hello, On Mon, 29 Jun 2020 14:35:08 +0300 "Jim F.Hilliard" wrote: > I believe I'm not the only one with this question but, how is Strunk & > White connected with white supremacy? I wouldn't be surprised if the only connection between them is the word "white". > > Scanning through this

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

Hello, Shouldn't such feedback be also cross-posted to the python-dev mailing list? Also note the original pull request, https://github.com/python/peps/pull/1470, and differences of what was written in the pull request description and what went in the commit message. On Sun, 28 Jun 2020

[Python-Dev] Re: Virtual machine bleeds into generator implementation?

Hello, On Sun, 26 Apr 2020 19:51:18 -0700 Skip Montanaro wrote: [] > I think it's worse that this though, as it seems that in gen_send_ex() > it actually pushes a value onto the stack. That can't be solved by > simply adding a state attribute to the generator object struct. At the higher

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

Hello, On Tue, 24 Mar 2020 22:51:55 +0100 Victor Stinner wrote: > > === config.something === > > # If you'd like to remove some prefix from your lines, set it here > > REMOVE_PREFIX = "" > > == > > > > === src.py === > > ... > > line = line.cutprefix(config.REMOVE_PREFIX) > > ... > > ==

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

Hello, On Tue, 24 Mar 2020 19:14:16 +0100 Victor Stinner wrote: [] > The behavior of tuple containing an empty string is a little bit > surprising. > > cutsuffix("Hello World", ("", " World")) returns "Hello World", > whereas cutsuffix("Hello World", (" World", "")) returns "Hello". > >

[Python-Dev] [ANN] "compiler" package resurrected

Hello, I'm sorry for posting here and not to python-announce, somehow I think (perhaps naively) that it may be of interest to people who are interested in Python development. At the very least, creation of the original package is (very likely, I didn't trace up to that) was discussed on

Re: [Python-Dev] Add more SyntaxWarnings?

Hello, On Tue, 29 Jan 2019 18:55:37 + MRAB wrote: [] > > https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python > > > I have a vague recollection that a certain computer system (Amiga?) > had a 'why' command. If it reported

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

Hello, On Mon, 7 Jan 2019 01:14:55 +1100 Steven D'Aprano wrote: [] > > Thanks, that summarizes it well. And well, my interest is also how > > non-compliant would be for another Python implementation to act > > differently, specifically to skip wrapping an except handler body in > > try-finally

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

Hello, On Sun, 6 Jan 2019 17:26:09 +0200 Serhiy Storchaka wrote: [] > Because there is a reason for such code. > > See issue1631942 [1] and the thread with the subject "self-contained > exceptions" on the Python-3000 mailing list [2] for the rationale. > > In short, the code > > try:

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

Hello, On Sun, 6 Jan 2019 23:10:24 +1100 Steven D'Aprano wrote: [] > > # Where's my *global* variable? > > # Worse, my variable can be gone or not, depending on whether > > exception # triggered or not. > > print(e) > > That's not "worse", that's BETTER. > > With e deleted, you get an

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

Hello, On Sun, 6 Jan 2019 22:19:39 +1100 Chris Angelico wrote: > > It's clear that what happens there is that first None is stored to > > N, just to del it as the next step. Indeed, that's what done in the > > compile.c: > > > >

[Python-Dev] Compilation of "except FooExc as var" adds useless store

Hello, As explained in https://docs.python.org/3/reference/compound_stmts.html#the-try-statement , except E as N: foo is actually compiled as: except E as N: try: foo finally: del N But looking at the generated bytecode, it's worse than that: 16

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

Hello, On Sat, 13 Jan 2018 19:18:41 +0100 Christian Heimes wrote: [] > >> Nowadays Python has venv in the standard library. The user-specific > >> site-packages directory is no longer that useful. I would even say > >> it's causing more trouble than it's worth. For

Re: [Python-Dev] Using async/await in place of yield expression

Hello, On Mon, 27 Nov 2017 15:33:51 +1000 Caleb Hattingh wrote: [] > The PEP only says that __await__ must return an iterator, but it > turns out that it's also required that that iterator > should not return any intermediate values. This requirement is only >

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Tue, 7 Nov 2017 14:40:07 +0900 INADA Naoki wrote: > I agree with Raymond. dict ordered by default makes better developer > experience. > > So, my concern is how "language spec" is important for minor (sorry > about my bad vocabulary) implementation? > What's

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Tue, 7 Nov 2017 17:33:03 +1100 Steven D'Aprano <st...@pearwood.info> wrote: > On Mon, Nov 06, 2017 at 06:35:48PM +0200, Paul Sokolovsky wrote: > > > For MicroPython, it would lead to quite an overhead to make > > dictionary items be in insertion order. As

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Hello, On Mon, 6 Nov 2017 11:33:10 -0800 Barry Warsaw wrote: [] > If we did make the change, it’s possible we would need a way to > explicit say that order is not preserved. That seems a little weird I recently was working on a more or less complex dataflow propagation

  1   2   3   >