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

[Steve Dower]

On 6/3/2021 7:42 PM, Senthil Kumaran wrote:

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


While we were investigating the reliably broken behaviour, we figured 
that related behaviour was *unreliably* broken on all platforms.


Specifically, if you imported a module through a relative path (resolved 
to CWD), changed the CWD, cleared the module cache, and reimported, you 
would still get the original module, contrary to the intent of getting 
the newly resolved module. ("Correct" code would have also cleared the 
import path caches, not just sys.modules.) This was because the module 
info was cached using the relative path, and so would be used later even 
though its absolute path had changed.


Someone reported this change in 3.8 and we decided to revert it in 
existing released, because the bugfix was for an obscure enough 
situation that it really wasn't worth breaking any existing versions. 
For unreleased versions, it's better to fix it so that imports will be 
more reliable in the future.


Based on Robin's original post, it looks like this is exactly the 
scenario we wanted to fix, and it's probably exposed an underlying issue 
in that test suite.


Unfortunately, import caching has changed a lot since Python 2.7, so 
it's very unlikely that one approach will be able to do reliable 
reloading across all of those versions. Your best bet since 3.3 is to 
use the importlib module's methods (but your *best* bet overall is to 
run separate test suites in their own process so you can avoid the CWD 
changes).


Cheers,
Steve
___
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/RDIMZA2KVWZSYUVLWQUZT4TE5BH6QWOV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-05-28 - 2021-06-04)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7426 ( +2)
  closed 48623 (+49)
  total  56049 (+51)

Open issues with patches: 2940 


Issues opened (29)
==

#43921: test_ssl: test_wrong_cert_tls13() and test_pha_required_nocert
https://bugs.python.org/issue43921  reopened by christian.heimes

#44264: Add descriptive error message when environment variable not de
https://bugs.python.org/issue44264  opened by astrosticks

#44266: AttributeError: module 'sys' has no attribute 'original_stdout
https://bugs.python.org/issue44266  opened by chinmay.malvania

#44268: gettext: deprecate selecting plural form by fractional numbers
https://bugs.python.org/issue44268  opened by serhiy.storchaka

#44269: smtplib AUTH command doesn't handle EAI arguments
https://bugs.python.org/issue44269  opened by jrlevine

#44271: asyncio random crash with longtime run
https://bugs.python.org/issue44271  opened by twbt4f

#44275: Is there a mojibake problem rendering interactive help in the 
https://bugs.python.org/issue44275  opened by jessevsilverman

#44276: Replace if-elif-else structure with match-case (PEP634)
https://bugs.python.org/issue44276  opened by Kshitiz17

#44279: doc: contextlib.suppress documentation is imprecise
https://bugs.python.org/issue44279  opened by iritkatriel

#44283: Add jump table for certain safe match-case statements
https://bugs.python.org/issue44283  opened by Dennis Sweeney

#44287: test_asyncio: test_popen() failed on AMD64 Windows8.1 Refleaks
https://bugs.python.org/issue44287  opened by vstinner

#44288: unittest: _is_relevant_tb_level() fails because tb.tb_frame.f_
https://bugs.python.org/issue44288  opened by vstinner

#44289: tarfile.is_tarfile() modifies file object's current position
https://bugs.python.org/issue44289  opened by mateja.and

#44291: Unify logging.handlers.SysLogHandler behavior with SocketHandl
https://bugs.python.org/issue44291  opened by cybergrind

#44292: contextmanager + ExitStack.pop_all()
https://bugs.python.org/issue44292  opened by lucae.mattiello

#44293: PEP 585 breaks inspect.isclass
https://bugs.python.org/issue44293  opened by joperez

#44295: self.assertDictContainsSubset warning is unhelpful
https://bugs.python.org/issue44295  opened by Anthony Sottile

#44296: Should warnings.warn default to stacklevel=2?
https://bugs.python.org/issue44296  opened by Anthony Sottile

#44297: Frame with -1 line number
https://bugs.python.org/issue44297  opened by vstinner

#44299: Enable control over daemon flag in ThreadPoolExecutor and Proc
https://bugs.python.org/issue44299  opened by dkropachev

#44301: Is there a way to provide destructor for module written using 
https://bugs.python.org/issue44301  opened by lycantropos

#44302: compile fail when make install run pip install as sudo
https://bugs.python.org/issue44302  opened by Battant

#44304: segmentation fault appeared in python 3.10.0b2
https://bugs.python.org/issue44304  opened by zzzeek

#44306: asyncio.from_thread
https://bugs.python.org/issue44306  opened by graingert

#44307: date.today() is 2x slower than datetime.now().date()
https://bugs.python.org/issue44307  opened by Anthony Sottile

#44309: Add support for yescrypt in crypt.
https://bugs.python.org/issue44309  opened by besser82

#44310: lru_cache memory leak
https://bugs.python.org/issue44310  opened by Wouter De Borger2

#44312: test_asyncio leaked [1533, 1531, 1533] references, sum=4597
https://bugs.python.org/issue44312  opened by pablogsal

#44313: Generate LOAD_ATTR+CALL_FUNCTION instead of LOAD_METHOD+CALL_M
https://bugs.python.org/issue44313  opened by BTaskaya



Most recent 15 issues with no replies (15)
==

#44309: Add support for yescrypt in crypt.
https://bugs.python.org/issue44309

#44307: date.today() is 2x slower than datetime.now().date()
https://bugs.python.org/issue44307

#44302: compile fail when make install run pip install as sudo
https://bugs.python.org/issue44302

#44299: Enable control over daemon flag in ThreadPoolExecutor and Proc
https://bugs.python.org/issue44299

#44297: Frame with -1 line number
https://bugs.python.org/issue44297

#44296: Should warnings.warn default to stacklevel=2?
https://bugs.python.org/issue44296

#44295: self.assertDictContainsSubset warning is unhelpful
https://bugs.python.org/issue44295

#44292: contextmanager + ExitStack.pop_all()
https://bugs.python.org/issue44292

#44289: tarfile.is_tarfile() modifies file object's current position
https://bugs.python.org/issue44289

#44287: test_asyncio: test_popen() failed on AMD64 Windows8.1 Refleaks
https://bugs.python.org/issue44287

#44269: smtplib AUTH command doesn't handle EAI arguments
https://bugs.python.org/issue44269

#44264: Add descriptive error message when environment variable not de

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

[Victor Stinner]

On Fri, Jun 4, 2021 at 12:29 AM Guido van Rossum  wrote:
>> 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()?)

Hum, the C API is somehow off-topic, but let me reply anyway ;-)

As I explained in my PEP 620, the Python C API never had any design.
Things were only exposed because it was easy and technically possible,
and it was a convenient way to define a function in one file and uses
it from another file. But 30 years later, we identified that exposing
some things are causing troubles and we are trying to make the C API
more "abstract".

Exposing directly all structures is causing a lot of headaches at
every new Python 3.x release. Getter and setter functions can handle
structure changes, retrieve information from another structure, return
an error, etc. This abstractation is needed for users to not have to
update their code, and to CPython developers to be able to change
things.

If possible, I would prefer to make PyThreadState, PyCodeObject and
other structures opaque, and only go through getter and setter
functions ;-) PyCode_New() is another problem :-/ The PEP 570 first
changed it to add a new parameter. It broke Cython and other projects.
The change was reverted, and PyCode_NewWithPosOnlyArgs() was added.
The lesson is that it's possible to change PyCodeObject without
breaking PyCode_New() (which handles the "backward compatibility" for
you).

Victor
--
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/GQI2NKFXQ4LYJ2HVFBCHL3KPMQVD4HI4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Rittau]

Am 03.06.21 um 20:11 schrieb Gregory P. Smith:
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/ 


There is certainly value in having some stability guarantees, even in 
"unstable" APIs. For example, while it is expected that the ast module 
breaks with each new minor Python version (3.7, 3.8 etc.), it's still 
stable during each such version. This makes the ast module quite useful 
for lots of applications that work on Python source code and that are 
understood to need changes for each Python version anyway. Breaking the 
compatibility just for the sake of it would be counterproductive.


 - Sebastian

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

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

[Petr Viktorin]

On 04. 06. 21 10:25, Serhiy Storchaka wrote:

03.06.21 20:10, 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"?


There is already a way to specify the stable ABI (see
Doc/tools/extensions/c_annotations.py). But unfortunately this feature
is not is not used in the documentation. It needs just an amount of work
to do this, and nobody did this.


It is used, and I started the work :)
See e.g. 
https://docs.python.org/3.10/c-api/sequence.html#c.PySequence_Concat




After marking all stable ABI we can extend this feature to support
halftones: provisional API, unstable API for Cython, etc.


I don't think that's necessary for the C API; the three-tier structure 
we have now (see https://devguide.python.org/c-api/ ) is, IMO, sufficient.


I don't think it can be easily adapted for the Python API, though.
___
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/4QINROTO26H5USYKUSQLRY4XTZOSV2FS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

03.06.21 20:10, 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"?

There is already a way to specify the stable ABI (see
Doc/tools/extensions/c_annotations.py). But unfortunately this feature
is not is not used in the documentation. It needs just an amount of work
to do this, and nobody did this.

After marking all stable ABI we can extend this feature to support
halftones: provisional API, unstable API for Cython, etc.

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