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
groun
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 diff
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 figure
y PoV, a solution which doesn't add particular complex behavior
into the language core, but allows to plug it in, and keep whole thing
more explicit, is something that "works better".
Again, I wanted to mention that point, as between the initial PEP
version and the latest one, I don&#x
nctionality in
PEP654, because again, it tries to codify rather complex and "magic"
behavior. 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 m
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 iss
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 "..
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):
> >>
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
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 (most
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 th
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 t
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
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 chec
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. Th
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 annotat
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 P
" 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:
> >
ing 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).
>
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
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’s i
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__"?
> &
yet, and 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
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.
> This
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 w
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.
>
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 sai
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
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
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
&
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
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 compiler:
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
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 pa
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
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 nai
ccepted annotations 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
> > C
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 positional-only
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 con
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
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
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
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
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" as port}
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 wro
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,
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,
> mayb
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 worked
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
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
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__ patient
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 will
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 "it
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 sel
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 widel
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 an
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 star
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 fairnes
alternative approaches
(as Brandt mentioned, there were such), and try to look into those
alternatives again.
Thanks!
>
> Of course, we encourage anyone interested in it to read the academic
> paper. Since its focus is somewhat complementary to the PEPs, it
> might highlight some
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)
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
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:
ca
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, i
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 value
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 sa
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 PEP
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
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
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 m
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
"->"
(https://mail.python.org/ar
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
>
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
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
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 = starlette_websocket_iterator(clien
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 the
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.
>
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 ar
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-nes
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
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 start
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
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 late
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:
> >
> > >
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 thread,
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 22:10:14
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 level
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)
> > ...
> > ==
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".
>
> cutpr
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 python-dev
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 a
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
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:
>
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 immed
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:
> >
> > https://github.com/python/cpython/blob/master/Python/compile.c#L290
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 STORE_
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 example it's common
> >> for
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
> enforced in the event loop, not
>
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 difference between "Micro
Hello,
On Tue, 7 Nov 2017 17:33:03 +1100
Steven D'Aprano 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 I mentioned, MicroPython
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
problem. It should conv
1 - 100 of 208 matches
Mail list logo
