On Mon, Apr 11, 2022 at 2:03 PM Brett Cannon wrote:
> 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
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
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
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
To me Steve nailed it... static type checker = lean and mean...
On Fri, Apr 8, 2022, 5:03 AM Steven D'Aprano wrote:
> 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
On Sun, 10 Apr 2022 at 09:31, Daniel Pope wrote:
> 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.
I like this proposal and I agree with
On Sun, 10 Apr 2022, 15:53 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,
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
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
On Fri, Apr 8, 2022 at 1:26 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 is
> typing.
>
What for? To save a few keystrokes?
Can't some IDE's add the import for you?
Please don't drag
Hi Malthe,
On Fri, Apr 8, 2022 at 12:04 PM Malthe wrote:
> Actually, to me the interesting idea is not so much lazy imports – I
> think they should not be lazy, at least that was my initial thought. I
> think they should be immediately resolved before anything else in that
> module:
I'm +0.25
Hi Barry,
On Fri, Apr 8, 2022 at 12:44 PM Barry Warsaw wrote:
>
> 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
>
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
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
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
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
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
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
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 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
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
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 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
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 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 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:
>
>
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, 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,
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 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, 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
31 matches
Mail list logo
