You only get the ease-of-implementation benefit if you are willing to
explicitly mark every _use_ of a lazy-imported name as special (and
give the fully qualified name at every usage site). This is rather
more cumbersome (assuming multiple uses in a module) than just
explicitly marking an import
>
> Discourse it just flat-out easier to admin: individuals can flag posts,
> automatic spam detection, site-wide admins instead of per-list, ability to
> split topics, ability to lock topics, ability to "slow down" topics,
> time-limited suspensions, etc. I quit being an admin for any ML beyond
I do not think it's a "typing" improvement.
I think what I like most in the proposal (which might be implemented
differently - I am not too tied to this) is that it potentially brings huge
optimisations in import times when currently a lot of imports are done
unnecessarily early - slowing
On Fri, 8 Apr 2022 at 16:40, 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. IIRC the Cinder
> version
Start up overhead due to imports is a real problem for some class of
applications, e.g. CLIs, and I’ve seen a lot of hacks implemented to get Python
CLIs to be more responsive. E.g. getting from invocation to —help output is a
major UX problem.
It’s often more complicated than just imports
ACTIVITY SUMMARY (2022-04-01 - 2022-04-08)
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:
open7146 ( -7)
closed 51841 (+78)
total 58987 (+71)
Open issues
An interesting point in the lazy imports design space that I hadn't
previously considered could be:
- lazy imports are explicitly marked and usage of the imported name
within the module is transparent, but
- lazily imported names are _not_ visible in the module namespace;
they can't be accessed
On Thu, Apr 7, 2022 at 7:33 PM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> Gregory P. Smith writes:
>
> > We feel it too. We've been finding Discourse more useful from a
> community
> > moderation and thread management point of view as well as offering
> markdown
> > text and
In about 1 hour from now, bugs.python.org will become read-only, and
the migration to GitHub Issues will begin.
Throughout the migration it will not be possible to report new issues
or comment on existing ones. Once all the issues have been migrated
from bpo to GitHub, you will be able to
On 4/8/22 09:34, Petr Viktorin wrote:
> some cases where Discourse thinks something is a footer and removes it, but
> IMO they're not huge problems.
It also has some very good markdown support, so you can post nicely formatted
code via email. Mailing list mode with Discourse is almost nicer
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. IIRC the
Cinder version even modifies the bytecode and/or the interpreter.
Disregarding
On Thu, Apr 7, 2022 at 7:19 PM David Mertz, Ph.D.
wrote:
> FWIW, I find Discourse (and everything similar that I've seen), awkward,
> difficult to use, poorly organized, and in every way inferior to my mail
> client.
>
> I don't think I'm entirely alone in this experience though.
>
You're
On Fri, Apr 8, 2022 at 4:38 PM dfremont--- via Python-Dev <
python-dev@python.org> wrote:
> Hello,
>
> I came across what seems like either a bug in the import system or a gap
> in its documentation, so I'd like to run it by folks here to see if I
> should submit a bug report. If there's
Hello,
I came across what seems like either a bug in the import system or a gap in its
documentation, so I'd like to run it by folks here to see if I should submit a
bug report. If there's somewhere else more appropriate to discuss this, please
let me know.
If you import A.B, then remove A
On 4/8/2022 7:56 PM, Brett Cannon wrote:
On Fri, Apr 8, 2022 at 4:38 PM dfremont--- via Python-Dev
mailto:python-dev@python.org>> wrote:
If you import A.B, then remove A from sys.modules and import A.B
again, the newly-loaded version of A will not contain an attribute
referring
Thank you, Victor.
I had considered dropping (a) from the PEP. But I keep them because:
* I rushed to write PEP, before 3.11 beta.
* In the "Backward compatibility" section in the PEP, I want to
mention `locale.getencoding()` and `encoding="locale"`
* But they are not fixed in the main branch
On Fri, 8 Apr 2022 at 08:51, Paul Moore wrote:
> Are you exaggerating for effect here or would this *actually* just expand to
>
> from datetime import datetime
> default_args = {
> "start_date": datetime(...)
> }
Yes – and of course that is just a snippet, an actual complete script
will have
On 08. 04. 22 1:26, Ethan Furman wrote:
On 4/7/22 07:31, Petr Viktorin wrote:
On 07. 04. 22 15:59, Victor Stinner wrote:
Would it be possible to announce new PEPs on python-dev please?
Currently, all PEPs should be announced on python-dev, but not
necessarily right after they're
On Fri, 8 Apr 2022, 09:30 Malthe, wrote:
> For example, `some_regex = @re.compile(...)`.
>
I like the idea of import expressions. I pitched it on Discourse recently:
https://discuss.python.org/t/import-expressions/11582
However, I do not see hoisting as something that should be done by Python.
On Fri, 8 Apr 2022 at 18:29, Malthe wrote:
>
> This is an idea which has been brought up before, sometimes introduced
> as "heresy". But an interesting twist has surfaced now which is
> typing.
>
> But firstly, let me present the idea. It is very simple, that Python
> should have declarative
On Fri, 8 Apr 2022 at 09:29, Malthe wrote:
> A workflow definition which could be a 5-liner quickly
> becomes a 20-liner – consider for example:
>
> default_args = {
> "start_date": @datetime.datetime(...)
> }
Are you exaggerating for effect here or would this *actually* just
On Fri, Apr 08, 2022 at 08:24:40AM +, Malthe wrote:
> But firstly, let me present the idea. It is very simple, that Python
> should have declarative imports,
I'm not sure I understand why you consider this "declarative".
https://en.wikipedia.org/wiki/Declarative_programming
As I see it,
This is an idea which has been brought up before, sometimes introduced
as "heresy". But an interesting twist has surfaced now which is
typing.
But firstly, let me present the idea. It is very simple, that Python
should have declarative imports, usable anywhere using a simple
syntax, @.
For
Hi,
Le 08/04/2022 à 03:52, David Mertz, Ph.D. a écrit :
> FWIW, I find Discourse (and everything similar that I've seen), awkward,
> difficult to use, poorly organized, and in every way inferior to my mail
> client.
Another Discourse misfeature I just came across: history rewriting. I
know it's
On 07. 04. 22 17:10, Victor Stinner wrote:
On Thu, Apr 7, 2022 at 12:02 PM Petr Viktorin wrote:
- This API stays with the regular public API (Include/cpython/), but to
use it you'll need to #define Py_USING_UNSTABLE_API (name up for
bikeshedding).
Since there is already something similar
On Fri, 8 Apr 2022 at 10:15, Daniel Pope wrote:
> But, your proposed syntax is not usable because it is ambiguous. Exactly what
> you propose is already used for decorators in a way that the parser would not
> be able to distinguish a decorator from an import expression. Consider:
>
>
I've read the rest of the thread so far, and agree strongly that we
can't do this at the language/runtime level.
However ...
On 4/8/2022 9:24 AM, Malthe wrote:
This is an idea which has been brought up before, sometimes introduced
as "heresy". But an interesting twist has surfaced now which
On Fri, 8 Apr 2022 at 11:26, Malthe wrote:
> Perhaps `some_regex = re::compile(r"...")` could work.
>
> That is, :: to delineate the import.
As I mentioned in the Discourse thread, this syntax chimes with Rust
(and C++, and also PHP, triggering fond memories of Paamayim
Nekudotayim).
There are
On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote:
>
> I've read the rest of the thread so far, and agree strongly that we
> can't do this at the language/runtime level.
You mean the hoisting, right?
I don't see any reason why an import expression without hoisting would
be impractical. But I'd
On Apr 8, 2022, 6:49 AM -0500, Greg Ewing , wrote:
> On 8/04/22 12:13 pm, Gregory P. Smith wrote:
> > And
> > for lurkers and subscribers here to enable email notifications for
> > categories of interest over there.
>
> Is it possible to participate in a Discourse discussion entirely
> by email,
On Fri, 8 Apr 2022 at 10:27, Malthe wrote:
>
> On Fri, 8 Apr 2022 at 08:51, Paul Moore wrote:
> > Are you exaggerating for effect here or would this *actually* just expand to
> >
> > from datetime import datetime
> > default_args = {
> > "start_date": datetime(...)
> > }
>
> Yes – and of
On 8/04/22 12:13 pm, Gregory P. Smith wrote:
And
for lurkers and subscribers here to enable email notifications for
categories of interest over there.
Is it possible to participate in a Discourse discussion entirely
by email, without having to visit the web site?
If not, then if python-dev
On Fri, 8 Apr 2022 at 12:57, Daniel Pope wrote:
>
> On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote:
> >
> > I've read the rest of the thread so far, and agree strongly that we
> > can't do this at the language/runtime level.
>
> You mean the hoisting, right?
>
> I don't see any reason why an
While it's different than you proposal, some people may like this
magic "smart imports" project which lazily imports a module when it's
used :-)
Project: https://pypi.org/project/smart-imports/
Replace:
---
import math
from my_project import calc
# 100500 other imports
def my_code(argument,
On 08. 04. 22 13:40, Greg Ewing wrote:
On 8/04/22 12:13 pm, Gregory P. Smith wrote:
And for lurkers and subscribers here to enable email notifications for
categories of interest over there.
Is it possible to participate in a Discourse discussion entirely
by email, without having to visit the
On 4/8/2022 12:51 PM, Daniel Pope wrote:
On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote:
I've read the rest of the thread so far, and agree strongly that we
can't do this at the language/runtime level.
You mean the hoisting, right?
I don't see any reason why an import expression without
Hello,
Now that tomllib is in the stdlib, I'd like to convert the stable ABI
manifest (Misc/stable_abi.txt) to TOML to make it easier to work with.
To get proper highlighting in editors, I'd like to rename it from .txt
to .toml.
So, when the command that uses it stops working for you, change
37 matches
Mail list logo
