On 2/16/21 11:50 AM, Андрей Казанцев wrote:
It seems technically possible to override attributes/methods of
built-in types, but the question is more if it's desirable?
The problem is that you cannot override the method not only in built-in
types but also, for example, in `lxml.etree`
It seems technically possible to override attributes/methods of built-in types, but the question is more if it's desirable? The problem is that you cannot override the method not only in built-in types but also, for example, in `lxml.etree` classes. I wrote a module that changes the
Victor Stinner wrote:
> It seems technically possible to override attributes/methods of built-in
> types, but the question is more if it's desirable?
The problem is that you cannot override the method not only in built-in types
but also, for example, in `lxml.etree` classes. I wrote a module
It is an issue if you use `__annotations__` directly and you are using PEP
563's `from __future__ import annotations`. This currently gives some
strings that may or may not refer to existing globals. With Larry's PEP 649
it will raise an error.
On Tue, Feb 16, 2021 at 9:35 AM Joseph Perez wrote:
> Please note that this is a thread about PEP 649.
>
> If PEP 649 accepted and PEP 563 dies, all such idioms breaks
annotation completely.
>
> Users need to import all heavy modules and circular references used
only type hints, or user can not get even string form annotation which
is very useful
PEP 649 doesn't prevent to use stringified annotations (Larry has previously
mentioned it in its response to Paul Bryan), and they seem to be still required
when `if TYPE_CHECKING:` is used, despite the PEP claim.
And my last message bring some use cases where strings are also required
If I've understood the PEP correctly, it would cause the following simple
example to fail:
```python
from dataclasses import dataclass
@dataclass
class User:
name: str
friends: list[User]
```
In fact, when the `dataclass` decorator is called, `User` class is not yet
added to the module
I certainly wouldn't want to keep `from __future__ import annotations` in
the language forever if Larry's PEP is accepted.
Of course you can still use explicit string literals in annotations.
Your observation about the @dataclass decorator is significant. Thanks for
that.
On Tue, Feb 16, 2021
I've proposed PEP 593 `Annotated` too, but in the typing-sig mailing list:
https://mail.python.org/archives/list/typing-...@python.org/message/CVLLRWU7MU7T2AMC4P7ZEG4IMJF6V5UL/
and Guido had the following answer:
> I see PEP 593 as a verbose solution to the problem "how do we use
annotations for
Could you summarize your proposal in a few lines? I've tried to read that
email several times now and I still don't follow the proposal. You can
leave the reasoning *why* you believe your proposal is better out -- I just
want to see what it will look like (how to define a type guard, and how to
> Could you summarize your proposal in a few lines?
Use PEP 593 `Annotated` the way Adrian has proposed, but with an additional
parameter which maps the type guard on the given function parameter name:
```python
def check_int_and_str(x, y) -> Annotated[bool, TypeGuard(int, "x"),
TypeGuard(str,
Awesome, Skip!
Was there a date somewhere? I can't recall if this would have been the
first open source release (from just about 30 years ago, sometime in
February 1991) or some time later in the same year?
On Tue, Feb 16, 2021 at 1:57 PM Skip Montanaro
wrote:
> A note to webmas...@python.org
On Tue, Feb 16, 2021 at 1:58 PM Skip Montanaro
wrote:
>
> I then pushed the result to a Github repo:
>
> https://github.com/smontanaro/python-0.9.1
>
Wow. Was white-space not significant in this release of Python? I see the
lack of indentation in the first Python programs.
On Tue, Feb 16, 2021 at 2:59 PM Senthil Kumaran wrote:
> On Tue, Feb 16, 2021 at 1:58 PM Skip Montanaro
> wrote:
>
>>
>> I then pushed the result to a Github repo:
>>
>> https://github.com/smontanaro/python-0.9.1
>>
>
> Wow. Was white-space not significant in this release of Python? I see the
>
A note to webmas...@python.org from an astute user named Hiromi in
Japan* referred
us to Guido's shell archives for the 0.9.1 release from 1991. As that
wasn't listed in the historical releases README file:
https://legacy.python.org/download/releases/src/README
I pulled the shar files (and a
On 2/16/21 3:44 PM, Guido van Rossum wrote:
Awesome, Skip!
Was there a date somewhere? I can't recall if this would have been the
first open source release (from just about 30 years ago, sometime in
February 1991) or some time later in the same year?
Guido van Rossum
unread,
Python 0.9.1 part
On Tue, Feb 16, 2021 at 5:02 PM Skip Montanaro wrot
> A note to webmas...@python.org from an astute user named Hiromi in Japan*
> referred us to Guido's shell archives for the 0.9.1 release from 1991.
Very interesting discovery! In my efforts to uncover the original
plaintext usenet post, I
> Also mind
> http://www.dalkescientific.com/writings/diary/archive/2009/03/27/python_0_9_1p1.html
> for result comparison.
Thanks, Paul. I had lost track of Andrew. Good to know he's still out
there. I wonder why his tar file was never sucked up into the
historical releases page.
Whew! My
>
> Wow. Was white-space not significant in this release of Python? I see the
>> lack of indentation in the first Python programs.
>>
>
> Indentation most certainly was significant from day 0. I suspect what
> happened is that these files got busted somehow by the extraction process
> used by Skip
> If someone knows how to get the original Usenet messages from what Google
> published, let me know.
Seems the original shar is there buried in a Javascript string toward
the end of the file. I think I've got a handle on it, though it will
take a Python script to massage back into correct
Hello,
On Tue, 16 Feb 2021 18:22:00 -0600
Skip Montanaro wrote:
> > If someone knows how to get the original Usenet messages from what
> > Google published, let me know.
>
> Seems the original shar is there buried in a Javascript string toward
> the end of the file. I think I've got a handle
> When I see diffs like this (your git vs. the unshar result) I tend to
> trust unshar more:
Sorry, it was not you. I meant the github repo from this e-mail thread.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
On Tue, Feb 16, 2021 at 05:49:49PM -0600, Skip Montanaro wrote:
> If someone knows how to get the original Usenet messages from what Google
> published, let me know.
I don't have those, but I do have a copy of Python 0.9.1 with unmangled
scripts.
$ ls -lh Python-0.9.1.tar.gz
-rwxr-xr-x 1
On Wed, Feb 17, 2021 at 7:33 AM Steven D'Aprano wrote:
>
> On Tue, Feb 16, 2021 at 05:49:49PM -0600, Skip Montanaro wrote:
>
> > If someone knows how to get the original Usenet messages from what Google
> > published, let me know.
>
> I don't have those, but I do have a copy of Python 0.9.1 with
It was not that bad, though:
https://github.com/smontanaro/python-0.9.1/compare/main...Ringdingcoder:original
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
Another advantage of annotating the variable is that it moves some stuff out
the signature line.
def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
is probably OK on length, but if there were even a second typed and defaulted
parameter, it would start to get unwieldy. And if the
Eric Traut wrote:
"""It must be possible to express the type guard within the function signature.
In other words, the implementation should not need to be present. This is
important for compatibility with type stubs and to guarantee consistent
behaviors between type checkers."""
Can type
27 matches
Mail list logo
