On Tue, Mar 29, 2022 at 11:55 AM Brett Cannon wrote:
> You're right that is the fundamental problem. But for me this somewhat stems
> from the fact that we don't have a shared understanding of what the stdlib
> is, and so the stdlib is a bit unbounded in its size and scope. That leads
> to a s
[woops]
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@p
RANK
SLOBODNIK
NAME
STANISLAV
FRST NAME
SMOLEC
BINARY
15.03/1983
IDENTIFICATION NUMBER
830315/6081
ADDRESS
KUČIŠDORFSKÁ DOLINA
NUMBER HOME
6144/704
CITY
PEZINOK
COUNTRY
SLOVAKIA
ZIP CODES
90201
EUROPE
COMPANY 4KA SLOVAKIA
MY CALL NUMBER
+421949281444
COMPANY MICROSOFT
MY E-MAIL
stanisl
On Wed, Mar 30, 2022 at 12:42 PM Steve Holden wrote:
> Not defining the semantics of annotations was a brave move, but
> inevitably led to the situation where different use cases, all
> quite reasonable, would spring into being. Now they have, the development
> team has to decide a) which ones to
Not defining the semantics of annotations was a brave move, but
inevitably led to the situation where different use cases, all
quite reasonable, would spring into being. Now they have, the development
team has to decide a) which ones to sanction and b) which will be left out
in the cold.
I wish th
On Wed, 2022-03-30 at 17:51 +0200, Petr Viktorin wrote:
> On 30. 03. 22 17:42, Guido van Rossum wrote:
> > In the not so distant past I have proposed to introduce a new
> > category,
> > "Unstable APIs". These are public but are not guaranteed to be
> > backwards
> > compatible in feature release
On Wed, Mar 30, 2022, 12:02 PM Toshio Kuratomi wrote:
>
> As just one example, i found two interesting items in the discussion
> started by Skip about determining what modules don't have maintainers just
> downstream if this.
>
Age in snake years doesn't necessarily correlate well with one's des
I don't think such a guarantee (to not vary internal APIs from 3.x.y to
3.x.(y+1)) has ever before been made in writing, although in practice we've
been doing this (more so now than we were in the 2.x timeframe).
I think we should not lightly vary internal APIs between bugfix releases,
but at the
-- Forwarded message -
From: Sasha Kacanski
Date: Wed, Mar 30, 2022, 2:55 PM
Subject: Re: [Python-Dev] Re: Are "Batteries Included" still a Good Thing?
[was: It's now time to deprecate the stdlib urllib module]
To: Paul Moore
Cc: Christopher Barker , Ethan Furman <
et...@stoneleaf
On Wed, Mar 30, 2022 at 4:53 AM Barney Gale wrote:
> On Wed, 30 Mar 2022 at 12:20, Antoine Pitrou wrote:
>
>> On Wed, 30 Mar 2022 12:03:58 +0100
>> Steve Dower wrote:
>> > On 30Mar2022 1124, Barney Gale wrote:
>> > > I'd like to become a maintainer for the pathlib module, if possible.
>> I
>> >
On Tue, Mar 29, 2022, 10:55 AM Brett Cannon wrote:
>
>
> On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren
> wrote:
>
>>
>>
>> On 29 Mar 2022, at 00:34, Brett Cannon wrote:
>>
>>
>>
>> On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker
>> wrote:
>>
>>> On Mon, Mar 28, 2022 at 11:29 AM Paul Moor
Got it, thanks for the clarifications!
Tracking 3.x Python versions is fine. We already need to do that to support
things like new bytecodes, and PyTorch supports an explicit list of 3.x Python
versions with separate builds for each.
Tracking 3.x.y Python versions would be much more painful, a
On 3/30/2022 12:32 PM, Baptiste Carvello wrote:
Le 28/03/2022 à 18:44, Steve Dower a écrit :
I think to most people "batteries included" doesn't necessarily mean
"standard library," with all that implies. It just means "it came with
the first thing that I installed" (or alternatively, "at no add
> I personally would love for a typing.python.org or equivalent subsection
of docs.python.org to exist.
+1
There’s a wrinkle here, however. The type specs are Python, but how they
are used/interpreted is up to third party packages.
So it’s a bit tricky to know exactly what to document where.
I
As someone who maintains a debugger that uses private api’s, I’d like to see
some commitment to seeing them not change in micro releases such as 3.11.1 ->
3.11.2. Micro releases should be compatible with other micro releases of the
same major.minor release such as 3.11 so that an extension compi
On 3/30/2022 4:42 PM, Guido van Rossum wrote:
In the not so distant past I have proposed to introduce a new category,
"Unstable APIs". These are public but are not guaranteed to be backwards
compatible in feature releases (though I feel they should remain so in
bugfix releases).
Agreed. This
On 30. 03. 22 17:42, Guido van Rossum wrote:
In the not so distant past I have proposed to introduce a new category,
"Unstable APIs". These are public but are not guaranteed to be backwards
compatible in feature releases (though I feel they should remain so in
bugfix releases).
I'm not sure w
In the not so distant past I have proposed to introduce a new category,
"Unstable APIs". These are public but are not guaranteed to be backwards
compatible in feature releases (though I feel they should remain so in
bugfix releases).
I'm not sure whether those should have a leading underscore or n
The internal C API can be used on purpose. But there is no backward
compatibility warranty and it can change anytime. In practice, usually
it only changes in 3.x.0 releases. For example, these private C API
changed in Python 3.9 and Python 3.11 (see my first email in the other
PEP 523 thread).
To
On Wed, Mar 30, 2022 at 2:26 AM Steve Dower wrote:
> Right now, the API is allowed/expected to change between 3.x releases
> (which normally we don't allow without a deprecation period) but it
> still has to remain compatible within a single 3.x release. Making it
> fully internal *without adding
On Tue, 29 Mar 2022, 9:44 am Toshio Kuratomi, wrote:
> One thing about talking about "make urllib more like requests" that is
> different than any of the other libs, though, is that requests aims to be
> easier to use than anything else (which I note Chris Barker called out as
> why he wanted url
On Wed, 30 Mar 2022, 3:49 am Brett Cannon, wrote:
>
>
> On Mon, Mar 28, 2022 at 3:58 PM Luciano Ramalho
> wrote:
>
>>
>> Documenting the generic types in the standard library is a much
>> smaller task than turning the typing PEPs into specs. It seems like a
>> good next step on the way to better
On Wed, 30 Mar 2022 at 12:28, Steve Dower wrote:
>
> On 30Mar2022 1132, Baptiste Carvello wrote:
> > Le 28/03/2022 à 18:44, Steve Dower a écrit :
> >> I think to most people "batteries included" doesn't necessarily mean
> >> "standard library," with all that implies. It just means "it came with
>
On Wed, 30 Mar 2022 at 12:20, Antoine Pitrou wrote:
> On Wed, 30 Mar 2022 12:03:58 +0100
> Steve Dower wrote:
> > On 30Mar2022 1124, Barney Gale wrote:
> > > I'd like to become a maintainer for the pathlib module, if possible. I
> > > know the code and tests inside-out, and I've been wrestling t
On 30Mar2022 1132, Baptiste Carvello wrote:
Le 28/03/2022 à 18:44, Steve Dower a écrit :
I think to most people "batteries included" doesn't necessarily mean
"standard library," with all that implies. It just means "it came with
the first thing that I installed" (or alternatively, "at no additio
On Wed, 30 Mar 2022 12:03:58 +0100
Steve Dower wrote:
> On 30Mar2022 1124, Barney Gale wrote:
> > I'd like to become a maintainer for the pathlib module, if possible. I
> > know the code and tests inside-out, and I've been wrestling the
> > internals for past few Python releases. I check the bug
Le 28/03/2022 à 18:44, Steve Dower a écrit :
> I think to most people "batteries included" doesn't necessarily mean
> "standard library," with all that implies. It just means "it came with
> the first thing that I installed" (or alternatively, "at no additional
> charge").
A point I have not seen
On 30Mar2022 1124, Barney Gale wrote:
I'd like to become a maintainer for the pathlib module, if possible. I
know the code and tests inside-out, and I've been wrestling the
internals for past few Python releases. I check the bugs/PRs at least
every week and help wherever I can.
Antoine is sti
On Mon, 28 Mar 2022 at 20:37, Steve Dower wrote:
> email doesn't fix bugs; maintainers fix bugs. Please let us know
> *publicly* if you want to become the maintainer for a stdlib module and
> then we can support them, but if nobody is willing/able/ready to care
> for them it's irresponsible for u
29 matches
Mail list logo
