Hi Paul,
On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote:
>
> Can someone state what's currently unpalatable about 649? It seemed to
> address the forward-referencing issues, certainly all of the cases I was
> expecting to encounter.
Broadly speaking I think there are 3-4 issues to resolve as
On Tue, Apr 26, 2022 at 7:24 PM Greg Ewing
wrote:
> On 27/04/22 2:01 am, Chris Angelico wrote:
> > That would be the case if monkeypatching were illegal. Since it's not,
> > wherein lies the difference?
>
> The proposed feature is analogous to forward declaring a
> struct in C. Would you call
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
> I also would like to hear more about the problem this is trying to solve,
> when th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too quickly into
esoteric details of implementation and
On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno wrote:
>
> I am not worried about the bikeshed part of which syntax to use -
> and more worried with the possible breaking of a lot of stuff, unless
> we work with creation of a non-identical "forward object" that is
> rebound, as in plain name
Hi Larry,
On Sat, Apr 23, 2022 at 1:53 AM Larry Hastings wrote:
> But rather than speculate further, perhaps someone who works on one of the
> static type analysis checkers will join the discussion and render an informed
> opinion about how easy or hard it would be to support "forward class"
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
>
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
Hi Larry,
On 4/14/21, 1:56 PM, "Larry Hastings" wrote:
>My plan was to post it here and see what the response was first. Back in
> January, when I posted the first draft, I got some very useful feedback that
> resulted in some dramatic changes. This time around, so far, nobody has
>
Hi Larry,
On 4/12/21, 6:57 PM, "Larry Hastings" wrote:
Again, by "works on PEP 563 semantics", you mean "doesn't raise an error".
But the code has an error. It's just that it has been hidden by PEP 563
semantics.
I don't agree that changing Python to automatically hide errors is an
11 matches
Mail list logo
