[Python-Dev] Re: Python 0.9.1

[Stefan Ring]

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
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DYL6AVU6IN4FNGONQO3MSGTFIUENWJWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Stefan Ring]

> 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 python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CZFFUBW52HBIGMNLJZME46EQLMKZVUZA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Stefan Ring]

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 unmangled
> scripts.
>
> $ ls -lh Python-0.9.1.tar.gz
> -rwxr-xr-x 1 steve steve 379K Nov  5  2009 Python-0.9.1.tar.gz
>
> I don't remember where I got it from, but it compiled on CentOS release
> 5.11, I'm not sure if it will compile on anything newer.
>
> Skip, if you would like me to email it to you privately, let me know.
> (Likewise for anyone else.)

The original ones are here:
http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/
Look at http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/index.gz
for the associating subjects with file names. As far as I can tell,
they extract flawlessly using unshar.

When I see diffs like this (your git vs. the unshar result) I tend to
trust unshar more:

--- a/README
+++ b/README
@@ -41,7 +41,7 @@ I am the author of Python:
1098 SJ  Amsterdam
The Netherlands

-   E-mail: gu...@cwi.nl
+   E-mail: gu...@cwi.nl

--- a/doc/mod.tex
+++ b/doc/mod.tex
@@ -17,7 +17,7 @@
 \itembreak
 }

-   itle{\bf
+\title{\bf
Python Library Reference \\
(DRAFT)
 }
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/M22TFWZRACVXGLNHDHLWJ5FHUZBAYDEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Steven D'Aprano]

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 steve steve 379K Nov  5  2009 Python-0.9.1.tar.gz

I don't remember where I got it from, but it compiled on CentOS release 
5.11, I'm not sure if it will compile on anything newer.

Skip, if you would like me to email it to you privately, let me know. 
(Likewise for anyone else.)



-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AG5PBM32M36HYEDTWANZ34XDR2LQQBNE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Jim J. Jewett]

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 stubs include a docstring?  If so, then adding subsequent lines that 
are only parameter annotations doesn't seem like a problem.  

And frankly, allowing subsequent lines (possibly restricted to 
first-except-docstrings) doesn't seem any more invasive than adding another 
magic type that has to be interpreted differently.  (I understand it might be 
more coding in practice, based on one solution having already been written.)

def is_str_list(val: List[object]) -> bool:
"""Determines whether all objects in the list are strings"""
val: NarrowsTo[List[str]]

I agree that Greg's suggestion of 

def is_str_list(val: Constrains[List[object]:List[str]) -> bool:

also meets the criteria you list, but ... as a human reader, that signature is 
getting too heavy.

I'll also note that I don't think TypeScript is a good model for "this won't be 
a problem."  It is probably a good model for "this will work for the people who 
*want* to go whole hog on explicit typing", but for people who are at best 
agnostic about typing ... they would stick with JavaScript, instead of using 
TypeScript.  Alas, this change isn't being proposed just for TypedPython; it is 
being proposed for baseline python.

-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DXVRLPGFUYQ2CDNMQSS66M7RITSGIB3R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Jim J. Jewett]

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 answer is "there won't 
be, these are simple functions", then that sort of screams that these are a 
special kind of function that should be decorated to alert readers to the 
restriction.

def is_str_list(val: List[object]) -> bool:
val: NarrowsTo[List[str]]

is still near the top (like a docstring), and doesn't require a change in how 
to interpret existing syntax.  Someone who doesn't care about typing can wonder 
why you bothered to quote/assert val, just as they can wonder why you did that 
to a docstring, but it will be (almost) as obvious that the line doesn't *do* 
anything -- so at least they won't assume it is doing something else (such as 
returning some custom type that you happen to call TypeGuard). 

-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IZULNMCU6SHAFDO4BFGWEDE3ZNUHWPFZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Skip Montanaro]

> 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 stupid little extraction script did a reasonable job. I see
plenty of differences, but a cursory examination shows they are only
in leading whitespace. Where I translated "\t" to TAB, it seems Andrew
used a suitable number of spaces. Python modules/scripts seem more
plausibly indented, and the couple I tried worked, so I'm a bit more
confident I have things right:

% PYTHONPATH=lib ./src/python
>>> import string
>>> print string.upper('hello world!')
HELLO WORLD!
>>>
% ./src/python lib/fact.py
9
[3, 3, 41, 271]
4096
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2]

The tests don't pass though. 1 * 1 raises an integer overflow exception:

>>> 1 * 1
Unhandled exception: run-time error: integer overflow
Stack backtrace (innermost last):
  File "", line 1

I'll let someone figure that out. :-)

At any rate, the git repo has been updated.

Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RPNQWLFJ54QENZZEKTRLSYZXVPDOGWFS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Jonathan Goble]

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 stumbled across this 12-year-old diary/blog
post: 
http://www.dalkescientific.com/writings/diary/archive/2009/03/27/python_0_9_1p1.html

A little further digging led to
https://www.python.org/download/releases/early/ which references the
above post and is the first hit on Google for the search query
"alt.sources python 0.9.1" (without the quotes).

> As that wasn't listed in the historical releases README file

It would be good to add it to that.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Z22BR75Z4XZEWWM4V4DCO3Q6R6OMJDX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Paul Sokolovsky]

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 on it, though it will
> take a Python script to massage back into correct format.

Also mind
http://www.dalkescientific.com/writings/diary/archive/2009/03/27/python_0_9_1p1.html
for result comparison.

> 
> Skip

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OG3EYQ4S6BA5WUWZUM26XFX2ED6F3LPZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Skip Montanaro]

> 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 format.

Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GIHYWK64MY4TBQA357HOK2K7MG3HZBFN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Skip Montanaro]

>
> 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 or Hiromi.
>

Yes, that's certainly possible. While it's nice that Google has archived
this stuff, their faithfulness to the original formats leaves a bit to be
desired (and gmane still doesn't work for me, eliminating that option). Guido's
messages are displayed as HTML, and I saw no way to get at the raw Usenet
messages. I just copied the shar data and saved the result. It seems clear
that tabs copied as spaces. The Makefile indentation was hosed up. It
should have dawned on me that the .py, .c and .h files would be messed up
as well. I was only concerned with building the interpreter.

If someone knows how to get the original Usenet messages from what Google
published, let me know.

Skip

>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WQ4QHOWHQVLCNCJGAWALBSLDYLVHJIEI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Guido van Rossum]

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
> 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 or Hiromi.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/56QFAN7EIGTHEJZX6XXYAIQLSDLKHSQN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Mats Wichmann]

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 01/21
XThis is Python, an extensible interpreted programming language that 
Xcombines remarkable power with very clear syntax. X XThis is version 
0.9 (the first beta release), patchlevel

2/19/91
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EM6XSLVPQWO6W2DB73TX6JLAWEPKGH4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Senthil Kumaran]

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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OBWWV3HP7GI24SL6NDN7UPUFTHRKJFXZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 0.9.1

[Guido van Rossum]

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 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 patch), then made a few tweaks to get it to
> build:
>
> % ./python
> >>> print 'hello world!'
> hello world!
> >>> import sys
> >>> dir(sys)
> ['argv', 'exit', 'modules', 'path', 'ps1', 'ps2', 'stderr', 'stdin',
> 'stdout']
> >>> sys.modules
> {'builtin': ; 'sys': ; '__main__':  '__main__'>}
> >>> sys.exit(0)
>
> I then pushed the result to a Github repo:
>
> https://github.com/smontanaro/python-0.9.1
>
> There is a new directory named "shar" with the original files, a small
> README file and a compile.patch file between the original code and the
> runnable code.
>
> It was a pleasant diversion for a couple hours. I was tired of shovelling
> snow anyway... Thank you, Hiromi.
>
> Skip
>
> *  Hiromi is bcc'd on this note in case he cares to comment. I didn't want
> to publish his email beyond the bounds of the webmaster alias without his
> permission.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VZYELIYAQWUHHGIIEPPJFREDX6F24KMN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GW7WJRO5OWVP5ATIU75GJ6IRA4BRLSAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Joseph Perez]

> 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, "y")]:
return isinstance(x, int) and isinstance(y, str)
```
Provide the following shortcuts:
- `TypeGuard` second parameter can be omitted,  i.e. `TypeGuard(int)`; the type 
guard then apply to the first parameter of the function
- `TypeGuard` can be used like a type, i.e. `def is_int(x) -> TypeGuard[int]` 
(and the type guard apply then to the first parameter), but it has to be 
evaluated to `Annotated[bool, TypeGuard(int)]` at runtime (by implementing 
`TypeGuard.__class_getitem__`).
To be interpreted by type checkers, type guard must be evaluated as a boolean 
condition (exactly as the current proposal):
```python
def is_int(x) -> TypeGuard[int]:
return isinstance(x, int)
x = ...
if is_int(x):
# reveal_type(x) -> int
while is_int(x):
# reveal_type(x) -> int
def foo(x):
assert is_int(x)
# reveal_type(x) -> int
```
Restriction: `TypeGuard` second parameter must be a string literal 
corresponding to the name of a function whose return type is annotated, or must 
be omitted.

A possible implementation of `TypeGuard` would be:
```python
class TypeGuard:
def __init__(self, tp, param=None):
self.tp = tp
if param is not None and not isinstance(param, str):
raise TypeError("Type guard parameter mapping must be a string")
self.param = param

def __class_getitem__(self, item):
return Annotated[bool, TypeGuard(item)]
```

(It's not really different than my first mail, but I've fixed my mistake by 
using `__class_getitem__` instead of `__getitem__)

I see the following advantages of using PEP 593:
-  it will not break type checkers implementation when it will be released (at 
the condition of using the raw `Annotated` form and not the second shortcut)
- the second shortcut makes it as easy to use than the current proposal using a 
special form
- it allows supporting type guard for multiple parameters (but this use case 
should be quite occasional)
- it will not break tools using runtime introspection (I think the case where 
return type of type guard predicate is inspected at runtime will also be very 
uncommon)
- it allows returning other thing than a boolean, for example an `Optional` 
value:
```python
def get_bar(foo) -> Annotated[Optional[Bar], TypeGuard(Foo)]:
return foo.bar if isinstance(foo, Foo) else None

foo = …
if bar := get_bar(foo):
# foo will be inferred as Foo
```
but this use case should be quite occasional too (and it's kind of tricky 
because if the type guard function returns an `Optional[int]` and the return is 
`0`, the type guard will still *fail*)
- lastly, it would be a good way to introduce PEP 593 into the standard 
library, as I see other use cases for it (especially `ClassVar` and `InitVar`), 
but that's an other subject.

The drawbacks:
- `TypeGuard` will not be interpreted when present in a `Callable` signature, 
and the following example will not be possible:
```python
def infer_list(l: list, guard: Callable[[Any], TypeGuard[T]]) -> 
TypeGuard[list[T]]:
return all(map(guard, l))
```
but this use case should also be occasional (especially because of the lack of 
generic type var, that make impossible to replace `list` by a `TypeVar`). By 
the way, I don't know if things like this are possible in TypeScript.
- your quote:
> I see PEP 593 as a verbose solution to the problem "how do we use annotations 
> for static typing and for runtime metadata simultaneously". Type guards solve 
> a problem that's entirely in the realm of static typing, so IMO it would be 
> an abuse of Annotated.

because I quite agree with you; contrary to `ClassVar` and `InitVar` which are 
used at runtime, `TypeGuard` should only be used by type checkers.

So there are pros and cons, but they are mostly about occasional use cases.
Personally, I would be more in favor of PEP 593, but the current proposal if 
also fine to me.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BISHSBSOYAYRY736P7RRONNVJWVWGJTY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 0.9.1

[Skip Montanaro]

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 patch), then made a few tweaks to get it to
build:

% ./python
>>> print 'hello world!'
hello world!
>>> import sys
>>> dir(sys)
['argv', 'exit', 'modules', 'path', 'ps1', 'ps2', 'stderr', 'stdin',
'stdout']
>>> sys.modules
{'builtin': ; 'sys': ; '__main__': }
>>> sys.exit(0)

I then pushed the result to a Github repo:

https://github.com/smontanaro/python-0.9.1

There is a new directory named "shar" with the original files, a small
README file and a compile.patch file between the original code and the
runnable code.

It was a pleasant diversion for a couple hours. I was tired of shovelling
snow anyway... Thank you, Hiromi.

Skip

*  Hiromi is bcc'd on this note in case he cares to comment. I didn't want
to publish his email beyond the bounds of the webmaster alias without his
permission.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VZYELIYAQWUHHGIIEPPJFREDX6F24KMN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Guido van Rossum]

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
use it).

On Tue, Feb 16, 2021 at 11:39 AM Joseph Perez  wrote:

> 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 static typing and for runtime metadata simultaneously".
> Type guards solve a problem that's entirely in the realm of static typing,
> so IMO it would be an abuse of Annotated.
>
> (I've also written in the mail about checked cast as an alternative
> solution to type guard.)
>
> > For the most extensible approach both -> TypeGuard(...)  and
> -> Annotated[bool, TypeGuard(...)] could be allowed, which would open the
> path for future non-type-annotations, which could be used regardless of
> whether the code
> is type-annotated.
> I've proposed a possible implementation in my mail linked above.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/B3QZTPW6S6LHQKX476VRYAWEVMZ26VHH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RL7KWEW6OKWW7TLZAX4AE76EJHG5LAWD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Guido van Rossum]

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 at 10:36 AM Joseph Perez  wrote:

> 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
> (notably, in recursive dataclasses).
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7QA3Z4CNYHW3GOEDAST6WW37O5OUJRW6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QKEOZJDPBOVI7QMF5GJLVKV6LRYK5MLT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Joseph Perez]

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 static typing and for runtime metadata simultaneously".
Type guards solve a problem that's entirely in the realm of static typing,
so IMO it would be an abuse of Annotated.

(I've also written in the mail about checked cast as an alternative solution to 
type guard.)

> For the most extensible approach both -> TypeGuard(...)  and
-> Annotated[bool, TypeGuard(...)] could be allowed, which would open the
path for future non-type-annotations, which could be used regardless of whether 
the code
is type-annotated.
I've proposed a possible implementation in my mail linked above.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/B3QZTPW6S6LHQKX476VRYAWEVMZ26VHH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Joseph Perez]

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 
(notably, in recursive dataclasses).
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7QA3Z4CNYHW3GOEDAST6WW37O5OUJRW6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Joseph Perez]

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 namespace, so when class `__annotations__` descriptor will 
be called inside the decorator, it will raise a `NameError` because of 
`friends` recursive annotation.

By the way, in the example given by the PEP:
```python
def foo(x: int = 3, y: MyType = None) -> float:
 ...
class MyType:
 ...
```
if `foo` is decorated with a decorator calling `__annotations__` or 
`get_type_hints`, it will fail too.

Using stringified annotations would prevent `NameError` to be raised, but it 
really mitigates the PEP claim that 
> This PEP also solves the forward reference problem

Not only this PEP doesn't solve (again, if I understand it correctly) the 
forward reference problem, but also it makes it a lot more tricky. And I think 
my first example is not so uncommon.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CDCDXBKQF6ALDEM4EEUGEK654XOKJG3I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Guido van Rossum]

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 for REPLs.
>
> I don't see why `if TYPE_CHECKING:` idiom breaks annotations with PEP 649.
> There will be no error as long as `__annotations__` descriptor is not
> called.
> And currently in 3.9 (with or without `from __future__ import
> annotations`), the issue is the same: you `get_type_hints` fails if some of
> the types in the annotations have been imported in a `if TYPE_CHECKING:`
> block.
>
> > Hm, that's a rather serious problem with Larry's PEP 649 compared to from
> __future__ import annotations, actually.
>
> As I've written above, this is not a new issue, and neither this PEP nor
> PEP 563 can fix it.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/PVPCJV6GATMRACXIPPNSNCUV7OFGDEU3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3EF3WUIYDHBJRGTYO7YX3TKZGRZFVSYY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

[Joseph Perez]

> 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 for REPLs.

I don't see why `if TYPE_CHECKING:` idiom breaks annotations with PEP 649. 
There will be no error as long as `__annotations__` descriptor is not called.
And currently in 3.9 (with or without `from __future__ import annotations`), 
the issue is the same: you `get_type_hints` fails if some of the types in the 
annotations have been imported in a `if TYPE_CHECKING:` block. 

> Hm, that's a rather serious problem with Larry's PEP 649 compared to from
__future__ import annotations, actually.

As I've written above, this is not a new issue, and neither this PEP nor PEP 
563 can fix it.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PVPCJV6GATMRACXIPPNSNCUV7OFGDEU3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?

[Petr Viktorin]

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` classes. I wrote a module 
that changes the `type_setattro` method to mine, which does not have 
this check. And I'm wondering if there are any problems in this solution 
(in addition to philosophical ones) or everything will work as it should 
(and not as inheritance from built-in types).

Thank you for participating in the discussion.



As with built-in types, lxml.etree classes and all other static (i.e. 
non-heap) types are shared between all interpreters in a process. 
Changing them has the same issues as with built-in types.

The check for the Py_TPFLAGS_HEAPTYPE flag is correct.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VITJX3QT2YG3AN5CY4FB7OP2VLSSP4UZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?

[Kazantcev Andrey]

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 that changes 
the `type_setattro` method to mine, which does not have this check. And I'm 
wondering if there are any problems in this solution (in addition to 
philosophical ones) or everything will work as it should (and not as an 
inheritance from built-in types).
 
Thank you for participating in the discussion.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OK47U3SRICVUIDC6V6KR3UMXKPOEVA3L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?

[Андрей Казанцев]

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 `type_setattro` method to mine, which does not have this check. And I'm wondering if there are any problems in this solution (in addition to philosophical ones) or everything will work as it should (and not as inheritance from built-in types). Thank you for participating in the discussion.___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5GBZLFJ5JFIW336LRH7TX6OKPA47LOG5/
Code of Conduct: http://python.org/psf/codeofconduct/