[Python-Dev] Re: PEP 678: Enriching Exceptions with Notes

[Gregory P. Smith]

On Thu, Jan 27, 2022 at 10:10 AM Zac Hatfield Dodds <
zac.hatfield.do...@gmail.com> wrote:

> Hi all,
>
> I've written PEP 678, proposing the addition of a __note__ attribute
> which can be used to enrich displayed exceptions.  This is particularly
> useful with ExceptionGroup, or where exception chaining is unsuitable, and
> ensures that 'orphan' output is not produced if the annotated exception is
> caught.
>
> Link to the PEP: https://www.python.org/dev/peps/pep-0678/
>
> *Please, redirect all discussions to:*
> https://discuss.python.org/t/pep-678-enriching-exceptions-with-notes/13374
>

FYI - The Steering Council reviewed your updates and is **Accepting** the
latest iteration of *PEP 678: Enriching Exceptions with Notes*. :grin:

A short and sweet reply, we don't have more to add.

-gps on behalf of the Python Steering Council
___
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/QFOWI4WOUOVPSERRYADQNZWJJTKTOR3A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 687 – Isolating modules in the standard library

[Nick Coghlan]

On Tue, 12 Apr 2022, 3:59 am Guido van Rossum,  wrote:

> In the sentence starting with
>
> Types whose methods need access to their module instance will be converted
> to heap types[...]
>
> please emphasize (bold!) "whose methods need access to their module
> instance".
>
> Also emphasize this paragraph:
>
> "Static types that do not need module state access, and have no other
> reason to be converted, should stay static."
>
> I hadn't noticed the qualification in the first sentence and had assumed
> all types were to be converted, until I came across the second at the very
> end of the section (where it is easily overlooked by lazy readers :-).
>


Making that final paragraph the first paragraph in the section should help
on both points (reminds me of flipping an if/else in code so the one-liner
branch is the first one).

Definite +1 from me on the overall PEP.

Cheers,
Nick.


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

[Python-Dev] Re: Lazy Imports [was: Declarative imports]

[Barry Warsaw]

On Apr 11, 2022, at 13:10, Guido van Rossum  wrote:
> 
> On Mon, Apr 11, 2022 at 1:07 PM Itamar O  wrote:
> Breaking out the discussion about lazy imports.
> It seems somewhat OT in the declarative imports thread.
> 
> Yes and Yes (at least for the "thinking about" part).
> Germán Méndez Bravo (Kronuz) will be drafting a PEP,
> and is leading work internally to port this from 3.8 (first
> to 3.10, then to the cpython main branch).
> We are planning to get started on this during PyCon sprints,
> it would be nice to connect in-person with anyone who's
> interested in this and happens to be in the sprints too!
> 
> I am and I will be.

Apologies for the icky quoting, but yay! It’s great to hear your intentions, 
and like Guido, I would like to connect on this at Pycon as well.

-Barry




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

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

[dfremont--- via Python-Dev]

Brett Cannon wrote:
> So we don't want to strengthen the definition at
> all; best we are comfortable with is put up a warning that you don't want
> to do stuff with sys.modules unless you know what you're doing.

OK, thanks for the clarification. Having read through the source of importlib 
one too many times, I guess I will declare that I "know what [I'm] doing" for 
now and keep on mutating sys.modules, since the alternative (intercepting all 
imports) seems more painful to me. If my code breaks in a future Python version 
I'll only blame myself :)

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

[Python-Dev] Re: Declarative imports

[Brett Cannon]

On Sun, Apr 10, 2022 at 2:39 AM Daniel Pope  wrote:

> On Fri, 8 Apr 2022, 17:44 Guido van Rossum,  wrote:
>
>> The interesting idea here seems to make "lazy imports" easier to
>> implement by making them explicit in the code. So far, most lazy import
>> frameworks for Python have done hacks with `__getattribute__` overrides.
>>
>
> The value is more than ease of implementation. Having syntax for import
> expressions makes them statically analysable, which is needed for type
> checkers and IDE autocompletion.
>
> But I also see value in being able to type out code that uses modules not
> yet imported without breaking my flow to add an import statement. I don't
> yet trust IDEs to do this because I've been bitten by them doing so
> incorrectly in the past.
>
> The key questions to me are
>> - What should the notation be?
>>
>
> I would like to bid again for (import package.module) as an expression.
> Instead of doing the import and assigning package to a variable package it
> would evaluate to the module object package.module.
>

That is an extremely subtle shift for what `import x.y` does compared to
`(import x.y)`. That requires a context switch of not only seeing `import`
in an expression context, but that the statement also acts differently in
terms of what is returned by the equivalent statement. I really don't to
try and teach that distinction to a newcomer. And I don't think the
ergonomics are great enough to warrant the context switch.

Plus you can do this today with imortlib.import_module(). Unless you're
suggesting the name also be bound in the scope it's run in? In which case
that's `(abc := importlib.import_module("collections.abc")).Mapping`.

-Brett


>
> The `as` form is not needed because no name is assigned and the `from`
> form isn't as valuable because you can just use attribute access afterwards.
>
> It isn't terse but it does make use of the import keyword and is thus
> instantly recognisable. It is even syntax highlighted correctly by much
> existing software. If we're using the import keyword then I think it has to
> look like this.
>
> But I concede that it isn't particularly elegant to type hint things with
>
> (import collections.abc).Mapping
>
> ...but not so inelegant that I couldn't see myself using it for a few
> one-off imports per module.
>
> A quirk is that it means there's a big difference between the statements
>
> import foo
>
> and
>
> (import foo)
>
> because one assigns a variable. I don't mind that; I don't think it is too
> ambiguous to a reader.
>
>
>
> ___
> 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/T6V7WZAFEXGWMHXLHS7XHYXI5OPMOZKA/
> 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/5HMNON4YODBJNHSSAYT4B7CRZJUKFGW4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

[Brett Cannon]

On Sat, Apr 9, 2022 at 1:53 PM dfremont--- via Python-Dev <
python-dev@python.org> wrote:

> Thanks, Brett. I understand why the behavior happens, I just don't
> understand the decision to implement imports this way. Since there's no
> warning in the documentation that removing items from sys.modules can break
> the fact that "import X.Y" defines "X.Y" (note that the "behind the
> curtain" stuff happens *before* the second import, so it's still the case
> that the second import does not define "X.Y" as implied by the docs), and
> there's also no warning that submodules must be removed at the same time as
> their parent, I would expect my example code to work.
>
> I don't see any downside to having "import X.Y" always set the Y attribute
> of X (instead of only setting it if 'X.Y' is not already in sys.modules),
> but if you think it's a bad idea, here's a suggestion for a paragraph to
> add at the end of PLR 5.4.2:
>
> "Note that the binding to the submodule object in the parent module's
> namespace is only added when the submodule is actually *loaded*. If the
> submodule is already present in `sys.modules` when it is imported (through
> any of the mechanisms above), then it will not be loaded again and no
> binding will be added to the parent module."
>

I don't want the import docs to be that detailed. As others have suggested,
something more about "directly mutating the contents of `sys.modules` may
have unexpected side-effects" is better.


>
> If removing a module but not its submodules from sys.modules is considered
> "cheating" and could potentially break other parts of the import system,
> that should also be documented, e.g. by adding the sentence "If you delete
> a key for a module in `sys.modules`, you must also delete the keys for all
> submodules of that module." at the end of the 3rd paragraph of PLR 5.3.1.
> However, I would much rather not impose this restriction, since it seems
> unnecessarily restrictive (indeed, my code violates it but works fine, and
> changing it to transitively remove all submodules would necessitate
> reloading many modules which do not actually need to be reloaded).
>
> (Terry, thanks for your suggestion. My concern about adding such a vague
> warning is that to me, it reads as saying that all bets are off if you
> modify sys.modules by hand, which means it would never be safe to do so,
> i.e., the behavior might change arbitrarily in a future Python version.


That's correct, and that's the reason Terry suggested that wording. If we
were to do the import system over again, sys.modules would either be hidden
from direct access, be attached to the code implementing the importer, or
have a leading underscore. So we don't want to strengthen the definition at
all; best we are comfortable with is put up a warning that you don't want
to do stuff with sys.modules unless you know what you're doing.


> But in my opinion there are legitimate cases where it is necessary to
> ensure a module will be reloaded the next time it is imported, and the
> documented way to do that is to remove entries from sys.modules.)
>

The Python import system is simply not designed around the idea of undoing
an import (the fact that imports have side-effects guarantee it will never
be 100% successful). Plus even using something like importlib.reload()
won't necessarily get you what you want since any object stored as an
attribute somewhere will not get updated.
___
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/MLQT5UTTRDNXP5PTTIAAJME6JBAWASBR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Lazy Imports [was: Declarative imports]

[Guido van Rossum]

On Mon, Apr 11, 2022 at 1:07 PM Itamar O  wrote:

> Breaking out the discussion about lazy imports.
> It seems somewhat OT in the declarative imports thread.
>
> On Mon, Apr 11, 2022 at 10:50 AM Barry Warsaw  wrote:
>
>> Thanks Carl,
>>
>> > On Apr 9, 2022, at 08:25, Carl Meyer  wrote:
>> >
>> > Our experience in practice, though, has been that universally lazy
>> > imports is somewhat easier to adopt than Strict Modules, and has had a
>> > much bigger overall impact on reducing startup time for big CLIs (and
>> > a big web server too; as you note it's not as serious an issue for a
>> > web server in production, but restart time still does make a
>> > difference to dev speed / experience.)
>>
>> Excellent point about the impact of restarts and development time.
>> That’s been an issue for us a bit, but not an overwhelming motivation to
>> rewrite in other languages[1].
>>
>
> Lazy imports had been very significant to both CLI startup time, as
> well as service reload time during local development - we have
> more details in the docs [1], and a related blog post coming up soon.
>
>
>>
>> > Removing slow stuff happening
>> > at import time helps, but it'll never match the speed of not doing the
>> > import at all! We've seen startup time improvements up to 70% in
>> > real-world CLIs just by making imports lazy. We've also opened an
>> > issue to discuss the possibility of upstreaming this. [2]
>> >
>> > [1] https://github.com/facebookincubator/cinder/#strict-modules
>> > [2] https://bugs.python.org/issue46963
>>
>> Post-GH-issues-migration link for the issue:
>> https://github.com/python/cpython/issues/91119
>>
>> I’ve put some questions and comments there, but I’m also really curious
>> about the technical details for your lazy imports.  Have you gotten as far
>> as thinking about a PR or PEP?
>>
>
> Yes and Yes (at least for the "thinking about" part).
> Germán Méndez Bravo (Kronuz) will be drafting a PEP,
> and is leading work internally to port this from 3.8 (first
> to 3.10, then to the cpython main branch).
> We are planning to get started on this during PyCon sprints,
> it would be nice to connect in-person with anyone who's
> interested in this and happens to be in the sprints too!
>

I am and I will be.

>
>
>>
>> -Barry
>>
>> [1] Not that there aren’t other reasons folks give for rewriting, such as
>> multicore performance, ecosystem alignment (e.g. SREs being more
>> comfortable in Go), etc.
>>
>
> Itamar.
>
> [1]
> https://github.com/facebookincubator/cinder/blob/cinder/3.8/CinderDoc/lazy_imports.rst#lazy-imports
> ___
> 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/NIXH574H64DXEXNZK6NDOGNZKQQPUDYM/
> 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/KZRURVH7VLHD7JQ2ASNZ6OMBVTVYEYXG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] RFC on PEP 681: Data Class Transforms

[Erik De Bonte via Python-Dev]

PEP 681 improves type checker 
support for libraries with dataclass-like behaviors by introducing a way to map 
the behaviors of decorators and classes in those libraries to the behaviors of 
stdlib dataclass.

The PEP will not affect CPython directly except for the addition of the 
dataclass_transform decorator in typing.py. The decorator is currently in 
typing_extensions.

The canonical discussion thread is on Typing 
SIG.
 Please send any comments there.

Any feedback would be appreciated!

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

[Python-Dev] Lazy Imports [was: Declarative imports]

[Itamar O]

Breaking out the discussion about lazy imports.
It seems somewhat OT in the declarative imports thread.

On Mon, Apr 11, 2022 at 10:50 AM Barry Warsaw  wrote:

> Thanks Carl,
>
> > On Apr 9, 2022, at 08:25, Carl Meyer  wrote:
> >
> > Our experience in practice, though, has been that universally lazy
> > imports is somewhat easier to adopt than Strict Modules, and has had a
> > much bigger overall impact on reducing startup time for big CLIs (and
> > a big web server too; as you note it's not as serious an issue for a
> > web server in production, but restart time still does make a
> > difference to dev speed / experience.)
>
> Excellent point about the impact of restarts and development time.  That’s
> been an issue for us a bit, but not an overwhelming motivation to rewrite
> in other languages[1].
>

Lazy imports had been very significant to both CLI startup time, as
well as service reload time during local development - we have
more details in the docs [1], and a related blog post coming up soon.


>
> > Removing slow stuff happening
> > at import time helps, but it'll never match the speed of not doing the
> > import at all! We've seen startup time improvements up to 70% in
> > real-world CLIs just by making imports lazy. We've also opened an
> > issue to discuss the possibility of upstreaming this. [2]
> >
> > [1] https://github.com/facebookincubator/cinder/#strict-modules
> > [2] https://bugs.python.org/issue46963
>
> Post-GH-issues-migration link for the issue:
> https://github.com/python/cpython/issues/91119
>
> I’ve put some questions and comments there, but I’m also really curious
> about the technical details for your lazy imports.  Have you gotten as far
> as thinking about a PR or PEP?
>

Yes and Yes (at least for the "thinking about" part).
Germán Méndez Bravo (Kronuz) will be drafting a PEP,
and is leading work internally to port this from 3.8 (first
to 3.10, then to the cpython main branch).
We are planning to get started on this during PyCon sprints,
it would be nice to connect in-person with anyone who's
interested in this and happens to be in the sprints too!


>
> -Barry
>
> [1] Not that there aren’t other reasons folks give for rewriting, such as
> multicore performance, ecosystem alignment (e.g. SREs being more
> comfortable in Go), etc.
>

Itamar.

[1]
https://github.com/facebookincubator/cinder/blob/cinder/3.8/CinderDoc/lazy_imports.rst#lazy-imports
___
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/NIXH574H64DXEXNZK6NDOGNZKQQPUDYM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 687 – Isolating modules in the standard library

[Guido van Rossum]

In the sentence starting with

Types whose methods need access to their module instance will be converted
to heap types[...]

please emphasize (bold!) "whose methods need access to their module
instance".

Also emphasize this paragraph:

"Static types that do not need module state access, and have no other
reason to be converted, should stay static."

I hadn't noticed the qualification in the first sentence and had assumed
all types were to be converted, until I came across the second at the very
end of the section (where it is easily overlooked by lazy readers :-).

On Mon, Apr 11, 2022 at 6:33 AM Petr Viktorin  wrote:

> Hello,
> Please provide any feedback you might have on PEP 687 – Isolating
> modules in the standard library: https://peps.python.org/pep-0687/
>
>  From recent discussions around “what should have a PEP”, it’s clear
> that this should have been a PEP long ago. Better late than never, I guess!
>
> We submit this PEP to explain the changes, seek consensus on whether
> they are good, propose the remaining changes, and set best practices for
> new modules.
>
> There's a discussion thread on Discourse:
>
> https://discuss.python.org/t/pep-687-isolating-modules-in-the-standard-library/14824
>
>
> ___
> 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/B3HYQIE4Z5WBJCC3FUZJZHXLM32I4BZA/
> 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/MOGERKXYWRSSM65L5MK3PQC6BO65GLJ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Declarative imports

[Barry Warsaw]

Thanks Carl,

> On Apr 9, 2022, at 08:25, Carl Meyer  wrote:
> 
> Our experience in practice, though, has been that universally lazy
> imports is somewhat easier to adopt than Strict Modules, and has had a
> much bigger overall impact on reducing startup time for big CLIs (and
> a big web server too; as you note it's not as serious an issue for a
> web server in production, but restart time still does make a
> difference to dev speed / experience.)

Excellent point about the impact of restarts and development time.  That’s been 
an issue for us a bit, but not an overwhelming motivation to rewrite in other 
languages[1].

> Removing slow stuff happening
> at import time helps, but it'll never match the speed of not doing the
> import at all! We've seen startup time improvements up to 70% in
> real-world CLIs just by making imports lazy. We've also opened an
> issue to discuss the possibility of upstreaming this. [2]
> 
> [1] https://github.com/facebookincubator/cinder/#strict-modules
> [2] https://bugs.python.org/issue46963

Post-GH-issues-migration link for the issue: 
https://github.com/python/cpython/issues/91119

I’ve put some questions and comments there, but I’m also really curious about 
the technical details for your lazy imports.  Have you gotten as far as 
thinking about a PR or PEP?

-Barry

[1] Not that there aren’t other reasons folks give for rewriting, such as 
multicore performance, ecosystem alignment (e.g. SREs being more comfortable in 
Go), etc.



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

[Python-Dev] Re: Need gh-13143 (bpo-34975: Add start_tls() method to streams API) to be merged

[Jelle Zijlstra]

El lun, 11 abr 2022 a las 9:10, Oleg Iarygin ()
escribió:

> Hi everyone,
>
> Can PR gh-13143 be reopened and reviewed/merged when possible? It was
> closed in favor of the new asyncio streams API (gh-13251). Later, the API
> was cleanly removed (gh-16482) so the proposed PR became relevant again.
>

I can't reopen the PR; I assume the branch was deleted. It's going to be
easier to just open a new PR.


>
> The added method allows to turn encryption on on demand (and off, as the
> author expressed his readiness). It's required for a CPython test suit, to
> port `test.test_ftplib.DummyFTPServer` from asyncore/asynchat before their
> removal according to PEP 594 (Removing dead batteries from the standard
> library).
>
> Thank you in advance.
> ___
> 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/RNQKBKAU3DPLGQLX3WZB5IRPEUKU6XKK/
> 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/SMZEYTOYSJOFRKQMSVZPJJOGLMAKIACA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Need gh-13143 (bpo-34975: Add start_tls() method to streams API) to be merged

[Oleg Iarygin]

Hi everyone,

Can PR gh-13143 be reopened and reviewed/merged when possible? It was closed in 
favor of the new asyncio streams API (gh-13251). Later, the API was cleanly 
removed (gh-16482) so the proposed PR became relevant again.

The added method allows to turn encryption on on demand (and off, as the author 
expressed his readiness). It's required for a CPython test suit, to port 
`test.test_ftplib.DummyFTPServer` from asyncore/asynchat before their removal 
according to PEP 594 (Removing dead batteries from the standard library).

Thank you in advance.
___
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/RNQKBKAU3DPLGQLX3WZB5IRPEUKU6XKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Declarative imports

[Patrick Reader]

On 10/04/2022 15:52, Guido van Rossum wrote:

On Sun, Apr 10, 2022 at 2:31 AM Daniel Pope  wrote:

On Fri, 8 Apr 2022, 17:44 Guido van Rossum,  wrote:

The interesting idea here seems to make "lazy imports" easier
to implement by making them explicit in the code. So far, most
lazy import frameworks for Python have done hacks with
`__getattribute__` overrides.


The value is more than ease of implementation. Having syntax for
import expressions makes them statically analysable, which is
needed for type checkers and IDE autocompletion.


This has been brought up a few times and I don't get it. Currently a 
use of an imported module is perfectly analyzable by all the static 
type checkers I know of (e.g. mypy, Pyre, pyright). For the static 
analyzer it makes no difference if I have


import re
.
.
.
def foo(x):
    if re.match(r"blah", x): ...

or the hypothetical inline form:

def foo(x):
    if @re.match(r"blah", x): ...

But I also see value in being able to type out code that uses
modules not yet imported without breaking my flow to add an import
statement. I don't yet trust IDEs to do this because I've been
bitten by them doing so incorrectly in the past.


I have too.


I see no reason why @re.match(...) couldn't just be equivalent to 
__import__("re").match(...) (or a more optimised compiled version of 
that). Any side-effects of importing the module (of which there probably 
shouldn't be any for most modules) just happen at whenever the first 
time the @re.match(...) is evaluated.


After the first call, and unless __import__ is overloaded, I also don't 
think @re.match(...) would have to be significantly slower than 
re.match(...). The latter already has to look up a global variable 
(assuming the module was imported globally, which is almost always the 
case). I don't think it would be too hard to optimise and Quicken.
___
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/3P5KUDUZXOIEZSEWNV7UMVAQNGYPGXDF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 687 – Isolating modules in the standard library

[Petr Viktorin]

Hello,
Please provide any feedback you might have on PEP 687 – Isolating 
modules in the standard library: https://peps.python.org/pep-0687/


From recent discussions around “what should have a PEP”, it’s clear 
that this should have been a PEP long ago. Better late than never, I guess!


We submit this PEP to explain the changes, seek consensus on whether 
they are good, propose the remaining changes, and set best practices for 
new modules.


There's a discussion thread on Discourse: 
https://discuss.python.org/t/pep-687-isolating-modules-in-the-standard-library/14824



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

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

[Nick Coghlan]

On Sun, 10 Apr 2022, 8:44 am Eric V. Smith,  wrote:

> On 4/9/2022 4:28 PM, Terry Reedy wrote:
> > On 4/9/2022 5:09 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> >>
> >> Not only deletion, but also random assignments:
> >
> > Ok.  Change "Manual deletion of entries from sys.modules" to "Direct
> > manipulation of sys.modules"
>
> I'm not sure it's worth the hassle to document this. There are no doubt
> hundreds of ways to break things. We can't enumerate all of them.
>


I thought we already explicitly said that if you directly alter the import
system's data stores then it's possible to break things in non-obvious ways.

If we don't, then it seems reasonable to make it explicit that the runtime
*isn't* implicitly enforcing the invariants the import system expects to
see, it is instead assuming that all code manipulating the data stores is
cooperating to ensure those invariants hold.

As the OP noted, in the context of programming languages in general, rather
than Python in particular, it's a relatively unusual design choice to allow
developers the ability to inadvertently (or intentionally!) corrupt the
internal consistency of the import system's runtime state to the point
where legal code won't run anymore (even though it's aligned with Python's
generally permissive philosophy that allows even destructive actions like
clearing the builtin namespace).

Cheers,
Nick.


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