On Jan 30, 2019, at 14:32, Raymond Hettinger
wrote:
>
> Now that regular dicts are ordered and compact, it makes more sense for the
> _asdict() method to create a regular dict (as it did in its early days)
> rather than an OrderedDict. The regular dict is much smaller, much faster,
> and has
On Feb 3, 2019, at 13:03, Antoine Pitrou wrote:
>
> I'd like to ask for the reversion of the changes done in
> https://github.com/python/cpython/pull/11664
>
> The reason is simple: the PR isn't complete, it lacks docs and tests.
> It also didn't pass any review (this was pointed by Ronald), eve
On Feb 3, 2019, at 18:10, Raymond Hettinger wrote:
>
> FWIW, with dataclasses we decided to get the PR committed early, long before
> most of the tests and all of the docs. The principle was that bigger changes
> needed to go in as early as possible in the release cycle so that we could
> thor
On Feb 4, 2019, at 05:02, Stephane Wirtel wrote:
>
> Just one idea, we could create a Docker image with this alpha version.
>
> This Docker image could be used with the CI of the main projects and the
> test suites of these projects.
>
> If we have some issues, we should create an issue for pyt
On Feb 5, 2019, at 02:24, Stephane Wirtel wrote:
>
> I was not aware of this image. So it's true that it's very useful.
>
> Thank you very much,
You’re welcome! I just pushed an update to add 3.8.0a1 to the set of Python’s
(including git head). Do you think there’s a better way to publicize
On Feb 13, 2019, at 08:20, Victor Stinner wrote:
> I'm a (strong) supporter of providing a "python" command which would
> be the latest Python version!
I think we should aspire for this to be the case too, eventually. When this
has come up in the past, we’ve said that it’s not appropriate to c
On Feb 13, 2019, at 15:07, Victor Stinner wrote:
>
> Le mer. 13 févr. 2019 à 21:26, Barry Warsaw a écrit :
>> I don’t think this should be conflated with PEP 394. IMHO, 3.10 is just
>> fine. Python 4 should be reserved for some future mythical GIL-less
>> interp
On Feb 13, 2019, at 23:08, Matěj Cepl wrote:
> Is this relevant to the discussion at hand? We are talking about
> the binary /usr/bin/python3 which will be surely be provided
> even by Python 4, won't it?
Why would it be? Since this is all hypothetical anyway , I’d more likely
expect to only s
On Feb 16, 2019, at 09:25, Nick Coghlan wrote:
> While Matthias is still personally reluctant to add the alias for
> Debian/Ubuntu, the *only* thing preventing aliasing /usr/bin/python to
> /usr/bin/python3 right now on the Fedora & RHEL side of things is PEP
> 394, and Guido objected strongly wh
Steve Dower wrote on 2/16/19 14:34:>
This is mostly about being able to assign blame when things break, so
I'm totally okay with extension modules that want to play with internals
declaring Py_BUILD_CORE to get access to them (though I suspect that
won't work out of the box - maybe we should have
On Feb 21, 2019, at 06:53, Stephane Wirtel wrote:
>
> What do you think if we suggest a "template" for the new bugs?
>
> For example:
> * Python version (exact version)
> * Operating System * on Linux -> Distribution (python can have some patches)
> * Add a script for the reproduction of the bu
On Feb 21, 2019, at 10:34, Raymond Hettinger
wrote:
>
> I think that anything that raises the cost of filing a bug report will work
> to our detriment. Ideally, we want the barriers to reporting to be as low as
> possible.
`python -m reportbug` could make the process even easier (too easy?).
> There haven't been many new ideas since this summary – mostly it was
> explaining and re-hashing what's been mentioned before.
Thanks for the summary Petr.
Here’s another way to think about the problem. I know Nick and I have talked
about this before, but I don’t think any distros have actua
On Feb 26, 2019, at 13:34, Petr Viktorin wrote:
> I have two very different questions in mind for moving this forward.
>
> Who gets to decide on PEP 394 changes?
Honestly, I think it’s the active distro maintainers who need to make this
decision. They have the pulse of their own communities a
On Feb 26, 2019, at 14:04, Neil Schemenauer wrote:
>
> Interesting idea. I remember when I was helping develop Debian
> packaging guides for Python software. I had to fight with people
> to convince them that Debian packages should use
>
>#!/usr/bin/pythonX.Y
>
> rather than
>
>#!/u
On Feb 26, 2019, at 13:02, Raymond Hettinger
wrote:
> * I gave up on ordering right away. If we care about performance, keys can
> be stored in the order added; but no effort should be expended to maintain
> order if subsequent deletions occur. Likewise, to keep set-to-set operations
> effi
On Feb 27, 2019, at 13:54, Chris Barker via Python-Dev
wrote:
>
> A mapping and a set type really don't have much to do with each other other
> than implementation -- anyone that isn't familiar with python C code, or hash
> tables in general, wouldn't likely have any expectation of them having
On Mar 1, 2019, at 02:41, Petr Viktorin wrote:
> Currently, in RHEL/Fedora:
> - "sudo pip" installs to /usr/local/, RPM packages install to /usr/
> - with "-I", the interpreter does not look into /usr/local/.
> AFAIK, Debian/Ubuntu have something very similar, and were first to do it.
Debuntu’s
On Mar 6, 2019, at 10:28, Abdur-Rahmaan Janhangeer wrote:
>
> As a non core-dev, my enthusiasm for submitting a pep has been diminished by
> some 40%.
I’m sorry to hear that.
I think it’s worth keeping in mind that successfully navigating the PEP process
can be quite daunting an demoralizing
On Mar 7, 2019, at 14:36, Mariatta wrote:
> I was not involved in core Python development back then, so if it is really
> important and if people think such paragraph needs to be part of the PEP,
> then perhaps someone else more knowledgeable will need to help with this.
>
> Personally, I don'
On Mar 26, 2019, at 04:23, Stéphane Wirtel wrote:
>
> I have proposed a PR for the update of this docker image:
> quay.io/python-devs/ci-image
>
> I have also updated the versions to 3.4.10, 3.5.7, 3.7.3 and of course
> to Python 3.8.0a3.
>
> By the way, this image will contain the last version
Thanks for the update. I have made one small suggestion on the PR for
clarification, but otherwise the changes LGTM.
-Barry
> On Apr 12, 2019, at 07:53, Miro Hrončok wrote:
>
> Hello.
>
> Based on discussions in [1], Petr Viktorin and me have drafted a new update
> [2] to the PEP 394 (The "
On May 7, 2019, at 03:52, Steve Holden wrote:
>
> What's not to like?
My only complaint is that you steadfastly refuse use Guido’s time machine keys
to make this available in 3.7.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
P
On May 8, 2019, at 10:13, Petr Viktorin wrote:
>
> Not sure what the original intent was, but I read that as: "Whenever you get
> to sending your first post, include an introduction in it. But, before you
> start actively participating, take your time to hang around and absorb the
> culture."
As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of
the Steering Council, I hereby Accept this PEP.
We would like to thank Mariatta for championing PEP 581, and to all the
contributors to the discussion, both pro and con. We appreciate your candor
and respect for yo
On May 16, 2019, at 03:12, Victor Stinner wrote:
> I came to the UnraisableHookArgs structseq idea because of my bad
> experience with extension warnings "hooks". Let me tell you this story
> :-)
Thanks for that!
> def showwarning(message, category, filename, lineno, file=None, line=None):
> .
On May 20, 2019, at 13:15, Christian Heimes wrote:
>
> here is the first version of my PEP 594 to deprecate and eventually remove
> modules from the standard library. The PEP started last year with talk during
> the Python Language Summit 2018, https://lwn.net/Articles/755229/.
>
> The PEP can
On May 23, 2019, at 14:17, Brett Cannon wrote:
> I'm personally viewing it as a first step in addressing the maintenance
> burden we have with such a large stdlib. Christian started this work over a
> year ago and I think it's worth seeing through. After that we should probably
> have a discus
On May 31, 2019, at 01:22, Antoine Pitrou wrote:
> I second this.
>
> There are currently ~7000 bugs open on bugs.python.org. The Web UI
> makes a good job of actually being able to navigate through these bugs,
> search through them, etc.
>
> Did the Steering Council conduct a usability study
On Jun 5, 2019, at 02:08, Victor Stinner wrote:
>
> Our kind postmasters Mark Sapiro and Abhilash Raj migrated
> python-ideas and python-dev mailing lists from Mailman 2 to Mailman 3
> (running on Python 3 ;-))!
Gosh, it warms my heart. :)
Thank you Mark, Abhilash!
-Barry
signature.asc
Descr
On Jun 6, 2019, at 09:15, David Mertz wrote:
>
> The old URL is definitely a lot friendlier, even apart from the length.
Unfortunately, the old URLs aren’t really permanent. Hypermail calculated them
sequentially and if you rebuild the archive from the source-of-truth mbox
files, there’s no w
On Jun 6, 2019, at 23:50, Wes Turner wrote:
>
> Thanks for getting these upgraded. IMHO, being able to copy URLs from list
> message footers as references in e.g. issues will be a great boost in
> productivity.
Just FYI, these URLs are a “standard" we proposed many years ago, with
discussions
On Jun 28, 2019, at 09:56, Mariatta wrote:
>
> I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section.
>
> https://www.python.org/dev/peps/pep-0581/#downsides-of-github
Thanks Mariatta!
> I plan to update PEP 588 sometime this weekend or next, to incorporate the
> discussion
On Jul 8, 2019, at 12:27, Jonathan Goble wrote:
> So my inbox, and probably many of yours, was flooded this afternoon
> with a dozen-plus emails from the Python-Announce list. I understand
> that this list requires every email to be manually approved by a
> moderator.
I cleared the queue this mo
On Jul 8, 2019, at 12:56, Barry Warsaw wrote:
> Volunteers are welcome! :)
Wow, that was fast! Thanks for the offers for help. I’ll add everyone who’s
stepped up so far to the list moderators. Yes, you do get a notification every
day with a link right to the moderation page.
Che
I’ve updated the official images to include 3.8.0b2:
https://gitlab.com/python-devs/ci-images/tree/master
Cheers,
-Barry
> On Jul 4, 2019, at 15:05, Łukasz Langa wrote:
>
> Signed PGP part
> After a few days of delay, but somewhat cutely timed with the US Independence
> Day, I present you Pyt
On Jul 13, 2019, at 19:09, Raymond Hettinger
wrote:
>
> In some modules, we've been careful to use both __all__ and to use an
> underscore prefix to indicate private variables and helper functions
> (collections and random for example). IMO, when a module has shown that
> care, future mainta
On Jul 23, 2019, at 08:44, Steve Dower wrote:
> The @public decorator is basically:
>
> def public(fn):
>__all__.append(fn.__name__)
>return fn
>
> It's trivial, but it adds a runtime overhead that is also trivially avoided
> by putting the name in __all__ manually. And once it's publi
On Jul 23, 2019, at 09:20, Ethan Furman wrote:
>
> On 07/23/2019 08:44 AM, Steve Dower wrote:
>
>> The @public decorator is basically:
>> def public(fn):
>> __all__.append(fn.__name__)
>> return fn
>> It's trivial, but it adds a runtime overhead that is also trivially avoided
>> by putt
On Jul 23, 2019, at 12:02, Steve Dower wrote:
>
> Even if the performance impact is zero, commits that span the entire codebase
> for not-very-impactful changes have a negative impact on readability (for
> example, someone will suddenly become responsible for every single module as
> far as so
I have updated the official docker images with 3.8b3:
https://gitlab.com/python-devs/ci-images/tree/master
-Barry
> On Jul 29, 2019, at 14:48, Łukasz Langa wrote:
>
> Signed PGP part
> This time without delays, I present you Python 3.8.0b3:
>
> https://www.python.org/downloads/release/python-
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 implem
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:
>>> M
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
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
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 cha
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:
>
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 ar
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
Galindo 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.
>
>
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 th
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 intuit
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 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 o
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
> f
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 change
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 awa
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 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 wh
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 th
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 "
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:
https://mail.python.org/archives/list/python-dev@python.org/message/OGYZZZ4A5
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 [...]
>> * C
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”
construct
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 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 GitHu
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 is
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 in
etter 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
>
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 DeprecationWa
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: Messa
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 Op
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 ju
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:
>
> >
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: Messag
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 requests
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
>
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
> so
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 namespa
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 good
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
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 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 -- python-dev@pytho
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:
int.to_bytes(length
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
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 Sep
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.
https://discuss.python.org/t/what-should-b
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 Emac
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 that
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 ge
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 t
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 t
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 “group
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 pr
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 don’
I just updated PEP 361 (Python 2.6 release schedule).
Python 2.6 is in security maintenance, source only release mode. Official
support for Python 2.6 expires on October 1 2013, and I would like to do one
last release[1], i.e. 2.6.9 as close to that date as possible.
I know of issue 16248, but i
On Feb 21, 2013, at 10:38 AM, Nick Coghlan wrote:
>- make it possible to enable safer behaviour globally in at least 2.7
>and 3.3 (and perhaps in 2.6 and 3.2 security releases as well)
I want to be fairly conservative with 2.6.9.
-Barry
___
Python-Dev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Feb 20, 2013, at 11:35 PM, Tres Seaver wrote:
>I believe that the same rationale should apply as that for adding hash
>randomization in 2.6.8: this is at least as bad a vulnerability, with
>many more vectors of attack.
Except that I really want
On Feb 23, 2013, at 04:02 PM, Stefan Krah wrote:
>Hmm. I think this limits interoperation with C libraries and prototyping
>C code.
As for flufl.enums, it doesn't really, because while items are not ints they
are interoperable with ints.
>>> from flufl.enum import make
>>> Colors = make('Colors'
On Feb 23, 2013, at 04:02 PM, Stefan Krah wrote:
>> +Ordered comparisons between enumeration values are *not* supported. Enums
>> are +not integers!
>
>Hmm. I think this limits interoperation with C libraries and prototyping
>C code.
This is mostly a red-herring. flufl.enum values are C-level i
401 - 500 of 2704 matches
Mail list logo
