Yep, fine with me too.
-Barry
> On Nov 13, 2023, at 02:17, Marc-Andre Lemburg wrote:
>
> Hello everyone,
>
> for quite a while now, core discussions have moved to Discourse and people
> are obviously enjoying things there:
>
> https://discuss.python.org/c/core-dev/23
>
> The Discourse
I heard it on reasonably believable authority that the FLUFL took the year off.
Lamentable.
-Barry
> On Apr 1, 2023, at 11:19, Skip Montanaro wrote:
>
> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or
ull
> wrote:
>
> Barry Warsaw writes:
>> I absolutely love not having to slog through hundreds of emails
>> before my first shots of caffeine, and I can now pull from
>> Discourse or GH when it’s convenient for me. It’s also much easier
>> to disengage for a few days a
On Dec 7, 2022, at 02:57, Petr Viktorin wrote:
>
> I'd like to point out that the SC decision was *reactive*, after most
> discussions moved to Discourse without SC pushing.
>
> I liked the list myself! But as soon as most of the posts were mandatory PEP
> and release notices, it stopped
Oh, I see, thanks. This is for the email interface, not the web interface.
-Barry
> On Sep 27, 2022, at 13:49, Cameron Simpson wrote:
>
> On 27Sep2022 11:14, Barry Warsaw wrote:
>>> Threading on the Python Discourse should now be working correctly. This is
>>&
> Threading on the Python Discourse should now be working correctly. This is
> the good work of Martin Brennan: https://meta.discourse.org/u/martin
I’m not sure what “working correctly” means. Do you have some examples on
discuss.python.org where threading is used? Is this something that
On Sep 20, 2022, at 02:47, Petr Viktorin wrote:
>
> Note that you can have development-related discussions anywhere, as long as
> you (eventually) include all relevant people. You're welcome to continue
> using python-dev and other mailing lists, IRC, in-person sprints, etc. But
> for
To me, that’s the biggest negative of Discourse, and I definitely prefer
threaded discussions. Unfortunately though, much like top posting , I
think that horse is out of the barn, what with other forums like GitHub being
linear.
-Barry
On Jul 15, 2022, at 11:59, Ethan Furman wrote:
>
> How
This might seem odd coming from me, but I’ve come around to supporting this
move. Discourse is not without its issues, but then again, the same can be
said about email. Without going into too much of my own personal preferences,
I agree that the experiment has proven successful enough that
On Apr 25, 2022, at 22:32, Larry Hastings wrote:
> The general shape of it is the same. First, we have some sort of forward
> declaration of the class. I'm going to spell it like this:
>
> forward class C
>
> just for clarity in the discussion. Note that this spelling is also viable:
>
>
On Apr 11, 2022, at 13:10, Guido van Rossum wrote:
>
> On Mon, Apr 11, 2022 at 1:07 PM Itamar O wrote:
> Breaking out the discussion about lazy imports.
> It seems somewhat OT in the declarative imports thread.
>
> Yes and Yes (at least for the "thinking about" part).
> Germán Méndez Bravo
Thanks Carl,
> On Apr 9, 2022, at 08:25, Carl Meyer wrote:
>
> Our experience in practice, though, has been that universally lazy
> imports is somewhat easier to adopt than Strict Modules, and has had a
> much bigger overall impact on reducing startup time for big CLIs (and
> a big web server
Start up overhead due to imports is a real problem for some class of
applications, e.g. CLIs, and I’ve seen a lot of hacks implemented to get Python
CLIs to be more responsive. E.g. getting from invocation to —help output is a
major UX problem.
It’s often more complicated than just imports
On Mar 26, 2022, at 17:48, Itay Yeshaya wrote:
>
> When running unittest with the -v flag, if a test has errors, and has a
> docstring, the test name is shown on one line, and the docstring is shown on
> the next line with the `ERROR` word.
This has been a long-standing nuisance, but I’m like
On Mar 27, 2022, at 11:52, Dan Stromberg wrote:
>
> It might make sense to have CPython's release cadence decoupled from the
> Standard Library's release cadence. That is, maybe they should be separate
> downloads.
While I don’t underestimate the work and complexity, we can do both. I.e.
As PEP-Delegate, I’m very happy to accept PEP 676 (PEP Infrastructure Process).
https://www.python.org/dev/peps/pep-0676/
https://discuss.python.org/t/request-for-comment-making-pep-rendering-self-contained/10774/98
Congratulations to Adam Turner and everyone who participated in the
On Jan 28, 2022, at 09:00, Steve Dower wrote:
>
> Does HPy have any clear guidance or assistance for their users to keep it up
> to date?
>
> I'm concerned that if we simply substitute "support the C API for everyone"
> with "support the C API for every version of HPy" we're no better off.
This looks great Adam, +1
One thing I’m pining for is a dark mode theme to PEPs. I know that’s outside
the scope of this PEP, but if you’re building a custom theme anyway, maybe you
can consider it.
Whether in this PEP or not, the design and implementation of the new system
should be fully
The advantage to users of keeping the languages the same is that readers of
your code don’t have to learn two disparate syntaxes to make sense of what
they’re reading. One of Python’s enduring strengths has been its readability.
In many ways, type annotations challenge that, but the trade-off
This is actually a topic the 2021 SC discussed at length and at the time we
decided that the typing language should follow the execution language. It was
buried in the call type syntax thread so it’s was probably easy to miss:
On Dec 23, 2021, at 17:09, Guido van Rossum wrote:
>
> Mark's proposal was
> ```
> @Callable
> def func(params): pass
> ```
> My question is, why does it need `@Callable`? Lukasz proposed just using any
> (undecorated) function, with the convention being that the body is `...` (to
> which I
On Dec 20, 2021, at 12:22, Guido van Rossum wrote:
> What do you think about -hh (and maybe —help-full) printing full help?
>
> Is there enough of a use case for this to bother?
Maybe not. I’d say if it was easy to implement, why not, but if it’s a pain,
don't bother.
-Barry
signature.asc
On Dec 20, 2021, at 11:34, Guido van Rossum wrote:
>
> Fair enough. Quick design proposal:
>
> -h and --help print info about flags (existing flags)
> --help-env (or --env-help?) prints info about env vars (new flag)
> -X help prints info about -X options (new -X option)
>
> Two lines
On Nov 29, 2021, at 15:57, Larry Hastings wrote:
>
> On 11/29/21 2:56 PM, Barry Warsaw wrote:
>> PEP 563 and 649 have visible effects that even within that domain can have
>> important side effects. For example, PEP 563’s loss of local scope, which
>> even “de-stri
I hope my understanding of where the SC’s debate about this currently sits
isn’t a misrepresentation, but since I sent the email on behalf of the SC, let
me try to clarify what I was trying to say.
Aside: A little insight into how the SC works. For communications like this,
after whatever
On Nov 26, 2021, at 01:13, Paul Moore wrote:
> I'd therefore interpret Barry's plea as being for *anyone* with a use
> for annotations to provide their feedback (at least, anyone who
> accepts that annotations are types), with particular emphasis on
> people who want to use the types declared in
I also agree with this analysis. I’ll just add that any discussion about
optimization needs to also show some data, for let’s say both contrived
examples (like this one IMHO) and as real-world examples as possible.
Sometimes “obvious” optimizations fool you and things actually get slower. Or
Hello Ethan,
The Steering Council has been discussing PEP 663 (Improving and Standardizing
Enum str(), repr(), and format() behaviors), for the last few weeks. We want
to thank you for your work on this PEP and your continued work on enums in the
standard library.
Upon further consideration,
Does PEP 563 or 649 satisfy static and dynamic typing needs?
In the interest of full transparency, we want to let the Python community know
that the Steering Council continues to discuss PEP 563 (Postponed Evaluation of
Annotations) and PEP 649 (Deferred Evaluation Of Annotations Using
Hello Mark, Matthew, Pradeep, Vincent, and Guido,
The Python Steering Council discussed the latest version of PEP 646 (Variadic
Generics) at our last meeting, and have unanimously decided to accept the PEP.
Congratulations!
We want to specifically mention that we appreciate the way you called
Thank you Sam, this additional detail really helps me understand your proposal.
-Barry
> On Oct 11, 2021, at 12:06, Sam Gross wrote:
>
> I’m unclear what is actually retried. You use this note throughout the
> document, so I think it would help to clarify exactly what is retried and why
>
Congrats on this impressive work Sam. I enjoyed the thorough write up of the
design. There’s one aspect that I don’t quite understand. Maybe I missed the
explanation. For example:
```
• Load the address of the item
• Increment the reference count of the item, if it is
On Oct 8, 2021, at 13:02, Sergei Lebedev wrote:
>
> I agree that type annotation syntax should be consistent with the rest of the
> language, but I'm curious why it has to be "standard Python syntax"? Could
> you elaborate a bit more on the reasoning behind that constraint?
Hi Sergei. I
Thanks for thinking more deeply about how we can make type annotations for
callables more user friendly.
The intersection between the syntax for general Python code and type
annotations has been a topic of discussion within the Steering Council (on and
off) for quite some time. We intend to
That might be exceptable.
-Barry
> On Oct 6, 2021, at 08:59, Brandt Bucher wrote:
>
> Łukasz Langa wrote:
>> Joking aside, since we allow any expression after 'except' 'group' then this
>> is indeed ambiguous. In theory!
>
> Another option (to remove the ambiguity) could be to move the
What do the PEP authors think about `except group`? Bikeshedding aside, that’s
still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and
can’t be confused with unpacking syntax.
-Barry
> On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev
> wrote:
>
> I agree
What do the PEP authors think about `except group`? Bikeshedding aside, that’s
still the best alternative I’ve seen. It’s unambiguous, self-descriptive, and
can’t be confused with unpacking syntax.
-Barry
> On Oct 5, 2021, at 11:15, sascha.schlemmer--- via Python-Dev
> wrote:
>
> I agree
On Oct 3, 2021, at 10:42, Łukasz Langa wrote:
>
> My idea is this:
>
> try:
>...
> except group E as e:
>...
> except group E1, T2 as e:
>...
>
> Should be doable given the magical match-case contextual keywords precedent.
> This looks nice and is explicit, since you will always
A couple of questions.
If you’re planning a runtime -X option, then does that mean that the modules
will be frozen at build time but Python will decide at runtime whether to use
the frozen modules or the unfrozen ones?
Are you planning on including the currently frozen importlib modules in
On Sep 21, 2021, at 15:03, Terry Reedy wrote:
>
> If same-quote nesting were limited to 1 deep, REs could handle it. Since
> nesting is not, and same-quote nesting would not be, they cannot in general.
>
> f'''length is {len(3*f"{f'{a}'}")}'''
I tried this in the latest python-mode.el for
There is some discussion going on in bpo-45155 about what the default value of
the `byteorder` argument should be for int.to_bytes() and int.from_bytes():
https://bugs.python.org/issue45155
I’ve created a short Discourse poll if you’d like to weigh in.
Adding default arguments to int.to_bytes() is both useful on its own merits and
kind of too easy *not* to do, so...
https://bugs.python.org/issue45155
https://github.com/python/cpython/pull/28265
-Barry
> On Sep 9, 2021, at 12:12, Barry Warsaw wrote:
>
> Signed PGP part
> On
On Sep 9, 2021, at 10:56, Ethan Furman wrote:
>
> On 9/9/21 9:37 AM, Barry Warsaw wrote:
>
> > While I think int.to_bytes() is pretty obscure (I knew about it, forgot
> > about it, and learned
> > about it again!) I’m not so sure it’s any less obscure than a
While I think int.to_bytes() is pretty obscure (I knew about it, forgot about
it, and learned about it again!) I’m not so sure it’s any less obscure than a
proposed bytes.fromint().
So why don’t we just relax int.to_bytes()’s signature to include natural
default values:
On Sep 9, 2021, at 08:53, Christopher Barker wrote:
>
> I fully admit serious bikeshedding here, but:
I think you meant “byte-shedding” :D
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list --
I’m finally getting back around to this thread. I’d like to see some
resolution to the bchr/fromint question, since it seems like that’s the last
thing holding up approval of the PEP. And the PEP has other useful additions
that I’d like to see in Python 3.11.
On Aug 22, 2021, at 16:08, Guido
On Aug 26, 2021, at 12:05, Brett Cannon wrote:
>
> I wouldn't be opposed to that personally. I think a lot of people just think
> PEP 8 is a doc for the community when it is actually for Python itself and it
> happens to be very convenient for others to use. Although we obviously
> understand
On Aug 9, 2021, at 08:27, Eric V. Smith wrote:
>
> My understanding is that PEP 649 is currently in front of the SC. But do we
> need to have any additional discussion here? My recollection is that we
> backed out the PEP 563 change because we didn't feel we had enough time to
> come to a
On Aug 4, 2021, at 07:31, Victor Stinner wrote:
>
> On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman wrote:
>> I would rather keep `bchr` and lose the `.fromint()` methods.
>
> I would prefer to only have a bytes.byte(65) method, no bchr()
> built-in function. I would prefer to keep builtins
Thanks for responding Ethan.
> On Aug 3, 2021, at 10:48, Ethan Furman wrote:
>
> I would rather keep `bchr` and lose the `.fromint()` methods.
>
> To get bytes:
>
> some_var = bchr(65)
> vs
> some_var = bytes.fromint(65)
>
> and for bytearrays
>
> some_var = bytearray(bchr(65))
> vs
>
Thanks Nick. Ethan, what do you think?
-Barry
> On Jul 29, 2021, at 16:28, Nick Coghlan wrote:
>
>
>
> On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote:
>
> Hello Nick, Ethan,
>
> The Python Steering Council reviewed PEP 467 -- Minor API improvements for
>
Hello Nick, Ethan,
The Python Steering Council reviewed PEP 467 -- Minor API improvements for
binary sequences at our 2021-07-26 meeting.
Thank you for work on this PEP. We’re generally very favorable for adding to
Python 3.11 the features and APIs described in the PEP. We have some
On Jul 29, 2021, at 05:55, Steve Dower wrote:
>
> Maybe we should have a "Type" other than Standards Track for PEPs that are
> documenting implementation designs, rather than requirements for
> standardisation?
Wouldn’t Informational fill that need?
-Barry
signature.asc
Description:
As specifically to the flaws in our workflow and the backlog, this is exactly
what the Developer-in-Residence program was designed to address:
https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-developer-in.html
Stay tuned!
-Barry
> On Jun 29, 2021, at 09:56, Joannah Nanjekye wrote:
>
>
The Steering Council discussed this topic at our meeting yesterday. We have
some discomfort about the changes to Enum’s str and repr in Python 3.10, both
in the specific changes and in the way the changes were decided on. No knock
on Ethan or others who participated in those decisions, it’s
On Jun 29, 2021, at 08:27, Mark Shannon wrote:
>
> I was expected the announcement of a BDFL delegate for PEP 657, as the author
> is a steering council member.
PEP Delegates are not required, even when the PEP author is an SC member.
-Barry
signature.asc
Description: Message signed with
I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in
Tracebacks) has been unanimously accepted for Python 3.11 by the Python
Steering Council.
Congratulations Pablo, Batuhan, and Ammar!
Cheers,
-Barry (on behalf of the Steering Council)
signature.asc
Description:
On Jun 23, 2021, at 16:34, Miro Hrončok wrote:
> Yes, we have a way to check all Fedora's Python packages by reusing our
> Python 3.10 pre-releases test-rebuild-everything mechanism, but it takes a
> few days to finish the builds and analyze the failures. Test failures caused
> by
to better match the current migration plan.
>
> I will check with Ezio and the gh-migration group on the status.
>
> Thanks.
>
> On Wed, Jun 23, 2021 at 10:33 AM Barry Warsaw wrote:
>
>
> Mariatta is the author of PEP 588 and I’m the delegate. Given how old that
&
Miro, what tests (outside of Python itself) do you think may break, and do you
have a way to check that?
-Barry
On Wed, Jun 23, 2021, at 17:15, Miro Hrončok wrote:
> On 23. 06. 21 23:49, Irit Katriel via Python-Dev wrote:
> >
> > Barry and I are working on a patch to add deprecation warnings
On Jun 23, 2021, at 03:21, Paul Moore wrote:
> PEP 588 has not been accepted, so it's not necessarily relevant to the
> actual migration plan here, but I do think it's reasonable to ask for
> some clarification. Either PEP 588 should be rejectected, noting that
> the actual implementation plan
On Jun 22, 2021, at 15:52, Brett Cannon wrote:
>
> One thing I will remind people is I personally have led the work to move this
> project from:
> • SourceForge to our own infrastructure
> • Mercurial to git
> • Our own infrastructure to GitHub for code management
> So if
I think it makes sense, and I do see a difference between Provisional and
Unstable. Is this anything more than a documentation label?
-Barry
> On Jun 3, 2021, at 13:10, Guido van Rossum wrote:
>
> This is not a complete thought yet, but it occurred to me that while we have
> deprecated APIs
On May 14, 2021, at 02:38, Chris Angelico wrote:
>
> Do we ever really need the ability to pass a specific sentinel to a
> function, or are we actually looking for a way to say "and don't pass
> this argument”?
Very often, that’s the case. Such a “it’s okay to not pass this argument”
On Apr 30, 2021, at 04:11, Antoine Pitrou wrote:
>
> On Thu, 29 Apr 2021 21:52:14 -0700
> Larry Hastings wrote:
>> D'oh! I have a second draft already.
>>
>>Your NEWS entry should be written in the /present tense,/ and should
>>start with a verb:
>>
>> * Add foo [...]
>> *
Hi Mario,
The Python Steering Council today decided that we will defer consideration of
PEP 648 to Python 3.11. On March 30, 2021 we sent the following feedback to
you via python-dev, which began a discussion thread:
Hi Carl,
> I think the first question to answer is, are the current mypy docs
> (https://mypy.readthedocs.io/en/stable/) insufficient for this purpose, and
> why?
There’s certainly lots of great documentation in the mypy docs; it’s often my
first go-to.
> They do include both tutorial-style
On Apr 15, 2021, at 17:49, Luciano Ramalho wrote:
> Anyone who uses a language with support for static typing expects the
> language distribution to include a type checker. Since that may be
> beyond our means, then the least we could do is have some official
> guidance on the matter, maybe in
On Apr 15, 2021, at 17:47, Oscar Benjamin wrote:
>
> Would it be problematic to postpone making __future__.annotations the default?
This is a good question, and I think the SC would really like to know if
anybody has objections to postponing this to 3.11. We haven’t discussed it
yet (this
On Apr 15, 2021, at 09:54, Antoine Pitrou wrote:
>
> On Thu, 15 Apr 2021 09:38:41 -0700
> Barry Warsaw wrote:
>> On Apr 14, 2021, at 23:11, Christopher Barker wrote:
>>>
>>> You wrote the original PEP, so of course you can withdraw it (or reject
>>&
On Apr 14, 2021, at 23:11, Christopher Barker wrote:
>
> You wrote the original PEP, so of course you can withdraw it (or reject it),
> but...
>
> Are you sure? See this discussion, I don't think it's as simple as all that.
From a library maintainers point of view, I personally want to get
On Apr 13, 2021, at 22:40, Christopher Barker wrote:
>
> Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago!
>
> https://www.python.org/dev/peps/pep-0396/
I’d forgotten that this PEP was in Deferred state. I think it should be
rejected and I plan on making that
On Apr 13, 2021, at 16:35, Rob Cliffe via Python-Dev
wrote:
> (Gasps in horror.) I can only hope I've misunderstood this sentence. Has it
> ever been even tentatively suggested that type hinting become mandatory?
> (What would that even mean: that the type of every function parameter or
>
On Apr 13, 2021, at 14:55, Luciano Ramalho wrote:
>
> Hugh was unfortunate in presenting the problem, but I agree that we
> should commit all the way to supporting type hints, and that means
> bundling a type checker as part of the standard library and
> distribution.
I wouldn’t necessarily be
On Apr 13, 2021, at 12:52, Serhiy Storchaka wrote:
>
> New example was found recently (see https://bugs.python.org/issue43833).
>
[0x1for x in (1,2)]
> [31]
>
> It is parsed as [0x1f or x in (1,2)] instead of [0x1 for x in (1,2)].
That’s a wonderfully terrible example! Who’s maintaining
On Apr 7, 2021, at 12:59, Guido van Rossum wrote:
>
> Note that in TypeScript this also doesn't look like a boolean -- it uses a
> unique syntax that has to be learned:
>
> function isCustomer(partner: any): partner is Customer {
> . . .
> }
>
> Arguably the TS syntax is more easily
The Python Steering Council reviewed PEP 647 -- User-Defined Type Guards, and
is happy to accept the PEP for Python 3.10. Congratulations Eric!
We have one concern about the semantics of the PEP however. In a sense, the
PEP subverts the meaning of the return type defined in the signature of
ndo Salgado
>
> On Wed, 31 Mar 2021 at 00:34, Nick Coghlan wrote:
>
>
> On Wed, 31 Mar 2021, 3:15 am Barry Warsaw, wrote:
> . We would like to eventually go farther, including deprecation of pth files
> entirely, but that is outside the scope of this PEP.
>
> Pleas
Great points Christian, thanks.
-Barry
> On Mar 30, 2021, at 10:59, Christian Heimes wrote:
>
> On 30/03/2021 19.01, Barry Warsaw wrote:
>> Hello Mario,
>>
>> Thank you for your submission of PEP 648 (Extensible customizations of the
>> interpreter at start
Hello Mario,
Thank you for your submission of PEP 648 (Extensible customizations of the
interpreter at startup). The Python Steering Council has reviewed the PEP and
before we can pronounce on it, we have some additional questions and comments
we’d like you to address. Once these questions
I think this is really the crux of the rejection: is the new syntax being
proposed primarily to support typing, or Python in general? Does it help both,
or is one use case the motivating factor, and the other is just piggybacking on
the syntactic proposal? Quoting from the rejection email:
>
The Steering Council unanimously believes this is the right thing to do.
Fortunately GitHub makes it very easy from their side. We push a button and it
makes the change for the repo and all PRs. Then when you visit the repo page
in GH, it tells you exactly what commands to run to make the
Thanks for this detailed PEP and analysis, and for the interesting discussion
in your separate thread. I’m glad to see this work that we chatted about all
that time before has coalesced into a PEP.
FYI: For those with write access to the PEPs repo, PEP number assignments are
self-serve. Just
On Nov 16, 2020, at 11:51, Paul Ganssle wrote:
>
> Not to put words in Barry's mouth, but I took Barry's comment to be more an
> answer to the question of how to contact "distro packagers" as a group, more
> than he was taking a position about this particular issue.
Correct!
Cheers,
-Barry
That’s what I was going to suggest. I’m not doing any Debian or Ubuntu work
these days, but Matthias Klose should be watching both lists, and should be
able to handle the Debuntu stack.
-Barry
> On Nov 16, 2020, at 07:45, Miro Hrončok wrote:
>
> On 11/16/20 4:10 PM, Paul Ganssle wrote:
>>>
I don’t have much to add to this thread, except to ask whether Mark has been in
contact with Carl Shapiro. Carl’s posted here before, but I don’t think he’s
an active mailing list participant. Carl has a lot of experience with VMs and
has been doing interesting work on performant Python
Seems fine to me. It’s an easy process; just ask postmaster@ and they can shut
the list down, retaining the archives read-only for posterity.
-Barry
> On Oct 13, 2020, at 09:26, Eric V. Smith wrote:
>
> Would anyone care if Import-SIG was shut down? It gets a few spam emails per
> day that
They say being a Python Release Manager is a thankless job, so the Python
Secret Underground (PSU), which emphatically does not exist, hereby officially
doesn’t thank Larry for his years of diligent service as the Python 3.4 and 3.5
release manager.
On the other hand, the Python Steering
Linking to a PEP for the historical record is fine, but let’s please make it
clear that the PEP is both not the documentation for any feature, and may
indeed be out of date. PEPs are deliberately not updated as features evolve.
Cheers,
-Barry
> On Sep 14, 2020, at 09:38, David Antonini
PEP 622 is already on the SC’s agenda for review.
-Barry
> On Aug 5, 2020, at 09:47, Ethan Furman wrote:
>
> On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:
>
>> The debate is still going on as to whether "capture" variables should be
>> marked...
> I don't think the PEP authors are
On Jul 11, 2020, at 13:28, MRAB wrote:
> Another possibility is:
>
>match:
>...
>case ...:
>case ...:
It’s ugly, but you could introduce and require a (soft) keyword on the line
after match, e.g.
match:
# Can’t really use `with` here although I think it reads better.
ents made on this thread. Thank you, and I look
forward to the updated PEP.
> On Tue, Jun 23, 2020 at 12:07 PM Barry Warsaw wrote:
> Couldn’t you adopt a flat indentation scheme with the minor change of moving
> the expression into a `match:` clause? E.g.
>
> match:
On Jun 23, 2020, at 23:25, Emily Bowman wrote:
> I wonder if it's time to officially designate _ as a reserved name.
That would break the i18n use case.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing
On Jun 23, 2020, at 14:34, Richard Levasseur wrote:
> I agree with not having flat indentation. I think having "case" indented from
> "match" makes it more readable overall.
I don’t know whether my suggestion to use `match:` and putting the expression
inside this stanza can be accomplished,
On Jun 23, 2020, at 13:50, Ethan Furman wrote:
>
> On 06/23/2020 12:49 PM, Barry Warsaw wrote:
>
>> Maybe the PEP could support this syntax:
>> case in 401, 403, 404:
>> That seems like it would be both unambiguous and semantically obvious.
>
On Jun 23, 2020, at 14:31, Chris Angelico wrote:
> I can't find it among the rejected alternatives, but was it considered
> to use "..." as the wildcard, rather than "_"? It carries similar
> meaning but its special case of "this will never be bound" is simply
> preventing an error, rather than
On Jun 23, 2020, at 12:27, Rob Cliffe via Python-Dev
wrote:
>
> On 23/06/2020 17:01, Guido van Rossum wrote:
>>
>> You can combine several literals in a single pattern using `|` ("or"):
>>
>> ```py
>> case 401|403|404:
>> return "Not allowed"
> The PEP is great, but this
On Jun 23, 2020, at 09:01, Guido van Rossum wrote:
> I'm happy to present a new PEP for the python-dev community to review. This
> is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin.
Congratulations to the authors. This is a well written, complex PEP for a
powerful
On Jun 12, 2020, at 04:21, Eric Wieser wrote:
> It seems to me there are at least three stances that could be taken here:
>
> * Specifying both is considered invalid: python should consider emitting a
> warning in `Type_READY` if both are filled.
> * Specifying both is considered an
In light of the release of Python 3.9b1, let’s take a moment to celebrate all
the great work that our Python 3.8 and 3.9 release manager Łukasz has done.
The role of Python Release Manager is hugely important to each successful
release, and it can be a lot of work, often unseen and thankless
1 - 100 of 2552 matches
Mail list logo
