[Python-Dev] Re: name for new Enum decorator

[Chris Jerdonek]

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 a couple comments. First, are these checks going to run at import
time? The reason I ask is that, in cases where the enums aren't generated
dynamically, it seems like it could make sense for efficiency to have the
option of running them instead during tests. The decorator would still be
useful because it could tell the test harness what checks to run.

My other comment is whether this design would permit checks that take
arguments. For example, in the case of the "continuous" check, one might
want to be able to say, "this Flag enum should span the first N bits" as
opposed to using the highest occurring bit as the N. That way you can be
sure you didn't leave off any flags at the end.

--Chris



>
___
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@python.org/message/NDNMEHATHT6QHMT7IZLNGJ55TO525ZZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Robin Becker]

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.path is identical (modulo version name changes) 
and that os.getcwd() is as expected and that os.path.isfile('./%s.py' % modulename) is True.


In a7 exec('%s as m', NS) works, but in b1 I get ModuleNotFoundError.

I can fix the problem by changing

sys.path.insert(0,'.')

into

sys.path.insert(0,os.getcwd())

The behaviour of '.' in sys.path has always been slightly mysterious, but is this a real bug and have we just been lucky 
for 20 years?


I have placed some details here

https://www.reportlab.com/ftp/import-bug-310b1.txt

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.


I do know that during the tests the errant code is executed with different values for the target directory; the first 
usage seems to succeed.

--
Robin Becker
___
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@python.org/message/DE3MDGB2JGOJ3X4NWEGJS26BK6PJUPKW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New pythoncapi_compat project adding Python 3.10 support to your C extensions without losing Python 2.7-3.9 support

[Simon Cross]

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. It's a really good time to
try things out and give feedback. Once we start doing more official
releases, changing fundamental things about the HPy API will become
harder (or at least more work).
___
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@python.org/message/P6AQ5TMFGOQUDCTSWBBQJK3SJRCUIKOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Chris Johns]

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 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.path 
> is identical (modulo version name changes) and that os.getcwd() is as 
> expected and that os.path.isfile('./%s.py' % modulename) is True.
> 
> In a7 exec('%s as m', NS) works, but in b1 I get ModuleNotFoundError.
> 
> I can fix the problem by changing
> 
>sys.path.insert(0,'.')
> 
> into
> 
>sys.path.insert(0,os.getcwd())
> 
> The behaviour of '.' in sys.path has always been slightly mysterious, but is 
> this a real bug and have we just been lucky for 20 years?
> 
> I have placed some details here
> 
> https://www.reportlab.com/ftp/import-bug-310b1.txt
> 
> 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.
> 
> I do know that during the tests the errant code is executed with different 
> values for the target directory; the first usage seems to succeed.
> -- 
> Robin Becker
> ___
> 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@python.org/message/DE3MDGB2JGOJ3X4NWEGJS26BK6PJUPKW/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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@python.org/message/664GGOGFJZ3SQ7PWLA6BYP4A27TSFZ63/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Larry Hastings]

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 such a system, if not 
the current directory?



//arry/

___
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@python.org/message/LVOYZGSOJ3OGDX7OUTDXRQVXZ7YGGPS7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Bernat Gabor]

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 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 such a system, if not the
> current directory?
>
>
> */arry*
> ___
> 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@python.org/message/LVOYZGSOJ3OGDX7OUTDXRQVXZ7YGGPS7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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@python.org/message/DZRKL3Q7JHT2RQ3UW3E724VSPTWPCS4L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Senthil Kumaran]

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 sounds like an excellent candidate for git bisect to help
and figure out which exact commit caused this behavior change.

Was it possible for you to detect that?

Thank you,
Senthil
___
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@python.org/message/CW2SAOGIO5EIXU7GJZIN26MLF6AC2HD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Guido van Rossum]

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 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 sounds like an excellent candidate for git bisect to help
> and figure out which exact commit caused this behavior change.
>
> Was it possible for you to detect that?
>
> Thank you,
> Senthil
> ___
> 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@python.org/message/CW2SAOGIO5EIXU7GJZIN26MLF6AC2HD5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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@python.org/message/NV4E6CALNMWR7C2J2NE2QABKWXYRZTZN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Proposal: declare "unstable APIs"

[Guido van Rossum]

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 *unstable* APIs, which will continually change without ever going away
or stabilizing. Examples would be the ast module (since the AST structure
changes every time the grammar changes) and anything to do with code
objects and bytecode (since we sometimes think of better ways to execute
Python).

So maybe the docs should grow a standard way of saying "this is an unstable
API"?

Would we need a PEP to create an initial list of APIs (modules, classes,
etc.) that are considered unstable?

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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@python.org/message/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Senthil Kumaran]

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/04732ca993fa077a8b9640cc77fb2f152339585a
was supposed to a platform specific bug fix.

I didn't a sense that reportlab regression detected was platform
specific one.  The behavior change is an interesting one though.

More interesting thing for me was developers running large test suites
between alpha and beta releases, and reporting bugs! :-)

-- 
Senthil

___
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@python.org/message/GJWGQQGZNUWYIX3UX6T4H5VN7IE4YGN6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Senthil Kumaran]

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 (which
> everyone can rely on), it might be good to also have something like *unstable*
> APIs, which will continually change without ever going away or stabilizing.

The first grey area will between Provisional API vs Unstable API.

Do developers consider provisional APIs as stable and start relying upon
heavily? I am not sure. 

I also lack the experience for the use-cases that you are thinking
about.

-- 
Senthil
___
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@python.org/message/XOMDLGMXWFRBETG7FWI5PB2Y5YNGNXP3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Guido van Rossum]

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 think of it as a sort of extended beta period for that module only.
Generally provisional status only lasts for one release cycle.

"Unstable" has a different meaning -- it's for APIs (including modules)
that are likely to change in every release (or most releases, anyway).
Users are not discouraged from using these, but they *must* be mindful of
their code breaking with every new release.

I could imagine some unstability to allow incompatible changes in bugfix
releases, though for my main use case it would be sufficient to only allow
those in minor releases.

On Thu, Jun 3, 2021 at 10:32 AM Senthil Kumaran  wrote:

> 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
> (which
> > everyone can rely on), it might be good to also have something like
> *unstable*
> > APIs, which will continually change without ever going away or
> stabilizing.
>
> The first grey area will between Provisional API vs Unstable API.
>
> Do developers consider provisional APIs as stable and start relying upon
> heavily? I am not sure.
>
> I also lack the experience for the use-cases that you are thinking
> about.
>
> --
> Senthil
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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@python.org/message/ZUTAVE3S3QMWNIBGTBDOTJ7M62CTO57R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Robin Becker]

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/commit/04732ca993fa077a8b9640cc77fb2f152339585a
was supposed to a platform specific bug fix.

I didn't a sense that reportlab regression detected was platform
specific one.  The behavior change is an interesting one though.

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 past so perhaps there are problems from my incompetence.



More interesting thing for me was developers running large test suites
between alpha and beta releases, and reporting bugs! :-)

You guys can certainly develop language changes faster than us maintainers can use them; the dead hand of past usage is 
a real handicap.


I have managed a smaller example which breaks for me in arch linux latest.

The self contained code is here

https://www.reportlab.com/ftp/timport-310b1.py

I switched to using importlib.import_module as I think that can now always be 
used in the versions we support.

To generate a test base I used an empty directory and then run (in bash)

for d in A B;do rm -rf $d; mkdir $d;echo "print('+ in module %s' % __name__)" > $d/$(echo $d | tr [:upper:] 
[:lower:]).py; done



or
$  for d in A B;do
>rm -rf $d
>mkdir $d
>echo "print('+ in module %s' % __name__)" \
> > $d/$(echo $d | tr [:upper:] [:lower:]).py
> done

to create two simple modules in dirs A & B.

If I run python timport-310b1.py in 3.10.0a7 I occasionally see a problem, but in 3.10.0b1 or b2 I see the problem every 
time; the TB ends like this



print(recursiveImport(mn, debug=1))
  File "/home/robin/devel/reportlab/REPOS/timpbug/tests/timport-310b1.py", line 
36, in recursiveImport
return importlib.import_module(modulename)
  File 
"/home/robin/devel/reportlab/.py310/lib/python3.10/importlib/__init__.py", line 
126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'a'


The occasional problem with 3.10.0a7 make me think some random element is at 
work perhaps hashing stuff.
--
Robin Becker
___
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@python.org/message/UJKVOAR6BUDOIFRSUGQ3THFA2DYG47PQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Gregory P. Smith]

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
breaking manner.  With every release and potentially even within some patch
releases when the point really needs to be made.  Even when you didn't have
a reason to change anything.  If you don't do that, people are going to
find it convenient, discover stability, assume it exists, depend on it, and
complain about breakage no matter what was stated.
https://www.hyrumslaw.com/

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.

-gps

On Thu, Jun 3, 2021 at 10:46 AM Guido van Rossum  wrote:

> 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 think of it as a sort of extended beta period for that module only.
> Generally provisional status only lasts for one release cycle.
>
> "Unstable" has a different meaning -- it's for APIs (including modules)
> that are likely to change in every release (or most releases, anyway).
> Users are not discouraged from using these, but they *must* be mindful of
> their code breaking with every new release.
>
> I could imagine some unstability to allow incompatible changes in bugfix
> releases, though for my main use case it would be sufficient to only allow
> those in minor releases.
>
> On Thu, Jun 3, 2021 at 10:32 AM Senthil Kumaran 
> wrote:
>
>> 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
>> (which
>> > everyone can rely on), it might be good to also have something like
>> *unstable*
>> > APIs, which will continually change without ever going away or
>> stabilizing.
>>
>> The first grey area will between Provisional API vs Unstable API.
>>
>> Do developers consider provisional APIs as stable and start relying upon
>> heavily? I am not sure.
>>
>> I also lack the experience for the use-cases that you are thinking
>> about.
>>
>> --
>> Senthil
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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@python.org/message/ZUTAVE3S3QMWNIBGTBDOTJ7M62CTO57R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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@python.org/message/NCWBNN5AH4D26ECGL4DYRI2DKZBIKV6C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Senthil Kumaran]

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" specific. But interesting that it was observed in ARCH. The
non-windows piece of changes were probably responsible

> You guys can certainly develop language changes faster than us maintainers
> can use them; the dead hand of past usage is a real handicap.

I was thinking in terms of Bug-Fix (https://bugs.python.org/issue43105)
that is causing an interesting behavior change (still not certain to
call this a regression).

> I have managed a smaller example which breaks for me in arch linux latest.
> 
> The self contained code is here
> 
> https://www.reportlab.com/ftp/timport-310b1.py
> 
> I switched to using importlib.import_module as I think that can now always be 
> used in the versions we support.

Thanks for this report, Robin. 

I will reference this in the issue43105, which has probably has the
context to this.

-- 
Senthil
___
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@python.org/message/DGR6DEWZJRN5IDOZPC4LAHP5J3EIQ55X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Guido van Rossum]

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 introspecting Python
code. I think stable and public are orthogonal axes.
-- 
--Guido (mobile)
___
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@python.org/message/5VCIBESTW5MIK6XOFBUOULIHF6D6WC5D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Victor Stinner]

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 know that this API is
not supported nor stable.

I don't know if there would be a way to advertise that a Python API is
unstable. Some projects use an underscore prefix in their module names
to mark them as "private". For example, sub-modules of a package are
called "_something.py" and they exposed in package/__init__.py (or
another public module).

Victor

On Thu, Jun 3, 2021 at 7:14 PM 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 
> everyone can rely on), it might be good to also have something like 
> *unstable* APIs, which will continually change without ever going away or 
> stabilizing. Examples would be the ast module (since the AST structure 
> changes every time the grammar changes) and anything to do with code objects 
> and bytecode (since we sometimes think of better ways to execute Python).
>
> So maybe the docs should grow a standard way of saying "this is an unstable 
> API"?
>
> Would we need a PEP to create an initial list of APIs (modules, classes, 
> etc.) that are considered unstable?
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> ___
> 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@python.org/message/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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@python.org/message/KG4Z45UW7Y2EY5WMPZ6Z4763CJWUTXH3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Barry Warsaw]

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 (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 
> *unstable* APIs, which will continually change without ever going away or 
> stabilizing. Examples would be the ast module (since the AST structure 
> changes every time the grammar changes) and anything to do with code objects 
> and bytecode (since we sometimes think of better ways to execute Python).
> 
> So maybe the docs should grow a standard way of saying "this is an unstable 
> API"?
> 
> Would we need a PEP to create an initial list of APIs (modules, classes, 
> etc.) that are considered unstable?
> 
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> ___
> 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@python.org/message/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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@python.org/message/IKNRQSWBZMKQRACSZY6OOCSMJVZHFIY3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Chris Angelico]

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 deal, but it would mean you could ask
something to analyze your code (I hesitate to call it a type checker,
since this is nothing to do with data types, but the same kind of
tool) and it'd tell you whether your code is (a) portable to all OSes,
(b) portable to all Pythons, and (c) stable across versions.

BTW, does "unstable" cover things like dis.dis(), which have existed
and will continue to exist for many versions, but their output can
change? In one sense, dis.dis() always does the exact same thing: it
shows you the disassembly of a piece of code. In another sense, its
output changes drastically when things change.

ChrisA
___
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@python.org/message/MRNDNHVLQWX5HC3LETQVUT4XX2TKYKVW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Tim Delaney]

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 everyone can rely on), it might be good to also have something
> like *unstable* APIs, which will continually change without ever going away
> or stabilizing. Examples would be the ast module (since the AST structure
> changes every time the grammar changes) and anything to do with code
> objects and bytecode (since we sometimes think of better ways to execute
> Python).
>

Perhaps "living API" analogous to "living document". Much more positive
connotations ...

Tim Delaney
___
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@python.org/message/J5U7HG2D35P2IXZRIYTKLT7COXNBJKUR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Guido van Rossum]

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 usable directly on purpose. It's
> an user agreement: I know what I am doing, and I know that this API is
> not supported nor stable.
>

Hm, but aren't for example all the fields of code objects (co_name,
co_argcount, etc.) in the "non-internal" API? Those (and the functions that
manipulate code objects) are a prime example of what I'd consider
"unstable".

On https://docs.python.org/3/c-api/code.html it already says about the
fields "The fields of this type are subject to change at any time." But I
think everything else on that page should be considered unstable as well.
(And why do we even have PyCode_GetNumFree()?)


> I don't know if there would be a way to advertise that a Python API is
> unstable. Some projects use an underscore prefix in their module names
> to mark them as "private". For example, sub-modules of a package are
> called "_something.py" and they exposed in package/__init__.py (or
> another public module).
>

I was primarily thinking of the docs.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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@python.org/message/U3TMLYUPDWJAUKOMLS4BRMMNPOEHSQAT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Guido van Rossum]

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 exactly? And doesn't it follow that all APIs are living? If we stick
with unstable, we're adopting a term that's in use by at least one other
language community (Rust), and the slightly negative connotation is welcome
-- people should think twice before using unstable APIs.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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@python.org/message/ONR3CJAPNP5PZ6DBCKXKCXUPKSD7E5QY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Guido van Rossum]

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 static checkers could be taught
> to recognize them? Not a huge deal, but it would mean you could ask
> something to analyze your code (I hesitate to call it a type checker,
> since this is nothing to do with data types, but the same kind of
> tool) and it'd tell you whether your code is (a) portable to all OSes,
> (b) portable to all Pythons, and (c) stable across versions.
>

Yeah, this could easily be taken on by any of the many linters.


> BTW, does "unstable" cover things like dis.dis(), which have existed
> and will continue to exist for many versions, but their output can
> change? In one sense, dis.dis() always does the exact same thing: it
> shows you the disassembly of a piece of code. In another sense, its
> output changes drastically when things change.
>

That's debatable. I sure hope people aren't ever parsing dis output.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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@python.org/message/6YBZPGE7HLMV6DHOSQ4PKICADESPR7AM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Glenn Linderman]

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 would 
then have to explain. And since the opposite would be "dead API", what 
is a dead API exactly? And doesn't it follow that all APIs are living? 
If we stick with unstable, we're adopting a term that's in use by at 
least one other language community (Rust), and the slightly negative 
connotation is welcome -- people should think twice before using 
unstable APIs.


I read somewhere that the term "stable" means "dead" in some contexts... 
was it maybe a medical context?  So "living" would be "unstable" too, as 
Tim suggested.


And since people know what a living document is, a living API wouldn't 
be much of a stretch.


On the other hand, "unstable" carries a bit more connotation of "needs 
caution".
___
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@python.org/message/CS23XQX3356Q3S6WI66PISIT3NXEGMGM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Chris Angelico]

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 a documentation label?
>> >
>>
>> Would it be a pipe dream to hope that static checkers could be taught
>> to recognize them? Not a huge deal, but it would mean you could ask
>> something to analyze your code (I hesitate to call it a type checker,
>> since this is nothing to do with data types, but the same kind of
>> tool) and it'd tell you whether your code is (a) portable to all OSes,
>> (b) portable to all Pythons, and (c) stable across versions.
>
>
> Yeah, this could easily be taken on by any of the many linters.

Cool cool.

>> BTW, does "unstable" cover things like dis.dis(), which have existed
>> and will continue to exist for many versions, but their output can
>> change? In one sense, dis.dis() always does the exact same thing: it
>> shows you the disassembly of a piece of code. In another sense, its
>> output changes drastically when things change.
>
>
> That's debatable. I sure hope people aren't ever parsing dis output.
>

That's exactly what I mean. People shouldn't be parsing that output,
because it's human-readable. Does it count as an API change when the
human-readable output is giving different information?

Actually, I think I just talked myself out of this. The
sys.version_info tuple is going to change from one version to another
(obviously!), but it is, by definition, stable and dependable. So I
think no, it's not "unstable" based on human-readable output.

ChrisA
___
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@python.org/message/HDTPVRMBX7L5NPWFSDOHTO7UTISOUC6Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Cameron Simpson]

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 where it isn't, these 
>> assumptions tend to cause problems.
>>
>> That sounds miserable.  What does "." signify on such a system, if not the
>> current directory?
>
>The only other thing that would make sense is a folder in the current
>working directory named ".", not?

I can't speak for Chris Johns, and we're off topic for this thread.

That said, I dislike "." in sys.path, particularly near the front. In 
fact my own "invoke this module's main" wrapper scripts strip it out. I 
remain personally of the opinion that it is a security nightmare, making 
imports _subject_ to the current directory (which might be anywhere, 
include a directory owned by a hostile user). So i dislike it as a 
default.

I know Robin becker is testing specific behaviour - I don't oppose being 
_able_ to put "." in sys.path (though I think a concrete absolute path 
is a saner choice).

So for Bernat and Larry: not systems where "." doesn't mean the working 
directory, but definitely in situations where you want a more secure 
loading of modules (i.e. only from where I expect, not destabilised by a 
cd).

Cheers,
Cameron Simpson 
___
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@python.org/message/YMV4LUW5LYFKJYEIHVM5GTCC6POM6BYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Irit Katriel via Python-Dev]

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 6/3/2021 3:34 PM, Guido van Rossum wrote:
>> 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 
>> exactly? And doesn't it follow that all APIs are living? If we stick with 
>> unstable, we're adopting a term that's in use by at least one other language 
>> community (Rust), and the slightly negative connotation is welcome -- people 
>> should think twice before using unstable APIs.
> 
> I read somewhere that the term "stable" means "dead" in some contexts... was 
> it maybe a medical context?  So "living" would be "unstable" too, as Tim 
> suggested.
> 
> And since people know what a living document is, a living API wouldn't be 
> much of a stretch.
> 
> On the other hand, "unstable" carries a bit more connotation of "needs 
> caution".
> ___
> 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@python.org/message/CS23XQX3356Q3S6WI66PISIT3NXEGMGM/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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@python.org/message/NBODHC6YELGWHLBRHJCJPINPZT6OZD4F/
Code of Conduct: http://python.org/psf/codeofconduct/