Sorry, folks, but I've been busy the last few days--the Language Summit
is Wednesday, and I had to pack and get myself to SLC for PyCon,
I'll circle back and read the messages on the existing threads
tomorrow. But for now I wanted to post "the wonderful third option" for
forward class
On Tue, Apr 26, 2022 at 12:33 AM Mehdi2277 wrote:
> The forward class annotations would not need need to be processed at
> runtime and could be no-ops.
>
> forward class A:
> x: int
> y: list[int]
>
>
So, as I"ve written before, since there seems to be no way out of Writing
Everything Twice
After talking about this in the SC today, we agreed to deprecate mailcap
under the auspices of PEP 594:
https://github.com/python/peps/commit/701999a91dc5f976c00d5bde1510226ebd9c7822
.
On Thu, Apr 14, 2022 at 11:44 AM Brett Cannon wrote:
> A CVE has been opened against mailcap (see
>
The forward class annotations would not need need to be processed at runtime
and could be no-ops.
forward class A:
x: int
y: list[int]
A.__annotations__ could be empty. For a more complete example you could have,
forward class A:
value: B # This annotation is solely for type checker and
The problem comes solely from runtime introspection of type annotations. Static
typing does not need this nor do any exceptional cases occur. From
mypy/pyright/other type checker perspective there is not an issue to solve
here. dataclasses, pydantic, cattrs, click, and other libraries that
One reason I dislike this whole proposal is that I can see forward
declarations (FDs) ending up in code that doesn't need them. This could
happen if
(a) The FDs were needed at some point, but then the type
declarations were taken out. This could happen with someone modifying
their own
On 4/25/2022 9:13 PM, Mehdi2277 wrote:
We could have forward part include all of method signatures/attributes which is
what a type checker needs. In theory we could do,
forward class Foo:
x: int
y: list[str]
def __init__(self, ...)
def process(self, data: list[float]) ->
We could have forward part include all of method signatures/attributes which is
what a type checker needs. In theory we could do,
forward class Foo:
x: int
y: list[str]
def __init__(self, ...)
def process(self, data: list[float]) -> float: ...
and then later do continue class. If
On 4/25/2022 1:10 PM, Jim J. Jewett wrote:
(That said, my personal opinion is that this is pretty heavyweight for very
little gain; why not just create a placeholder class that static analysis tools
are supposed to recognize as likely-to-be-replaced later? And why not just
use strings
On Tue, 26 Apr 2022 at 10:05, Greg Ewing wrote:
>
> On 23/04/22 5:44 pm, Chris Angelico wrote:
> > On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote:
> >>
> >> Still, it's not the intent of my PEP to condone or facilitate
> >> monkeypatching.
> >>
> >
> > The only difference is that you call
On 23/04/22 6:41 pm, Mehdi2277 wrote:
If it's allowed that a forward class may be continued in a different module I do not see how type checker like mypy/pyright could handle that. Classes are generally viewed as closed and fully defined within type checker.
The way this kind of thing works in
On 23/04/22 5:44 pm, Chris Angelico wrote:
On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote:
Still, it's not the intent of my PEP to condone or facilitate monkeypatching.
The only difference is that you call it something
different.
To me, monkeypatching means modifying the definition
On 23/04/22 10:10 pm, Terry Reedy wrote:
'forward class' for an incomplete class is not at all clear to me. It
is not clear to me which part of speech you intend it to be: noun, verb,
adjective, or adverb. You must have some experience with 'forward' in a
different context that makes it
On 23/04/22 7:22 pm, Steven D'Aprano wrote:
He said that could be
used as a very primitive form of separation of interface and
implementation, by putting the `forward class` in one module and the
`continue` in another.
But that only works if there is some way to define the interface
of the
On Mon, Apr 25, 2022 at 2:33 PM Brett Cannon wrote:
>
>
> On Sat, Apr 23, 2022 at 8:31 AM wrote:
>
>> Hello all,
>>
>> I am very excited about a future multithreaded Python. I managed to
>> postpone some rewrites in the company I work for Rust/Go, precisely because
>> of the potential to have a
On Sat, Apr 23, 2022 at 2:39 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> UGH!
>
I understand you don't like the proposal, but do please try to keep it
civil. It's totally okay to say you don't like something, but I don't think
anyone would take kindly to someone coming up to
On Sat, Apr 23, 2022 at 8:31 AM wrote:
> Hello all,
>
> I am very excited about a future multithreaded Python. I managed to
> postpone some rewrites in the company I work for Rust/Go, precisely because
> of the potential to have a Python solution in the medium term.
>
> I was wondering. Is Sam
There is an important difference between monkeypatching in general, vs
monkey-patching an object that was explicitly marked and documented as
expecting a monkeypatch.
(That said, my personal opinion is that this is pretty heavyweight for very
little gain; why not just create a placeholder
* Erik, could you propose a change to the PEP text?
I just created https://github.com/python/peps/pull/2555 to address these issues.
-Erik
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
On 23. 04. 22 3:15, Larry Hastings wrote:
Here's one alternate idea for how to implement the "forward class" syntax.
The entire point of the "forward class" statement is that it creates
the real actual class object. But what if it wasn't actually the
"real" class object? What if it was only
On Fri, Apr 22, 2022 at 2:52 PM Fabio Zadrozny wrote:
> Humm, now I'm a bit worried... the approach the debugger is using gets the
> PyFrameObject that's about to be executed and changes the
> PyFrameObject.f_code just before the execution so that the new code is
> executed instead.
You can
21 matches
Mail list logo
