Maybe ‘version-dependent’ api? It indicates why the api is unstable (as
opposed to something like test.support where the docs say ‘this is for us,
we’re not bothered about keeping it stable’).
In some contexts ‘unstable’ means buggy/unreliable.
> On 4 Jun 2021, at 00:20, Glenn Linderman wrote
On 03Jun2021 17:06, Bernat Gabor wrote:
>On Thu, Jun 3, 2021 at 5:05 PM Larry Hastings
>wrote:
>> On 6/3/21 4:20 AM, Chris Johns wrote:
>> Might be out of context here, but IMHO "." shouldn't be assumed to be
>> the current directory anyway.
>>
>> As someone who has ported python to a system wh
On Fri, Jun 4, 2021 at 8:31 AM Guido van Rossum wrote:
>
> On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote:
>>
>> On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote:
>> >
>> > I think it makes sense, and I do see a difference between Provisional and
>> > Unstable. Is this anything more than
On 6/3/2021 3:34 PM, Guido van Rossum wrote:
On Thu, Jun 3, 2021 at 3:17 PM Tim Delaney
mailto:timothy.c.dela...@gmail.com>> wrote:
Perhaps "living API" analogous to "living document". Much more
positive connotations ...
Perhaps, but that's pretty much coining a new term, which we wou
On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote:
> On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote:
> >
> > I think it makes sense, and I do see a difference between Provisional
> and Unstable. Is this anything more than a documentation label?
> >
>
> Would it be a pipe dream to hope that
On Thu, Jun 3, 2021 at 3:17 PM Tim Delaney
wrote:
> Perhaps "living API" analogous to "living document". Much more positive
> connotations ...
>
Perhaps, but that's pretty much coining a new term, which we would then
have to explain. And since the opposite would be "dead API", what is a dead
API
On Thu, Jun 3, 2021 at 1:33 PM Victor Stinner wrote:
> Hi Guido,
>
> It seems like you are talking about the Python API.
>
Primarily, yes.
In the C API, there is the internal C API which fits with your
> description. To access it, you have to declare the
> Py_BUILD_CORE_MODULE macro. It's not u
On Fri, 4 Jun 2021 at 03:13, Guido van Rossum wrote:
> This is not a complete thought yet, but it occurred to me that while we
> have deprecated APIs (which will eventually go away), and provisional APIs
> (which must mature a little before they're declared stable), and stable
> APIs (which every
On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote:
>
> I think it makes sense, and I do see a difference between Provisional and
> Unstable. Is this anything more than a documentation label?
>
Would it be a pipe dream to hope that static checkers could be taught
to recognize them? Not a huge de
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
Hi Guido,
It seems like you are talking about the Python API.
In the C API, there is the internal C API which fits with your
description. To access it, you have to declare the
Py_BUILD_CORE_MODULE macro. It's not usable directly on purpose. It's
an user agreement: I know what I am doing, and I kn
On Thu, Jun 3, 2021 at 11:11 Gregory P. Smith wrote:
> One obvious now in hindsight question: Why are any of these APIs even
> public? They all deserve underscore prefixed names to highlight their
> private-ness and potential instability.
>
Because they are still useful when manipulating or intr
On Thu, Jun 03, 2021 at 07:08:06PM +0100, Robin Becker wrote:
> The regression may well be a platform issue. I am by no means an expert at
> building python; I followed a recipe from the ARCH PKGBUILD of some time
I meant the change in the diff we were suspecting was supposed to be
"Windows" speci
Overall agreement. Your list of ast and code objects and bytecode
instructions are things that I'd _hope_ people already consider unstable so
declaring them as such just makes sense if we're not doing that already.
The ideal way to declare an API as unstable is to constantly change it in a
breakin
On 03/06/2021 18:14, Senthil Kumaran wrote:
On Thu, Jun 03, 2021 at 09:55:57AM -0700, Guido van Rossum wrote:
Maybe this?
04732ca993 bpo-43105: Importlib now resolves relative paths when creating
module spec objects from file locations (GH-25121)
Likely!. But
https://github.com/python/cpython
In practice, provisional APIs have been quite stable. The term
"provisional" was introduced for PEPs that introduce new modules, where we
wanted to allow some wiggle room for changes based on experience with using
the new module during the first release cycle where it's made available.
You can thin
On Thu, Jun 03, 2021 at 10:10:53AM -0700, Guido van Rossum wrote:
> This is not a complete thought yet, but it occurred to me that while we have
> deprecated APIs (which will eventually go away), and provisional APIs (which
> must mature a little before they're declared stable), and stable APIs (wh
On Thu, Jun 03, 2021 at 09:55:57AM -0700, Guido van Rossum wrote:
> Maybe this?
>
> 04732ca993 bpo-43105: Importlib now resolves relative paths when creating
> module spec objects from file locations (GH-25121)
Likely!. But
https://github.com/python/cpython/commit/04732ca993fa077a8b9640cc77fb2f15
This is not a complete thought yet, but it occurred to me that while we
have deprecated APIs (which will eventually go away), and provisional APIs
(which must mature a little before they're declared stable), and stable
APIs (which everyone can rely on), it might be good to also have something
like
Maybe this?
04732ca993 bpo-43105: Importlib now resolves relative paths when creating
module spec objects from file locations (GH-25121)
On Thu, Jun 3, 2021 at 9:49 AM Senthil Kumaran wrote:
> On 3 Jun 2021, at 09:31, Robin Becker wrote:
>
> > ReportLab has quite a large codebase and I think i
On 3 Jun 2021, at 09:31, Robin Becker wrote:
> ReportLab has quite a large codebase and I think it would be hard to
> get a concise test of this behaviour change. I would be glad if this
> is an expected change a7-->b1 and if the use of '.' in this way has
> become somehow wrong.
To me, this sou
The only other thing that would make sense is a folder in the current
working directory named ".", not?
On Thu, Jun 3, 2021 at 5:05 PM Larry Hastings wrote:
>
> On 6/3/21 4:20 AM, Chris Johns wrote:
>
> Might be out of context here, but IMHO "." shouldn't be assumed to be the
> current director
On 6/3/21 4:20 AM, Chris Johns wrote:
Might be out of context here, but IMHO "." shouldn't be assumed to be the
current directory anyway.
As someone who has ported python to a system where it isn't, these assumptions
tend to cause problems.
That sounds miserable. What does "." signify on
Might be out of context here, but IMHO "." shouldn't be assumed to be the
current directory anyway.
As someone who has ported python to a system where it isn't, these assumptions
tend to cause problems.
Cheers
Chris
Sent from my iPhone
> On 3 Jun 2021, at 09:31, Robin Becker wrote:
>
> I
On Thu, Jun 3, 2021 at 4:16 AM Victor Stinner wrote:
> I would say that HPy is not complete nor mature yet. IMO it's already
> worth it to start playing with it, try to convert your small C
> extensions, and send back your early feedback to HPy developers!
This is my view of the state of HPy too.
I have a failing test case in 3.10.0b1 for code that uses changes to sys.path and attempts to load unpackaged modules by
changing directory and placing '.' into sys.path; the code works as expected in 2.7.18, 3.6-3.10.0a7.
I printed out related variables in the a7 and b1 runs and find that sys.p
On Wed, Jun 2, 2021 at 8:04 PM Ethan Furman wrote:
>
> Thank you everyone for your ideas! Instead of adding another
> single-purpose decorator, I'm toying with the idea of
> adding a general purpose decorator that accepts instructions. Something
> along the lines of:
> ...
> Thoughts?
>
I had
27 matches
Mail list logo
