[Python-Dev] Re: Typing syntax and ecosystem, take 2

[Chris Angelico]

On Thu, Apr 15, 2021 at 2:36 PM Hugh Fisher  wrote:
>
> > Date: Wed, 14 Apr 2021 09:57:49 +1000
> > From: Chris Angelico 
> > Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2
>
> >
> > You're advocating an approach that absolutely mandates running the
> > type checker, but then caches the results in an executable file (the
> > JS file built from the TS source). Python already has a caching system
> > - the .pyc files - so if you're importing the same file more than
> > once, the cost of parsing type annotations is pretty much equivalent
> > to the cost of doing it in TypeScript.
>
> Thinking about it, if mypy compiled to .pyc for execution by the Python
> interpreter most of what I'm complaining about would go away.
>

The Python interpreter compiles to .pyc for execution by the Python
interpreter. Why should MyPy duplicate that work?

ChrisA
___
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/23D3CTOKNODHMH77LVLNCZKUCMAKNS5A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem, take 2

[Hugh Fisher]

> Date: Wed, 14 Apr 2021 09:57:49 +1000
> From: Chris Angelico 
> Subject: [Python-Dev] Re: Typing syntax and ecosystem, take 2

>
> You're advocating an approach that absolutely mandates running the
> type checker, but then caches the results in an executable file (the
> JS file built from the TS source). Python already has a caching system
> - the .pyc files - so if you're importing the same file more than
> once, the cost of parsing type annotations is pretty much equivalent
> to the cost of doing it in TypeScript.

Thinking about it, if mypy compiled to .pyc for execution by the Python
interpreter most of what I'm complaining about would go away.

-- 

cheers,
Hugh Fisher
___
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/LXFOU3TSSBXVCEFRMWJBBV7GHVRW357P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem, take 2

[Stephen J. Turnbull]

Hugh Fisher writes:

 > There are a lot of programmers like me. Those languages I listed
 > are widely used, and therefore we assume that if a Python language
 > construct looks like something we've used before, it will work in
 > the same way.

That's not very persuasive.  When in London, England, you speak
English, but you probably shouldn't assume that the words others use
mean the same thing that they do in London, Ohio.

Anyway, in which of those languages is "def foo(x:float = 1) -> int"
legal syntax?  What do you mean it "looks like" something you've used
before?  It looks to me like what you mean is "To me, declared types
(no matter what they look like) aren't hints, types should be
enforced."  I agree, that's what you learn if your experience is
restricted to common explicitly typed languages, but reality is more
flexible than that.  That's why I read manuals before using a new
language or a feature newly added to a familiar language. :-)

 > > Python's different approach is a compromise.  And as usual Guido's
 > > time machine (or somebody borrowed it) is in evidence: if that example
 > > bothers you, request that people around you who type things like that
 > > use stub files instead so you don't have to deal with it.
 > 
 > And that would be the TypeScript style approach, "typed Python" is a
 > language that gets translated into non-type hinted dynamic Python.

I can't agree.  To me it's the same Python with typed objects and
untyped identifiers it's always been, and that's a feature.  The
question is whether you see the hints in the implementation source, or
in an auxiliary file.  "Typed Python" as currently implemented is not
a different language.  It's the same language with extensive use of a
previously little-used feature (function annotations).

 > No-one who works in JavaScript needs to deal with TypeScript
 > language features unless they want to. This is not true of the
 > current typing in Python.

You *need* to deal with typing only to the extent of ignoring it.  OK,
one of the real selling points of Python is that its syntax is fairly
economical, and type hints do have a cost in that sense.  But the
answer to that is "just don't", and go ahead and ask colleagues you
share code with to "just don't" too.

 > >  > From an environmental point of view we're also doing the read
 > >  > source, lexical scan, syntax parse twice rather than once.
 > >
 > > This is not true.  Most programs, *especially* programs that are
 > > complex enough to want type-checking, are run far more often than they
 > > are type-checked.
 > 
 > Among the software devs I work with, testing and checking is something
 > you do *every* time you make a change. If I'm adding type checks to my
 > program, that's because I want them to be checked.

And that's the last time anybody ever runs that program?  That's
certainly not true of any of the programs I would consider using type
hinting for!  Even the test suite will typically run mypy once, and
the program itself many times since that's the easiest way to
guarantee de novo initialization of the program's state for each test.

 > Historical example would be lint for C programs. Running lint
 > wasn't required before compiling your C code, but it was so useful
 > that a number of projects made it compulsory, and the functionality
 > of lint was eventually incorporated into the C compiler itself.

I think the analogy is valid, but it doesn't support your position.
See Brett's reply for why, I'm just +1-ing here.

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/NCCQJXFHYPBKTUNXKHIWCE35N7UTWNVV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Inada Naoki]

On Thu, Apr 15, 2021 at 11:09 AM Larry Hastings  wrote:
>
> Thanks for doing this!  I don't think PEP 649 is going to be accepted or 
> rejected based on either performance or memory usage, but it's nice to see 
> you confirmed that its performance and memory impact is acceptable.
>
>
> If I run "ann_test.py 1", the annotations are already turned into strings.  
> Why do you do it that way?  It makes stock semantics look better, because 
> manually stringized annotations are much faster than evaluating real 
> expressions.
>

Because `if TYPE_CHECKING` and manually stringified annotation is used
in real world applications.
I want to mix both use cases.

-- 
Inada Naoki  
___
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/MKAGFBTVZ4LXYJC5X6P3LXXXRD7P2WH5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Larry Hastings]

Thanks for doing this!  I don't think PEP 649 is going to be accepted or 
rejected based on either performance or memory usage, but it's nice to 
see you confirmed that its performance and memory impact is acceptable.



If I run "ann_test.py 1", the annotations are already turned into 
strings.  Why do you do it that way?  It makes stock semantics look 
better, because manually stringized annotations are much faster than 
evaluating real expressions.


It seems to me that the test would be more fair if test 1 used real 
annotations.  So I added this to "lines":


   from types import SimpleNamespace
   foo = SimpleNamespace()
   foo.bar = SimpleNamespace()
   foo.bar.baz = float

I also changed quote(t) so it always returned t unchanged.  When I ran 
it that way, stock semantics "exec" time got larger.



Cheers,


//arry/

On 4/14/21 6:44 PM, Inada Naoki wrote:

I added memory usage data by tracemalloc.

```
# Python 3.9 w/ old semantics
$ python3 ann_test.py 1
code size: 121011
memory: (385200, 385200)
unmarshal: avg: 0.3341682574478909 +/- 3.700437551781949e-05
exec: avg: 0.4067857594229281 +/- 0.0006858555167675445

# Python 3.9 w/ PEP 563 semantics
$ python3 ann_test.py 2
code size: 121070
memory: (398675, 398675)
unmarshal: avg: 0.3352349083404988 +/- 7.749102039824168e-05
exec: avg: 0.24610224328935146 +/- 0.0008628035427956459

# master + optimization w/ PEP 563 semantics
$ ./python ~/ann_test.py 2
code size: 110488
memory: (193572, 193572)
unmarshal: avg: 0.31316645480692384 +/- 0.00011766086337841035
exec: avg: 0.11456295938696712 +/- 0.0017481202239372398

# co_annotations + optimization w/ PEP 649 semantics
$ ./python ~/ann_test.py 3
code size: 204963
memory: (208273, 208273)
unmarshal: avg: 0.597023528907448 +/- 0.00016614519056599577
exec: avg: 0.09546191191766411 +/- 0.00018099485135812695
```

Summary:

* Both of PEP 563 and PEP 649 has low memory consumption than Python 3.9.
* Importing time (unmarshal+exec) is about 0.7sec on old semantics and
PEP 649, 0.43sec on PEP 563.

On Thu, Apr 15, 2021 at 10:31 AM Inada Naoki  wrote:

I created simple benchmark:
https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d

This benchmark creates 1000 annotated functions and measure time to
load and exec.
And here is the result. All interpreters are built without --pydebug,
--enable-optimization, and --with-lto.

```
# Python 3.9 w/ stock semantics

$ python3 ~/ann_test.py 1
code size: 121011
unmarshal: avg: 0.33605549649801103 +/- 0.007382938279889738
exec: avg: 0.395090194279328 +/- 0.001004608380122509

# Python 3.9 w/ PEP 563 semantics

$ python3 ~/ann_test.py 2
code size: 121070
unmarshal: avg: 0.3407619891455397 +/- 0.0011833618746421965
exec: avg: 0.24590165729168803 +/- 0.0003123404336687428

# master branch w/ PEP 563 semantics

$ ./python ~/ann_test.py 2
code size: 149086
unmarshal: avg: 0.45410854648798704 +/- 0.00107521956753799
exec: avg: 0.11281821667216718 +/- 0.00011939747308270317

# master branch + optimization (*) w/ PEP 563 semantics
$ ./python ~/ann_test.py 2
code size: 110488
unmarshal: avg: 0.3184352931333706 +/- 0.0015278719180908732
exec: avg: 0.11042822999879717 +/- 0.00018108884723599264

# co_annotatins reference implementation w/ PEP 649 semantics

$ ./python ~/ann_test.py 3
code size: 229679
unmarshal: avg: 0.6402394526172429 +/- 0.0006400500128250688
exec: avg: 0.09774857209995388 +/- 9.275466265195788e-05

# co_annotatins reference implementation + optimization (*) w/ PEP 649 semantics

$ ./python ~/ann_test.py 3
code size: 204963
unmarshal: avg: 0.5824743471574039 +/- 0.007219086642131638
exec: avg: 0.09641968684736639 +/- 0.0001416784753249878
```

(*) I found constant folding creates new tuple every time even though
same tuple is in constant table.
See https://github.com/python/cpython/pull/25419
For co_annotations, I cherry-pick
https://github.com/python/cpython/pull/23056  too.


--
Inada Naoki  





___
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/PV3TWXK3WFITD2AGFQKQZEK3S26FQHRC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Fred Drake]

On Wed, Apr 14, 2021 at 7:04 PM Jim J. Jewett  wrote:

> I don't have a deep answer, but I do think __version__ should be specified
> (or at least mentioned) at
> https://docs.python.org/3/reference/datamodel.html


Given the intent to reject PEP 394, I can't imagine any good would come of
that.

Drop a __version__ in your modules if you find it valuable, but otherwise,
there's nothing to do here.


  -Fred

-- 
Fred L. Drake, Jr.
"There is nothing more uncommon than common sense."
  --Frank Lloyd Wright
___
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/3QHBGEIDDJEHZP5Q2I3ZGQ73FZ6SPDAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Inada Naoki]

I added memory usage data by tracemalloc.

```
# Python 3.9 w/ old semantics
$ python3 ann_test.py 1
code size: 121011
memory: (385200, 385200)
unmarshal: avg: 0.3341682574478909 +/- 3.700437551781949e-05
exec: avg: 0.4067857594229281 +/- 0.0006858555167675445

# Python 3.9 w/ PEP 563 semantics
$ python3 ann_test.py 2
code size: 121070
memory: (398675, 398675)
unmarshal: avg: 0.3352349083404988 +/- 7.749102039824168e-05
exec: avg: 0.24610224328935146 +/- 0.0008628035427956459

# master + optimization w/ PEP 563 semantics
$ ./python ~/ann_test.py 2
code size: 110488
memory: (193572, 193572)
unmarshal: avg: 0.31316645480692384 +/- 0.00011766086337841035
exec: avg: 0.11456295938696712 +/- 0.0017481202239372398

# co_annotations + optimization w/ PEP 649 semantics
$ ./python ~/ann_test.py 3
code size: 204963
memory: (208273, 208273)
unmarshal: avg: 0.597023528907448 +/- 0.00016614519056599577
exec: avg: 0.09546191191766411 +/- 0.00018099485135812695
```

Summary:

* Both of PEP 563 and PEP 649 has low memory consumption than Python 3.9.
* Importing time (unmarshal+exec) is about 0.7sec on old semantics and
PEP 649, 0.43sec on PEP 563.

On Thu, Apr 15, 2021 at 10:31 AM Inada Naoki  wrote:
>
> I created simple benchmark:
> https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d
>
> This benchmark creates 1000 annotated functions and measure time to
> load and exec.
> And here is the result. All interpreters are built without --pydebug,
> --enable-optimization, and --with-lto.
>
> ```
> # Python 3.9 w/ stock semantics
>
> $ python3 ~/ann_test.py 1
> code size: 121011
> unmarshal: avg: 0.33605549649801103 +/- 0.007382938279889738
> exec: avg: 0.395090194279328 +/- 0.001004608380122509
>
> # Python 3.9 w/ PEP 563 semantics
>
> $ python3 ~/ann_test.py 2
> code size: 121070
> unmarshal: avg: 0.3407619891455397 +/- 0.0011833618746421965
> exec: avg: 0.24590165729168803 +/- 0.0003123404336687428
>
> # master branch w/ PEP 563 semantics
>
> $ ./python ~/ann_test.py 2
> code size: 149086
> unmarshal: avg: 0.45410854648798704 +/- 0.00107521956753799
> exec: avg: 0.11281821667216718 +/- 0.00011939747308270317
>
> # master branch + optimization (*) w/ PEP 563 semantics
> $ ./python ~/ann_test.py 2
> code size: 110488
> unmarshal: avg: 0.3184352931333706 +/- 0.0015278719180908732
> exec: avg: 0.11042822999879717 +/- 0.00018108884723599264
>
> # co_annotatins reference implementation w/ PEP 649 semantics
>
> $ ./python ~/ann_test.py 3
> code size: 229679
> unmarshal: avg: 0.6402394526172429 +/- 0.0006400500128250688
> exec: avg: 0.09774857209995388 +/- 9.275466265195788e-05
>
> # co_annotatins reference implementation + optimization (*) w/ PEP 649 
> semantics
>
> $ ./python ~/ann_test.py 3
> code size: 204963
> unmarshal: avg: 0.5824743471574039 +/- 0.007219086642131638
> exec: avg: 0.09641968684736639 +/- 0.0001416784753249878
> ```
>
> (*) I found constant folding creates new tuple every time even though
> same tuple is in constant table.
> See https://github.com/python/cpython/pull/25419
> For co_annotations, I cherry-pick
> https://github.com/python/cpython/pull/23056  too.
>
>
> --
> Inada Naoki  



-- 
Inada Naoki  
___
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/JIZ6PCV5SSIL7BUKZUCVF45OFNO4H26I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Inada Naoki]

I created simple benchmark:
https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d

This benchmark creates 1000 annotated functions and measure time to
load and exec.
And here is the result. All interpreters are built without --pydebug,
--enable-optimization, and --with-lto.

```
# Python 3.9 w/ stock semantics

$ python3 ~/ann_test.py 1
code size: 121011
unmarshal: avg: 0.33605549649801103 +/- 0.007382938279889738
exec: avg: 0.395090194279328 +/- 0.001004608380122509

# Python 3.9 w/ PEP 563 semantics

$ python3 ~/ann_test.py 2
code size: 121070
unmarshal: avg: 0.3407619891455397 +/- 0.0011833618746421965
exec: avg: 0.24590165729168803 +/- 0.0003123404336687428

# master branch w/ PEP 563 semantics

$ ./python ~/ann_test.py 2
code size: 149086
unmarshal: avg: 0.45410854648798704 +/- 0.00107521956753799
exec: avg: 0.11281821667216718 +/- 0.00011939747308270317

# master branch + optimization (*) w/ PEP 563 semantics
$ ./python ~/ann_test.py 2
code size: 110488
unmarshal: avg: 0.3184352931333706 +/- 0.0015278719180908732
exec: avg: 0.11042822999879717 +/- 0.00018108884723599264

# co_annotatins reference implementation w/ PEP 649 semantics

$ ./python ~/ann_test.py 3
code size: 229679
unmarshal: avg: 0.6402394526172429 +/- 0.0006400500128250688
exec: avg: 0.09774857209995388 +/- 9.275466265195788e-05

# co_annotatins reference implementation + optimization (*) w/ PEP 649 semantics

$ ./python ~/ann_test.py 3
code size: 204963
unmarshal: avg: 0.5824743471574039 +/- 0.007219086642131638
exec: avg: 0.09641968684736639 +/- 0.0001416784753249878
```

(*) I found constant folding creates new tuple every time even though
same tuple is in constant table.
See https://github.com/python/cpython/pull/25419
For co_annotations, I cherry-pick
https://github.com/python/cpython/pull/23056  too.


-- 
Inada Naoki  
___
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/JEP4MXAHCVGQF7AI5OUUSGOENXAOR43O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Jim J. Jewett]

Larry Hastings wrote:
> On 4/14/21 1:42 PM, Baptiste Carvello wrote:
> > Are there specific annoyances associated with quoting always, apart 
> > from the 2 more characters?

> Yes.  Since the quoted strings aren't parsed by Python, syntax errors in 
> these strings go undetected until somebody does parse them (e.g. your 
> static type analyzer).

This is a real problem.  But in theory, your code editor (and python) *could* 
parse the strings.  They generally don't, but I'm not sure asking them to do 
that is much harder than asking them to deal with new syntax.

-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/JR2RKEEUI3WSIUBZOJ4J3EVRTVYGLXSU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Jim J. Jewett]

Baptiste Carvello wrote:
> Le 14/04/2021 à 19:44, Guido van Rossum a écrit :

> > No, what I heard is that, since in *most* cases the string quotes are
> > not needed, people are surprised and annoyed when they encounter cases
> > where they are needed.

> Well, I had assumed quotes would be used in all cases for consistency.

That does seem like a reasonable solution.  Redundant, ugly, and annoying, but 
safe and consistent.  Sort of like using type constraints in the first place.  
:D

> > ... the rule for finding the end of
> > an annotation would be very simple -- just skip words until the next
> > comma, close paren or colon, skipping matching brackets etc.

> ... But the hypothetic "def foo(prec:
> --precision int):" is already less readable. Will finding the closing
> comma or colon always be obvious to the human reader?

Nope.  "--" sometimes means "ignore the rest of the line, including the ")".  
At the moment, I can't remember where I've seen this outside of SQL, but I can 
guarantee that if I read it late enough at night, the *best* case would be that 
I notice the ambiguity, guess correctly and am only annoyed.

-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/MV3HQASUSAEKC332UFUDWQNONLCXZDRZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Bryan]

https://docs.python.org/3/reference/datamodel.html

On Wed, 2021-04-14 at 22:56 +, Jim J. Jewett wrote:
> Paul Moore wrote:
> > What's wrong with Version(module.__version__)? And if the
> > __version__
> > attribute isn't a valid version, raise an exception?
> 
> I don't have a deep answer, but I do think __version__ should be
> specified (or at least mentioned) at
> https://docs.python.org/3/reference/datamodel.html
> 
> At the moment, I can't even find a listing of possible __dunder__
> attributes, though I'm almost sure I've seen one in the past.
> 
> -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/AG344CLSKM7BDOYP3CWGXGBNFSPWVQU4/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/PZQD4HJZS34VKS6KT5QC5J6LOKEEHKEX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Jim J. Jewett]

Paul Moore wrote:
> What's wrong with Version(module.__version__)? And if the __version__
> attribute isn't a valid version, raise an exception?

I don't have a deep answer, but I do think __version__ should be specified (or 
at least mentioned) at https://docs.python.org/3/reference/datamodel.html

At the moment, I can't even find a listing of possible __dunder__ attributes, 
though I'm almost sure I've seen one in the past.

-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/AG344CLSKM7BDOYP3CWGXGBNFSPWVQU4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Bryan]

Seems like this is something that should make its way into stdlib?

On Thu, 2021-04-15 at 00:15 +0200, Antoine Pitrou wrote:
> On Wed, 14 Apr 2021 22:23:44 +0100
> Paul Moore  wrote:
> > On Wed, 14 Apr 2021 at 21:59, David Mertz  wrote:
> > > 
> > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore 
> > > wrote:  
> > > > 
> > > > If it's not basically equivalent to packaging.version.Version
> > > > (and
> > > > based on PEP 440) then we'll be creating a nightmare of
> > > > confusion,
> > > > because PEP 440 versions are fundamental to packaging.  
> > > 
> > > Are you suggesting that users should have to install an external
> > > module to tell what version of packages they are using?!  
> > 
> > No. To tell what version of a package they are using, a string is
> > sufficient.
> > 
> > They only need a version object if they want to do additional
> > processing (like comparing versions, or checking whether a version
> > meets a constraint).
> > 
> > Given that the packaging ecosystem already has a canonical version
> > object (provided by the packaging library), which has been used and
> > tested extensively in many environments, inventing a different API
> > seems at best ill-advised. Whether the stdlib needs a version
> > object.
> > rather than leaving that functionality to a 3rd party library, is
> > the
> > same question that comes up for *any* functionality that's proposed
> > for the stdlib, and I have no particular opinion in this case.
> 
> Tangentially, until now projects could use distutils's LooseVersion
> if
> they wanted to compare version numbers reliably.  With distutils
> being
> deprecated, they'll have to either depending on packaging (which is a
> large dependency just for comparison version numbers) or vendor
> packaging's Version class (which is doable but still some bothersome
> additional work).
> 
> Regards
> 
> Antoine.
> 
> 
> ___
> 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/T4J2JD454XP3ZGULM777H5EG5Z3WVNMJ/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/M6WEZ5YR66LQRFYITSD6Y5L457V3NZOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[Terry Reedy]

On 4/14/2021 8:00 AM, Joachim Wuttke wrote:


Furthermore, if policy about API changes allows, I'd suggest
that `NO_TIMESTAMP` become the new default value for `mtime`.


Changing defaults is a huge pain, which we mostly avoid.



--
Terry Jan Reedy

___
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/3LA5EIND4O2JGF5SBQBWF3K3W2YPG3EG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[Antoine Pitrou]

On Wed, 14 Apr 2021 21:38:11 +0100
Steve Holden  wrote:
> DEFAULT_TIMESTAMP?

It's not a default timestamp, it's a placeholder value meaning "no
timestamp".  The aforementioned RFC 1952 explicitly says: "MTIME = 0
means no time stamp is available".

So yes, it really means "no timestamp", regardless of the fact that
it's encoded as integer value 0.

Regards

Antoine.


___
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/D7MERE7EKE4RINSGNOFK52MDLM7QTRKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Antoine Pitrou]

On Wed, 14 Apr 2021 22:23:44 +0100
Paul Moore  wrote:
> On Wed, 14 Apr 2021 at 21:59, David Mertz  wrote:
> >
> > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore  wrote:  
> >>
> >> If it's not basically equivalent to packaging.version.Version (and
> >> based on PEP 440) then we'll be creating a nightmare of confusion,
> >> because PEP 440 versions are fundamental to packaging.  
> >
> > Are you suggesting that users should have to install an external module to 
> > tell what version of packages they are using?!  
> 
> No. To tell what version of a package they are using, a string is sufficient.
> 
> They only need a version object if they want to do additional
> processing (like comparing versions, or checking whether a version
> meets a constraint).
> 
> Given that the packaging ecosystem already has a canonical version
> object (provided by the packaging library), which has been used and
> tested extensively in many environments, inventing a different API
> seems at best ill-advised. Whether the stdlib needs a version object.
> rather than leaving that functionality to a 3rd party library, is the
> same question that comes up for *any* functionality that's proposed
> for the stdlib, and I have no particular opinion in this case.

Tangentially, until now projects could use distutils's LooseVersion if
they wanted to compare version numbers reliably.  With distutils being
deprecated, they'll have to either depending on packaging (which is a
large dependency just for comparison version numbers) or vendor
packaging's Version class (which is doable but still some bothersome
additional work).

Regards

Antoine.


___
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/T4J2JD454XP3ZGULM777H5EG5Z3WVNMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Moore]

On Wed, 14 Apr 2021 at 21:59, David Mertz  wrote:
>
> On Wed, Apr 14, 2021 at 9:12 PM Paul Moore  wrote:
>>
>> If it's not basically equivalent to packaging.version.Version (and
>> based on PEP 440) then we'll be creating a nightmare of confusion,
>> because PEP 440 versions are fundamental to packaging.
>
> Are you suggesting that users should have to install an external module to 
> tell what version of packages they are using?!

No. To tell what version of a package they are using, a string is sufficient.

They only need a version object if they want to do additional
processing (like comparing versions, or checking whether a version
meets a constraint).

Given that the packaging ecosystem already has a canonical version
object (provided by the packaging library), which has been used and
tested extensively in many environments, inventing a different API
seems at best ill-advised. Whether the stdlib needs a version object.
rather than leaving that functionality to a 3rd party library, is the
same question that comes up for *any* functionality that's proposed
for the stdlib, and I have no particular opinion in this case.

>> What's wrong with Version(module.__version__)? And if the __version__
>> attribute isn't a valid version, raise an exception? That's what
>> packaging.version does, and it's worked fine for the packaging
>> ecosystem. Is there a benefit that justifies being different here?
>
> Doesn't that seem really, really painful to use in an interactive shell?  
> This is honestly (a simplified version of) what I tried in trying to learn 
> packaging.version.Version.  It was not a good experience:

It's designed for programmatic use, not interactive use, yes. But
that's sort of my point, why do you want anything more than the bare
string in the REPL? What are you planning on doing with it?

Paul
___
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/6424E3GOVU463R7SOFQQXCWKV2M3LZRV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Larry Hastings]

On 4/14/21 1:42 PM, Baptiste Carvello wrote:
Are there specific annoyances associated with quoting always, apart 
from the 2 more characters?



Yes.  Since the quoted strings aren't parsed by Python, syntax errors in 
these strings go undetected until somebody does parse them (e.g. your 
static type analyzer).  Having the Python compiler de-compile them back 
into strings means they got successfully parsed.  Though this doesn't 
rule out other errors, e.g. NameError.


I thought this was discussed in PEP 563, but now I can't find it, so 
unfortunately I can't steer you towards any more info on the subject.



Cheers,


//arry/

___
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/UKO7SMXHUK5KLTWVTMU2RL6LAZQWA67U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

On Wed, 2021-04-14 at 22:42 +0200, Baptiste Carvello wrote:

> That's assuming the syntax in the annotations doesn't diverge too
> much
> from the Python syntax as far as brackets etc are concerned. I must
> say
> I'm not too worried about typing. But the hypothetic "def foo(prec:
> --precision int):" is already less readable. Will finding the closing
> comma or colon always be obvious to the human reader?

To push the limit, let's add some default value:

def foo(prec: --precision int = 123):
    ...

vs.

def foo(prec: "--precision int" = 123):
    ...

And if a "type parameter" becomes numeric. For example:

def foo(prec: --max bar 3000 = 123):
    ...

vs.

def foo(prec: "--max bar 3000" = 123):
    ...

Now, the quotes seem even more readable as a delimiter.

Paul

___
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/UITB2A657TAINAGWGRD6GCKWFC5PEBIZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

On Wed, Apr 14, 2021 at 9:12 PM Paul Moore  wrote:

> If it's not basically equivalent to packaging.version.Version (and
> based on PEP 440) then we'll be creating a nightmare of confusion,
> because PEP 440 versions are fundamental to packaging.
>

Are you suggesting that users should have to install an external module to
tell what version of packages they are using?!

What's wrong with Version(module.__version__)? And if the __version__
> attribute isn't a valid version, raise an exception? That's what
> packaging.version does, and it's worked fine for the packaging
> ecosystem. Is there a benefit that justifies being different here?
>

Doesn't that seem really, really painful to use in an interactive shell?
This is honestly (a simplified version of) what I tried in trying to learn
packaging.version.Version.  It was not a good experience:

% conda create -n test python=3.9 pandas
[...]
% conda activate test
% python
>>> import packaging
ModuleNotFoundError: No module named 'packaging'
^D
% pip install packaging
[...]
% python
>>> import packaging
>>> import panda, numpy, re,  statistics
>>> packaging.version.Version(pandas)
AttributeError: module 'packaging' has no attribute 'version'
>>> from packaging.version import Version
>>> Version(pandas)
TypeError: expected string or bytes-like object
>>> Version(pandas.__version__)

>>> Version(statistics.__version__)
AttributeError: module 'statistics' has no attribute '__version__'
>>> Version(re.__version__)

>>> import vaex
>>> Version(vaex.__version__)
TypeError: expected string or bytes-like object

I cannot find a case where the more verbose spelling is ever nicer than
just referencing `mod.__version__` directly for such exploration.  Yes, I
get that formal packaging has different needs.  But here it just seems like
a lot more work to get a lot less information back.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/QW4ZCLPH3TMYQNZMFVVGXXRJDYAMOG75/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Fred Drake]

On Wed, Apr 14, 2021 at 4:19 PM Paul Moore  wrote:

> PS I see Barry plans on rejecting the PEP, which I think is probably
> the right decision, given the way this thread has developed.
>

Barry makes good plans.

Putting the version into the sources is a bit of an anti-pattern.  IMO.


  -Fred

-- 
Fred L. Drake, Jr.
"There is nothing more uncommon than common sense."
  --Frank Lloyd Wright
___
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/HPAU4PMIGPPG2R7RJIL6QDS2WYACBCRV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Baptiste Carvello]

Hi,

Le 14/04/2021 à 19:44, Guido van Rossum a écrit :
> 
> No, what I heard is that, since in *most* cases the string quotes are
> not needed, people are surprised and annoyed when they encounter cases
> where they are needed. And if you have a large code base it takes an
> expensive run of the static type checker to find out that you've
> forgotten the quotes.

Well, I had assumed quotes would be used in all cases for consistency.
Indeed, using them only if needed leads to surprises. Are there specific
annoyances associated with quoting always, apart from the 2 more characters?

>  
> [...]
> 
> They will treat it as anything else they don't quite understand -- they
> will ignore it unless it bites them. And the rule for finding the end of
> an annotation would be very simple -- just skip words until the next
> comma, close paren or colon, skipping matching brackets etc.

That's assuming the syntax in the annotations doesn't diverge too much
from the Python syntax as far as brackets etc are concerned. I must say
I'm not too worried about typing. But the hypothetic "def foo(prec:
--precision int):" is already less readable. Will finding the closing
comma or colon always be obvious to the human reader?

Cheers,
Baptiste
___
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/E654LKI36TFURBOSBMFUPEMLJQ32CZNN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[Steve Holden]

DEFAULT_TIMESTAMP?

Kind regards,
Steve


On Wed, Apr 14, 2021 at 8:03 PM  wrote:

> If the so, then a better name than NO_TIMESTAMP should be chosen, as the
> gzip specification does not allow for no timestamp.
> ___
> 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/O3ENOZ5OAFYX6PBXMEDGS3RJ3OSPKNYC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/QAACKOOKU34IV7GRCRO4CWCJTAPB5VLB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Moore]

On Wed, 14 Apr 2021 at 18:04, Eric V. Smith  wrote:
>> Anyway, the question now for me is whether this is worth any more of my time.
>>
>> So:
>> - Is there someone willing to sponsor?
>> - Do folks generally think there's a chance of it being accepted without a 
>> huge debate and expansion of scope.
>>
>> I think that before these can be answered, you need to decide why this needs 
>> to be standardized. I don't see any reason to standardize it unless there's 
>> some programmatic use for these version strings. If it's just the user 
>> poking around on the REPL, then I think the status quo is fine. I've read 
>> the PEP, and the User Stories section talks about user convenience, not 
>> programmatic access.
>
> I also think the distribution version is more useful than any __version__ 
> information in each module/package. I realize this information might not be 
> available, depending on how the code was installed (say, just by copying some 
> files into the right place).

Agreed. The original PEP was very limited, just proposing a string
value for user convenience, with no programmatic interface. Doing
anything more than that is opening up a whole load of complexity and
compatibility (with packaging) that no-one has expressed any need for.

The distribution version (exposed via importlib.metadata) is the
correct thing to use for anything programmatic.

Paul

PS I see Barry plans on rejecting the PEP, which I think is probably
the right decision, given the way this thread has developed.
___
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/MQIFSJYQYCY4YBHVECJ7H2WR443EE32W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Moore]

On Wed, 14 Apr 2021 at 18:01, David Mertz  wrote:
>
> On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker  
> wrote:
>>
>> Another possible issue: using Version would require an extra import in many 
>> module initializations -- is that a performance issue that would matter?
>
>
> I like having a `Version` object that is easily importable in the standard 
> library.  I think it should relatively polymorphic.  I.e. it should accept a 
> module or package as an argument, but also should accept a string or a tuple. 
>  Maybe other objects from which one could reasonably extract a version.

If it's not basically equivalent to packaging.version.Version (and
based on PEP 440) then we'll be creating a nightmare of confusion,
because PEP 440 versions are fundamental to packaging.

> In particular, I think initializing this object with a module object should 
> at least look for a .__version__ attribute, and appropriately case either a 
> string (that looks sufficiently version-like) or a tuple.  I think that if it 
> doesn't succeed, it should become some sort of "cannot determine" object that 
> is neither less than nor greater than any other Version object.  In 
> particular, the Vaex example with a dictionary of versions of each component 
> should probably just become this "cannot determine" value (but as an instance 
> of Version).

What's wrong with Version(module.__version__)? And if the __version__
attribute isn't a valid version, raise an exception? That's what
packaging.version does, and it's worked fine for the packaging
ecosystem. Is there a benefit that justifies being different here?

Can I remind people that the packaging community have done a *huge*
amount of work designing and standardising concepts like version
identifiers, version comparisons and constraints, etc. (PEPs 440 and
508). Understanding those standards should really be the basic
starting point for any discussion like this.

Paul
___
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/U2PUBZZ2AULMULLESO3LZ74MCRV7BQ3G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Carl Meyer via Python-Dev]

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 
> suggested even minor changes.  Folks have just expressed their opinions about 
> it (which is fine).

This is not true. I suggested yesterday (in 
https://mail.python.org/archives/list/python-dev@python.org/message/DSZFE7XTRK2ESRJDPQPZIDP2I67E76WH/
 ) that PEP 649 could avoid making life worse for users of type annotations 
(relative to PEP 563) if it replaced runtime-undefined names with forward 
reference markers, as implemented in 
https://github.com/larryhastings/co_annotations/pull/3

Perhaps you've chosen to ignore the suggestion, but that's not the same as 
nobody suggesting any changes ;)

Carl

___
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/4LXOED3ABKDSNUDJ3JTNEGTXD3R7TEWT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Larry Hastings]

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 suggested even minor changes.  Folks have just expressed 
their opinions about it (which is fine).


Still left to do: ping the project leads of some other static type 
analysis projects and see if they have any feedback to contribute.  Once 
the dust completely settles around the conversation here, I expect to 
formally submit the PEP, hopefully later this week.


Cheers,


//arry/

On 4/14/21 12:22 PM, Brett Cannon wrote:



On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum > wrote:


Let's just wait for the SC to join the discussion. I'm sure they
will, eventually.


FYI the PEP has not been sent to us via 
https://github.com/python/steering-council/issues 
 as ready for 
pronouncement, so we have not started officially discussing this PEP yet.


-Brett


On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings
mailto:la...@hastings.org>> wrote:

On 4/14/21 10:44 AM, Guido van Rossum wrote:

besides the cost of closing the door to relaxed annotation
syntax, there's the engineering work of undoing the work that
was done to make `from __future__ import annotations` the
default (doing this was a significant effort spread over many
commits, and undoing will be just as hard).



I'm not sure either of those statements is true.

Accepting PEP 649 as written would deprecate stringized
annotations, it's true.  But the SC can make any decision it
wants here, including only accepting the new semantics of 649
without deprecating stringized annotations.  They could remain
in the language for another release (or two? or three?) while
we "kick the can down the road". This is not without its costs
too but it might be the best approach for now.

As for undoing the effort to make stringized annotations the
default, git should do most of the heavy lifting here. 
There's a technique where you check out the revision that made
the change, generate a reverse patch, apply it, and check that
in.  This creates a new head which you then merge. That's what
I did when I created my co_annotations branch, and at the time
it was literally the work of ten minutes.  I gather the list
of changes is more substantial now, so this would have to be
done multiple times, and it may be more involved.  Still, if
PEP 649 is accepted, I would happily volunteer to undertake
this part of the workload.


Cheers,


//arry/

___
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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/


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/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/


Code of Conduct: http://python.org/psf/codeofconduct/


___
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/MZNDSJ2Z5M6VXHBHWPOD2HYUQI72KGX2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Brett Cannon]

On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum  wrote:

> Let's just wait for the SC to join the discussion. I'm sure they will,
> eventually.
>

FYI the PEP has not been sent to us via
https://github.com/python/steering-council/issues as ready for
pronouncement, so we have not started officially discussing this PEP yet.

-Brett


>
> On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings 
> wrote:
>
>> On 4/14/21 10:44 AM, Guido van Rossum wrote:
>>
>> besides the cost of closing the door to relaxed annotation syntax,
>> there's the engineering work of undoing the work that was done to make
>> `from __future__ import annotations` the default (doing this was a
>> significant effort spread over many commits, and undoing will be just as
>> hard).
>>
>>
>> I'm not sure either of those statements is true.
>>
>> Accepting PEP 649 as written would deprecate stringized annotations, it's
>> true.  But the SC can make any decision it wants here, including only
>> accepting the new semantics of 649 without deprecating stringized
>> annotations.  They could remain in the language for another release (or
>> two? or three?) while we "kick the can down the road".  This is not without
>> its costs too but it might be the best approach for now.
>>
>> As for undoing the effort to make stringized annotations the default, git
>> should do most of the heavy lifting here.  There's a technique where you
>> check out the revision that made the change, generate a reverse patch,
>> apply it, and check that in.  This creates a new head which you then
>> merge.  That's what I did when I created my co_annotations branch, and at
>> the time it was literally the work of ten minutes.  I gather the list of
>> changes is more substantial now, so this would have to be done multiple
>> times, and it may be more involved.  Still, if PEP 649 is accepted, I would
>> happily volunteer to undertake this part of the workload.
>>
>>
>> Cheers,
>>
>>
>> */arry*
>> ___
>> 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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/
>> 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/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/7LXQATCTABW7HCSAUGAGFRJFFRLW5DVU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Barry Warsaw]

On Apr 13, 2021, at 22:40, Christopher Barker  wrote:
> 
> Turns out this was suggested in PEP 396 -- and deferred almost 13 years ago!
> 
> https://www.python.org/dev/peps/pep-0396/

I’d forgotten that this PEP was in Deferred state.  I think it should be 
rejected and I plan on making that change.  importlib.metadata is a much better 
approach to programmatically determining package versions.

https://docs.python.org/3/library/importlib.metadata.html#distribution-versions

-Barry




signature.asc
Description: Message signed with OpenPGP
___
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/GPDDGSO5JJDMNYCGVEUIUXFHPESVTUVH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

Let's just wait for the SC to join the discussion. I'm sure they will,
eventually.

On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings  wrote:

> On 4/14/21 10:44 AM, Guido van Rossum wrote:
>
> besides the cost of closing the door to relaxed annotation syntax, there's
> the engineering work of undoing the work that was done to make `from
> __future__ import annotations` the default (doing this was a significant
> effort spread over many commits, and undoing will be just as hard).
>
>
> I'm not sure either of those statements is true.
>
> Accepting PEP 649 as written would deprecate stringized annotations, it's
> true.  But the SC can make any decision it wants here, including only
> accepting the new semantics of 649 without deprecating stringized
> annotations.  They could remain in the language for another release (or
> two? or three?) while we "kick the can down the road".  This is not without
> its costs too but it might be the best approach for now.
>
> As for undoing the effort to make stringized annotations the default, git
> should do most of the heavy lifting here.  There's a technique where you
> check out the revision that made the change, generate a reverse patch,
> apply it, and check that in.  This creates a new head which you then
> merge.  That's what I did when I created my co_annotations branch, and at
> the time it was literally the work of ten minutes.  I gather the list of
> changes is more substantial now, so this would have to be done multiple
> times, and it may be more involved.  Still, if PEP 649 is accepted, I would
> happily volunteer to undertake this part of the workload.
>
>
> Cheers,
>
>
> */arry*
> ___
> 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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/
> 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/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

On Wed, Apr 14, 2021 at 11:03 AM Paul Bryan  wrote:

> What would you expect get_type_hints(...) to return with relaxed syntax?
> Today, for type hint annotations, it returns a type, which I'd argue is an
> important feature to preserve (in it or some successor).
>

It would have to return some other representation. Presumably the (purely
hypothetical) new syntax would be syntactic sugar for something that can be
expressed as an object, just like (as of PEP 604) X | Y is syntactic sugar
for Union[X, Y].

-- 
--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/Z4D4WUCLWUVO53EAKIY2WMCRL5MMZ6GD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[j . wuttke]

If the so, then a better name than NO_TIMESTAMP should be chosen, as the gzip 
specification does not allow for no timestamp.
___
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/O3ENOZ5OAFYX6PBXMEDGS3RJ3OSPKNYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[Michał Górny]

On Wed, 2021-04-14 at 18:06 +, j.wut...@fz-juelich.de wrote:
> The gzip specification [1] makes clear that the mtime field is always present.
> The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan.  1, 1970.
> MTIME = 0 means no time stamp is available. Hence no need for a
> new constant NO_TIMESTAMP.
> 
> So this is primarily a documentation problem [2]. For this, I will create a
> pull request to gzip.py.

I think having an extra constant (equal to 0) wouldn't hurt and could
make the code a bit more explicit.

-- 
Best regards,
Michał Górny


___
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/KK7J5GZTAR5NKNNN7BGRHZYEP3CWZTPM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[j . wuttke]

The gzip specification [1] makes clear that the mtime field is always present.
The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan.  1, 1970.
MTIME = 0 means no time stamp is available. Hence no need for a
new constant NO_TIMESTAMP.

So this is primarily a documentation problem [2]. For this, I will create a
pull request to gzip.py.

Joachim

[1] https://www.ietf.org/rfc/rfc1952.txt
[2] 
https://discuss.python.org/t/gzip-py-allow-deterministic-compression-without-time-stamp
___
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/LCPWERWIFG4AJS6DPHNEMOGBYJ2APDJ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Larry Hastings]

On 4/14/21 10:44 AM, Guido van Rossum wrote:
besides the cost of closing the door to relaxed annotation syntax, 
there's the engineering work of undoing the work that was done to make 
`from __future__ import annotations` the default (doing this was a 
significant effort spread over many commits, and undoing will be just 
as hard).



I'm not sure either of those statements is true.

Accepting PEP 649 as written would deprecate stringized annotations, 
it's true.  But the SC can make any decision it wants here, including 
only accepting the new semantics of 649 without deprecating stringized 
annotations.  They could remain in the language for another release (or 
two? or three?) while we "kick the can down the road".  This is not 
without its costs too but it might be the best approach for now.


As for undoing the effort to make stringized annotations the default, 
git should do most of the heavy lifting here.  There's a technique where 
you check out the revision that made the change, generate a reverse 
patch, apply it, and check that in.  This creates a new head which you 
then merge.  That's what I did when I created my co_annotations branch, 
and at the time it was literally the work of ten minutes.  I gather the 
list of changes is more substantial now, so this would have to be done 
multiple times, and it may be more involved.  Still, if PEP 649 is 
accepted, I would happily volunteer to undertake this part of the workload.



Cheers,


//arry/

___
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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

What would you expect get_type_hints(...) to return with relaxed
syntax? Today, for type hint annotations, it returns a type, which I'd
argue is an important feature to preserve (in it or some successor).

On Wed, 2021-04-14 at 10:54 -0700, Guido van Rossum wrote:
> On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan  wrote:
> > I favour annotations for type hints; the writing's been on the wall
> > for some time. I think the necessary escape hatch for those using
> > it for other purposes should be Annotated[Any, ...] (or a similar,
> > nicer alternative).
> > 
> > Guido, one of the difficulties I'm having is understanding the
> > direction you're going with "relaxed syntax". PEP 649 is concrete;
> > it's hard to weigh its merits against the usability—even
> > feasibility—of incorporating an as yet undefined relaxed syntax.
> > 
> > At the end of the day, such syntax is going to have to be
> > represented in some structure. If one were to accept that
> > annotations are for type hints only, is the debate then the
> > difference between a Python type (which PEP 649 would yield) and
> > some other as yet undefined structure?  
> > 
> 
> 
> In `__annotations__` it would be a string, as currently implemented
> in the 3.10 alpha code. The string just might not be parsable as an
> expression.
> 
> In the AST, it will have to be a new node that just collects tokens
> and bracketed things; that could be an array of low-level tokens.
> 

___
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/AP6TJNGH5SKFX3H5EL2QWACYG3F7WQF7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan  wrote:

> I favour annotations for type hints; the writing's been on the wall for
> some time. I think the necessary escape hatch for those using it for other
> purposes should be Annotated[Any, ...] (or a similar, nicer alternative).
>
> Guido, one of the difficulties I'm having is understanding the direction
> you're going with "relaxed syntax". PEP 649 is concrete; it's hard to weigh
> its merits against the usability—even feasibility—of incorporating an as
> yet undefined relaxed syntax.
>
> At the end of the day, such syntax is going to have to be represented in
> some structure. If one were to accept that annotations are for type hints
> only, is the debate then the difference between a Python type (which PEP
> 649 would yield) and some other as yet undefined structure?
>

In `__annotations__` it would be a string, as currently implemented in the
3.10 alpha code. The string just might not be parsable as an expression.

In the AST, it will have to be a new node that just collects tokens and
bracketed things; that could be an array of low-level tokens.

-- 
--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/FKOKFK7CPMMQEIPNZYJS56J3U3KFCFJE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Paul Bryan]

I favour annotations for type hints; the writing's been on the wall for
some time. I think the necessary escape hatch for those using it for
other purposes should be Annotated[Any, ...] (or a similar, nicer
alternative).

Guido, one of the difficulties I'm having is understanding the
direction you're going with "relaxed syntax". PEP 649 is concrete; it's
hard to weigh its merits against the usability—even feasibility—of
incorporating an as yet undefined relaxed syntax.

At the end of the day, such syntax is going to have to be represented
in some structure. If one were to accept that annotations are for type
hints only, is the debate then the difference between a Python type
(which PEP 649 would yield) and some other as yet undefined structure?
 

Paul


On Wed, 2021-04-14 at 10:24 -0700, Guido van Rossum wrote:
> On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings 
> wrote:
> > 
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> > 
> > > On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings
> > >  wrote:
> > > 
> > > > 
> > > > On 4/12/21 7:24 PM, Guido van Rossum wrote:
> > > > 
> > > > > I've been thinking about this a bit, and I think that the way
> > > > > forward is for Python to ignore the text of annotations
> > > > > ("relaxed annotation syntax"), not to try and make it
> > > > > available as an expression.
> > > > > 
> > > > > To be honest, the most pressing issue with annotations is the
> > > > > clumsy way that type variables have to be introduced. The
> > > > > current convention, `T = TypeVar('T')`, is both verbose (why
> > > > > do I have to repeat the name?) and widely misunderstood (many
> > > > > help request for mypy and pyright follow from users making a
> > > > > mistaken association between two type variables that are
> > > > > unrelated but share the same TypeVar definition). And relaxed
> > > > > annotation syntax alone doesn't solve this.
> > > > > 
> > > > > Nevertheless I think that it's time to accept that
> > > > > annotations are for types -- the intention of PEP 3107 was to
> > > > > experiment with different syntax and semantics for types, and
> > > > > that experiment has resulted in the successful adoption of a
> > > > > specific syntax for types that is wildly successful.
> > > > 
> > > > I don't follow your reasoning.  I'm glad that type hints have
> > > > found success, but I don't see why that implies "and therefore
> > > > we should restrict the use of annotations solely for type
> > > > hints".  Annotations are a useful, general-purpose feature of
> > > > Python, with legitimate uses besides type hints.  Why would it
> > > > make Python better to restrict their use now?
> > > > 
> > > 
> > > Because typing is, to many folks, a Really Important Concept, and
> > > it's confusing to use the same syntax ("x: blah blah") for
> > > different purposes, in a way that makes it hard to tell whether a
> > > particular "blah blah" is meant as a type or as something else --
> > > because you have to know what's introspecting the annotations
> > > before you can tell. And that introspection could be signalled by
> > > a magical decorator, but it could also be implicit: maybe you
> > > have a driver that calls a function based on a CLI entry point
> > > name, and introspects that function even if it's not decorated.
> > 
> > I'm not sure I understand your point.  Are you saying that we need
> > to take away the general-purpose functionality of annotations,
> > that's been in the language since 3.0, and restrict annotations to
> > just type hints... because otherwise an annotation might not be
> > used for a type hint, and then the programmer would have to figure
> > out what it means?  We need to take away the functionality from all
> > other use cases in order to lend clarity to one use case?
> > 
> 
> 
> Yes, that's how I see it.
> 
> And before you get too dramatic about it, the stringification of
> annotations has been in the making a long time, with the community's
> and the SC's support. You came up with a last-minute attempt to
> change it, using the PEP process to propose to *revert* the decision
> already codified in PEP 563 and implemented in the master branch. But
> you've waited until the last minute (feature freeze is in three
> weeks) and IMO you're making things awkward for the SC (who can and
> will speak for themselves).
>  
> > Also, if you're stating that programmers get confused reading
> > source code because annotations get used for different things at
> > different places--surely that confirms that annotations are useful
> > for more than just type hints, in real-world code, today.
> > 
> 
> No, it doesn't, it's just a hypothetical that they *would* be
> confused if there *were* other uses. Personally I haven't used any
> libraries that use non-type-hint annotations, but I've been told they
> exist.
> 
> > I genuinely have no sense of how important static type analysis is
> > in Python--personally I have no need for it--but I find it hard to
> > believe that type hints 

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

On Wed, Apr 14, 2021 at 9:42 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hi,
>
> tl;dr: imho the like or dislike of PEP 563 is related to whether people
> intend to learn a second syntax for typing, or would rather ignore it;
> both groups should be taken into account.
>
> Le 13/04/2021 à 19:30, Guido van Rossum a écrit :
> > On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello
> >  > > wrote:
> >
> > Then, what's wrong with quoting? It's just 2 characters, and prevent
> the
> > user (or their IDE) from trying to parse them as Python syntax.
> >
> >
> > Informal user research has shown high resistance to quoting.
>
> OK, but why? I'd bet it's due to an "aesthetic" concern: for typing
> users, type hints are code, not textual data. So it irks them to see
> them quoted and syntax-highlighted as text strings.
>

No, what I heard is that, since in *most* cases the string quotes are not
needed, people are surprised and annoyed when they encounter cases where
they are needed. And if you have a large code base it takes an expensive
run of the static type checker to find out that you've forgotten the quotes.


> > As a comparison: docstrings do get quoting, even though they also
> have
> > special semantics in the language.
> >
> >
> > Not the same thing. Docstrings use English, which has no formal (enough)
> > syntax. The idea for annotations is that they *do* have a formal syntax,
> > it just evolves separately from that of Python itself.
>
> If I may say it in my words: to both the parser and (more importantly)
> typing-savvy developers, type hints are code. I now see the point.
>
> But what about developers who won't learn this (future) incompatible
> typing syntax, and only encounter it in the wild? To them, those
> annotations are akin to docstrings: pieces of textual data that Python
> manages specially because of their role in the greater ecosystem, but
> that they can ignore because the program behavior is not modified.
>
> So it will irk them if annotations in this new syntax are not quoted or
> otherwise made distinguishable from code written in the normal Python
> syntax they understand. Again the "aesthetic" concern, and imho it
> explains in large part why some people dislike PEP 563.
>

They will treat it as anything else they don't quite understand -- they
will ignore it unless it bites them. And the rule for finding the end of an
annotation would be very simple -- just skip words until the next comma,
close paren or colon, skipping matching brackets etc.

Certainly I use this strategy all the time for quickly skimming code (in
any language) that I don't need to completely understand -- "oh, this is
where the parameters are processed, this is where the defaults are sorted
out, and this is where the work is being done; and since I'm investigating
why the default is weird, let me look at that part of the code in more
detail."


> Can the needs of both groups of developers be addressed? Could code in
> the new typing syntax be marked with a specific syntactic marker,
> distinguishing it from both normal Python syntax and text strings? Then
> this new marker could also be used outside of annotations, to mark
> analysis-time-only imports or statements?
>

There already is a special marker for annotations in function definitions
-- for arguments, it's the colon following the parameter name, and for
return types, it's the arrow after the parameter list. And for variable
declarations ("x: int") the same colon also suffices.

The idea to use the same marker for other analysis-time code is
interesting, but the syntactic requirements are somewhat different --
annotations live at the "expression" level (informally speaking) and are
already in a clearly indicated syntactic position -- analysis-time code
looks just like other code and can occur in any position where statements
can appear. So an appropriate marker would probably be an if-statement with
a special condition, like "if TYPE_CHECKING" (I am all for making that a
built-in constant, BTW).

If you were thinking of backticks, sorry, I'm not biting. (There are folks
who have other plans for those -- presumably because it's one of the few
ASCII characters that currently has no meaning.)


> Or is this all not worth the expense, and typing syntax can manage to
> stay compatible with normal Python syntax, in which case PEP 649 is the
> way to go?
>

I don't see much expense in the proposal to relax the syntax, and I see
benefits for new kinds of type annotations (e.g. PEP 647 would have
benefited).

And certainly PEP 649 has considerable cost as well -- besides the cost of
closing the door to relaxed annotation syntax, there's the engineering work
of undoing the work that was done to make `from __future__ import
annotations` the default (doing this was a significant effort spread over
many commits, and undoing will be just as hard). And we would still have to
support stringification 

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Brett Cannon]

On Tue, Apr 13, 2021 at 6:58 PM Inada Naoki  wrote:

> On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings 
> wrote:
> >
> >
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> >
> >
> > Because typing is, to many folks, a Really Important Concept, and it's
> confusing to use the same syntax ("x: blah blah") for different purposes,
> in a way that makes it hard to tell whether a particular "blah blah" is
> meant as a type or as something else -- because you have to know what's
> introspecting the annotations before you can tell. And that introspection
> could be signalled by a magical decorator, but it could also be implicit:
> maybe you have a driver that calls a function based on a CLI entry point
> name, and introspects that function even if it's not decorated.
> >
> >
> > I'm not sure I understand your point.  Are you saying that we need to
> take away the general-purpose functionality of annotations, that's been in
> the language since 3.0, and restrict annotations to just type hints...
> because otherwise an annotation might not be used for a type hint, and then
> the programmer would have to figure out what it means?  We need to take
> away the functionality from all other use cases in order to lend clarity to
> one use case?
> >
>
> I don't think we need to take away "general purpose functionality".
> But if we define type hinting is 1st class use case of annotations,
> annotations should be optimized for type hinting.  General purpose use
> case should accept some limitation and overhead.
>
> On the other hand, if we decide general purpose functionality is 1st
> class too, we shouldn't annotation syntax different from Python
> syntax.
>

Has anyone reached out to people like Pydantic, FastAPI, typer, etc. to see
what they think of this PEP? For instance, are they having issues with the
way things are today enough that this is a very clear win for them?

-Brett


>
> But annotations should be optimized for type hinting anyway. General
> purpose use case used only is a limited part of application. On the
> other hand, type hint can be used almost everywhere in application
> code base. It must cheap enough.
>
> Regards,
>
> --
> Inada Naoki  
> ___
> 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/UGFWTZUGH6QZRHF3FKTQHZLYG2ZNX5EG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/YKVYJMLUWUVT4KMLUNEQYVBZWNAPR4GV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings  wrote:

>
> On 4/13/21 1:52 PM, Guido van Rossum wrote:
>
> On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings 
> wrote:
>
>>
>> On 4/12/21 7:24 PM, Guido van Rossum wrote:
>>
>> I've been thinking about this a bit, and I think that the way forward is
>> for Python to ignore the text of annotations ("relaxed annotation syntax"),
>> not to try and make it available as an expression.
>>
>> To be honest, the most pressing issue with annotations is the clumsy way
>> that type variables have to be introduced. The current convention, `T =
>> TypeVar('T')`, is both verbose (why do I have to repeat the name?) and
>> widely misunderstood (many help request for mypy and pyright follow from
>> users making a mistaken association between two type variables that are
>> unrelated but share the same TypeVar definition). And relaxed annotation
>> syntax alone doesn't solve this.
>>
>> Nevertheless I think that it's time to accept that annotations are for
>> types -- the intention of PEP 3107 was to experiment with different syntax
>> and semantics for types, and that experiment has resulted in the successful
>> adoption of a specific syntax for types that is wildly successful.
>>
>>
>> I don't follow your reasoning.  I'm glad that type hints have found
>> success, but I don't see why that implies "and therefore we should restrict
>> the use of annotations solely for type hints".  Annotations are a useful,
>> general-purpose feature of Python, with legitimate uses besides type
>> hints.  Why would it make Python better to restrict their use now?
>>
>
> Because typing is, to many folks, a Really Important Concept, and it's
> confusing to use the same syntax ("x: blah blah") for different purposes,
> in a way that makes it hard to tell whether a particular "blah blah" is
> meant as a type or as something else -- because you have to know what's
> introspecting the annotations before you can tell. And that introspection
> could be signalled by a magical decorator, but it could also be implicit:
> maybe you have a driver that calls a function based on a CLI entry point
> name, and introspects that function even if it's not decorated.
>
>
> I'm not sure I understand your point.  Are you saying that we need to take
> away the general-purpose functionality of annotations, that's been in the
> language since 3.0, and restrict annotations to just type hints... because
> otherwise an annotation might not be used for a type hint, and then the
> programmer would have to figure out what it means?  We need to take away
> the functionality from all other use cases in order to lend *clarity* to
> one use case?
>

Yes, that's how I see it.

And before you get too dramatic about it, the stringification of
annotations has been in the making a long time, with the community's and
the SC's support. You came up with a last-minute attempt to change it,
using the PEP process to propose to *revert* the decision already codified
in PEP 563 and implemented in the master branch. But you've waited until
the last minute (feature freeze is in three weeks) and IMO you're making
things awkward for the SC (who can and will speak for themselves).


> Also, if you're stating that programmers get confused reading source code
> because annotations get used for different things at different
> places--surely that confirms that annotations are *useful* for more than
> just type hints, in real-world code, today.
>

No, it doesn't, it's just a hypothetical that they *would* be confused if
there *were* other uses. Personally I haven't used any libraries that use
non-type-hint annotations, but I've been told they exist.

I genuinely have no sense of how important static type analysis is in
> Python--personally I have no need for it--but I find it hard to believe
> that type hints are so overwhelmingly important that they should become the
> sole use case for annotations, and we need to take away this long-standing
> functionality, that you suggest is being successfully used side-by-side
> with type hints today, merely to make type hints clearer.
>

For projects and teams that use type hints, they are *very* important. For
example, they are so important to the Instagram team at Facebook that they
wrote their own static type checker when they found mypy wasn't fast enough
for their million-line codebase. And of course they were so important to
Dropbox that they sponsored a multi-year, multi-person effort to create
mypy in the first place. The amount of feedback we've received for mypy
indicates that it's not just those two companies that are using type hints.

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

[Python-Dev] Re: Typing syntax and ecosystem

[Hugh Fisher]

> Date: Wed, 14 Apr 2021 11:24:12 +0200
> From: Antoine Pitrou 
> Subject: [Python-Dev] Re: Typing syntax and ecosystem
>
> Can you explain why you think C++ typing is based on structural
> equivalence?

I'd rather not have a detailed discussion of C++ typing on python-dev.

My example was Ada style type equivalence by name only, in contrast
to Java/C++ style type checking which AFAIK is called "structural
equivalence". But if you use another term, it won't matter.

My point is that sometimes people have argued that the type checker
shouldn't be part of the Python interpreter because we're not sure about
the best approach and need to have freedom to experiment. I don't
think that is still true. Some type system choices, such as equivalence by
name only, have already been effectively ruled out. And there's now so
much code already annotated assuming the Java/C++ style that I don't
think a different type scheme checking can replace it. We've chosen the
type scheme for Python (although there may be some fine details to do)
and now we're just working on the implementation aspects.

Travelling for a few days, so this is probably a good place to stop on.
Thank you everybody for responding.

-- 

cheers,
Hugh Fisher
___
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/QRTERIPKB2QW6JB2CULRGT3CG3JX5FMO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Brett Cannon]

On Tue, Apr 13, 2021 at 5:12 PM Hugh Fisher  wrote:

> On Wed, 14 Apr 2021 at 08:21, Barry Warsaw  wrote:
> > I wouldn’t necessarily be opposed to bundling a type checker with the
> interpreter/stdlib, but I think there are some issues with it.  Just off
> the top of my head (there are undoubtedly many more issues to resolve):
> >
> > * Which type checker would we adopt or adapt, if any?
>
> Mypy.
> This has become an implementation issue, not one of which type
> system to adopt. A lot of code, even in the stdlib, has been annotated
> but I'm not aware of multiple different annotations with different
> semantics or type systems being created.
>

But there are feature concerns there as well, e.g. mypy and pytype offer
different "extras", even if the type checkers all align on semantics (which
I know they work on in the typing SIG). There's also variance in
maintenance, code complexity, etc. To me, this is not a clear-cut "mypy
wins" situation.

And I know Luciano said mypy because it's "the type checker hosted in the
python organization on github", but I don't know if the SC would approve
that today (Guido brought mypy into the org during his BDFL days), and
instead my guess is it would have ended up in the psf org like Black did.


>
> For example, type equivalence by name only is used in Ada (or was,
> it's been many years) and probably other languages. In equivalence
> by name, the following code would not pass the type checker.
> x : list[int]
> y : list[int]
> x = y # Type error
>
> But I'm not aware of anyone implementing type by name equivalence
> for Python, and the original PEP 483 seems to explicitly close off that
> possibility. Instead the assumption seems to be Java/C++ structural
> equivalence for types.
>
> Skimming a bunch of current type system related PEPs, I'm not seeing
> anything that a Java/C++ programmer would find unfamiliar. And this is
> probably a good thing.
>
> > * Which parts of the typing system require more frequent release cycles?
> > * Is there a core technology that could be put in the stdlib and still
> allow experimentation?
> > * Would the type checker authors become core developers?
> > * Do the same feature release / deprecation policies apply?
>
> No answers from me.
>

My guess is the closest we would ever come is some ensuretypechecker
situation like we have with ensurepip, but pip is done that way for
bootstrapping reasons and we don't *need *a type checker for bootstrapping.

-Brett


>
> > I would still be opposed to requiring type hinting in Python.
>
> I'm opposed to requiring type hints on everything, I want to still be
> able to write
> x = 1
> x = "hello"
> etc without declaring any kind of type for x.
>
> --
>
> cheers,
> Hugh Fisher
> ___
> 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/OABB53NTCBU6EKYQVVVY4IU2275XO4R4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/BVQAYB4N3JKHEJ5A6NPSBKT7OWQSYQ3K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[Victor Stinner]

Hi,

gzip.NO_TIMESTAMP sounds like a good idea. But I'm not sure about
changing the default behavior. I would prefer to leave it unchanged.

I guess that your problem is that you don't access gzip directly, but
uses a higher level API which doesn't give access to the timestamp
parameter, like the tarfile module?

If your usecase is reproducible build, you may follow py_compile
behavior: the default behavior depends if the SOURCE_DATE_EPOCH
environment variable is set or not:

def _get_default_invalidation_mode():
if os.environ.get('SOURCE_DATE_EPOCH'):
return PycInvalidationMode.CHECKED_HASH
else:
return PycInvalidationMode.TIMESTAMP

Victor

On Wed, Apr 14, 2021 at 6:34 PM Joachim Wuttke  wrote:
>
> gzip compression, using class GzipFile from gzip.py, by default
> inserts a timestamp to the compressed stream. If the optional
> argument `mtime` is absent or None, then the current time is used [1].
>
> This makes outputs non-deterministic, which can badly confuse
> unsuspecting users: If you run "diff" over two outputs to see
> whether they are unaffected by changes in your application,
> then you would not expect that the *.gz binaries differ just
> because they were created at different times.
>
> I'd propose to introduce a new constant `NO_TIMESTAMP` as
> possible value of `mtime`.
>
> Furthermore, if policy about API changes allows, I'd suggest
> that `NO_TIMESTAMP` become the new default value for `mtime`.
>
> How to proceed from here? Is this the kind of proposals that
> has to go through a PEP?
>
> - Joachim
>
> [1]
> https://github.com/python/cpython/blob/6f1e8ccffa5b1272a36a35405d3c4e4bbba0c082/Lib/gzip.py#L163
>
> ___
> 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/OTUGLATLYB736SAPPRWSSXWAKM5JHWZN/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/5FLBLVY3DJFGIBMED57SASLS5ASZ65KF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem, take 2

[Hugh Fisher]

>
> Date: Tue, 13 Apr 2021 19:55:38 -0400
> From: Ned Batchelder 
>
> In another message, you alluded to PEP 649 being a solution to run-time
> type checking.  Maybe I'm misunderstanding something: type annotations
> never do type checking at runtime.  As I understand it, PEP 649 is about
> avoiding the overhead of evaluating the type expression itself, not
> about checking the types of values.

Yes, and I see that as a problem. Here are two versions of code
V1
 # Apocalypse may occur if foo is not 
foo = "coconut"
V2
 # Apocalypse may occur if foo is not 
 foo :  = "coconut"

To the Python interpreter both have the same semantics and runtime
behaviour. But V2 has type annotations, which are effectively
syntactically constrained comments within individual statements. As
code they do absolutely nothing. However, the performance hit from
just being present is so great that talented programmers are working
hard to make the Python interpreter ... ignore them more efficiently.

-- 

cheers,
Hugh Fisher
___
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/A24AW5W2O5OEMFYZNIWWHZVDWM7HCJKV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[Brett Cannon]

On Wed, Apr 14, 2021 at 5:00 AM Joachim Wuttke 
wrote:

> gzip compression, using class GzipFile from gzip.py, by default
> inserts a timestamp to the compressed stream. If the optional
> argument `mtime` is absent or None, then the current time is used [1].
>
> This makes outputs non-deterministic, which can badly confuse
> unsuspecting users: If you run "diff" over two outputs to see
> whether they are unaffected by changes in your application,
> then you would not expect that the *.gz binaries differ just
> because they were created at different times.
>
> I'd propose to introduce a new constant `NO_TIMESTAMP` as
> possible value of `mtime`.
>
> Furthermore, if policy about API changes allows, I'd suggest
> that `NO_TIMESTAMP` become the new default value for `mtime`.
>
> How to proceed from here? Is this the kind of proposals that
> has to go through a PEP?
>

For something like this you would open an issue and see if a core developer
is intrigued enough to work with you to see the change occur; no PEP is
necessary.

-Brett


>
> - Joachim
>
> [1]
>
> https://github.com/python/cpython/blob/6f1e8ccffa5b1272a36a35405d3c4e4bbba0c082/Lib/gzip.py#L163
>
> ___
> 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/OTUGLATLYB736SAPPRWSSXWAKM5JHWZN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/Y2YFL25BF2LNT7VFSZALTZH5S57NA2J6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Eric V. Smith]

On 4/14/2021 12:38 PM, Christopher Barker wrote:



Anyway, the question now for me is whether this is worth any more of 
my time.


So:
- Is there someone willing to sponsor?
- Do folks generally think there's a chance of it being accepted 
without a huge debate and expansion of scope.


I think that before these can be answered, you need to decide why this 
needs to be standardized. I don't see any reason to standardize it 
unless there's some programmatic use for these version strings. If it's 
just the user poking around on the REPL, then I think the status quo is 
fine. I've read the PEP, and the User Stories section talks about user 
convenience, not programmatic access.


I also think the distribution version is more useful than any 
__version__ information in each module/package. I realize this 
information might not be available, depending on how the code was 
installed (say, just by copying some files into the right place).


Eric

___
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/7YUCFFNQ75T3SBPU3RLEXTQ7QPVVWI76/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker 
wrote:

> Another possible issue: using Version would require an extra import in
> many module initializations -- is that a performance issue that would
> matter?
>

I like having a `Version` object that is easily importable in the standard
library.  I think it should relatively polymorphic.  I.e. it should accept
a module or package as an argument, but also should accept a string or a
tuple.  Maybe other objects from which one could reasonably extract a
version.

In particular, I think initializing this object with a module object should
at least look for a .__version__ attribute, and appropriately case either a
string (that looks sufficiently version-like) or a tuple.  I think that if
it doesn't succeed, it should become some sort of "cannot determine" object
that is neither less than nor greater than any other Version object.  In
particular, the Vaex example with a dictionary of versions of each
component should probably just become this "cannot determine" value (but as
an instance of Version).

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/S6ZHCQ57ZH5OMLBQK5LWMZUTT7HEARPV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Christopher Barker]

On Wed, Apr 14, 2021 at 5:24 AM Victor Stinner  wrote:

> There are two main use cases for versions:
>
> * Display them to the user
> * Compare versions to check if one is newer, older or the same
>
> I dislike using strings for comparison. You need to use
> packaging.version for that:
> https://packaging.pypa.io/en/latest/version.html


Yes, though it looks a little too heavyweight to be required, nifty
features like ``is_prerelease` is going pretty far.

On the other hand, maybe no harm in all that, as long as:

- It's easy to do the easy stuff (which is looks like it is)
- It would be added to the stdlib

However, there is a lot of code out there that's already using strings for
__version__, so it would be a real shame if we had to ask everyone to
upgrade. And Version isn't going to be in older versions of the Python
stdlib, so hard to make code compatible.

But: If we make a Version object that can be compared to (confoming)
strings then there might be a path forward.


> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison: version_a <= version_b. Example:
>

Yes, and tuples are already built in to Python, so an easier lift than
adding the Version object.

Another possible issue: using Version would require an extra import in many
module initializations -- is that a performance issue that would matter?

In any case, I think the PEP should specify a standard for what is in
__version__

And ideally it would be backward compatible with strings, which are the
most commonly used currently.

And conform to PEP 440

Sadly, such tuple is no standardized. Which
> part is the major version? How to format it as a string?
>
> Good luck with trying to standardize that ;-)
>

well, PEP 440 gets us close -- and I *think* compliant strings could be
unambiguously converted to-from tuples.

Anyway, the question now for me is whether this is worth any more of my
time.

So:
- Is there someone willing to sponsor?
- Do folks generally think there's a chance of it being accepted without a
huge debate and expansion of scope.

If the answers are not yes, I can better spend my Python time of other
things.

BTW: one source of hope:

__version__ strings are pretty common, but, as evidenced already by this
brief discussion, it's not by any means a universal standard -- so we
really can't break anything that already works in any universal way.

What i mean by that is that anything done here might break someone's
special use case of __version__ (Like the one David Mertz identified), but
that scheme only works with that one package's code anyway. There are no
general tools that expect that scheme.

And it could be preserved by making a subclass of Version (Or str) that was
also a mapping :-)

- CHB



-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/QUJ6ESEXT2F3OWQIFG4ZFC4RT3CRRPCG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Baptiste Carvello]

Hi,

tl;dr: imho the like or dislike of PEP 563 is related to whether people
intend to learn a second syntax for typing, or would rather ignore it;
both groups should be taken into account.

Le 13/04/2021 à 19:30, Guido van Rossum a écrit :
> On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello
>  > wrote:
> 
> Then, what's wrong with quoting? It's just 2 characters, and prevent the
> user (or their IDE) from trying to parse them as Python syntax.
> 
> 
> Informal user research has shown high resistance to quoting.

OK, but why? I'd bet it's due to an "aesthetic" concern: for typing
users, type hints are code, not textual data. So it irks them to see
them quoted and syntax-highlighted as text strings.

> As a comparison: docstrings do get quoting, even though they also have
> special semantics in the language.
> 
> 
> Not the same thing. Docstrings use English, which has no formal (enough)
> syntax. The idea for annotations is that they *do* have a formal syntax,
> it just evolves separately from that of Python itself.

If I may say it in my words: to both the parser and (more importantly)
typing-savvy developers, type hints are code. I now see the point.

But what about developers who won't learn this (future) incompatible
typing syntax, and only encounter it in the wild? To them, those
annotations are akin to docstrings: pieces of textual data that Python
manages specially because of their role in the greater ecosystem, but
that they can ignore because the program behavior is not modified.

So it will irk them if annotations in this new syntax are not quoted or
otherwise made distinguishable from code written in the normal Python
syntax they understand. Again the "aesthetic" concern, and imho it
explains in large part why some people dislike PEP 563.

Can the needs of both groups of developers be addressed? Could code in
the new typing syntax be marked with a specific syntactic marker,
distinguishing it from both normal Python syntax and text strings? Then
this new marker could also be used outside of annotations, to mark
analysis-time-only imports or statements?

Or is this all not worth the expense, and typing syntax can manage to
stay compatible with normal Python syntax, in which case PEP 649 is the
way to go?

Cheers,
Baptiste
___
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/YI3DPTJXKTKZRVVWBJ6UYTUH3PPAJM6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] gzip.py: allow deterministic compression (without time stamp)

[Joachim Wuttke]

gzip compression, using class GzipFile from gzip.py, by default
inserts a timestamp to the compressed stream. If the optional
argument `mtime` is absent or None, then the current time is used [1].

This makes outputs non-deterministic, which can badly confuse
unsuspecting users: If you run "diff" over two outputs to see
whether they are unaffected by changes in your application,
then you would not expect that the *.gz binaries differ just
because they were created at different times.

I'd propose to introduce a new constant `NO_TIMESTAMP` as
possible value of `mtime`.

Furthermore, if policy about API changes allows, I'd suggest
that `NO_TIMESTAMP` become the new default value for `mtime`.

How to proceed from here? Is this the kind of proposals that
has to go through a PEP?

- Joachim

[1] 
https://github.com/python/cpython/blob/6f1e8ccffa5b1272a36a35405d3c4e4bbba0c082/Lib/gzip.py#L163




smime.p7s
Description: S/MIME Cryptographic Signature
___
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/OTUGLATLYB736SAPPRWSSXWAKM5JHWZN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Stéfane Fermigier]

I agree that showing support for type hints is important, as long as this
doesn't convey the counterproductive message that type hints have become
almost mandatory. They are useful in some circumstances, and less so
(specially when dealing with beginners or non-professional programmers) in
others.

I don't agree that mypy should become part of the standard lib.

1) It's already obvious that it's the prefered implementation (in Python -
there are at least 3 other implementations that are not written in Python
and/or not open source that have an impact on the market).

2) Mypy is already part of the Python organisation on GitHub, it's even one
of the 6 featured repositories (which means it probably has a top-level
status with the PSF).

3) But it has a release cycle that is shorter than Python. It hasn't even
reached 1.0 !

4) If we are to "commit all the way to supporting type hints", a first step
IMHO would be to type hint all the standard library. AFAICT, type hints for
the stdlib are currently supported in the typeshed project, which is also a
top-level project. But I have not checked if it covers 100% of the stdlib.

Also, one could argue that the stdlib type hints should live closer to the
stdlib itself, and have a release cycle aligned with that of the stdlib,
and that typeshed should be reserved for type hinting popular third-party
libraries.

Indeed, if there was a proposal to make, mine would be to do exactly this :)

  S.


On Tue, Apr 13, 2021 at 11:58 PM Luciano Ramalho 
wrote:

> Hugh was unfortunate in presenting the problem, but I agree that we
> should commit all the way to supporting type hints, and that means
> bundling a type checker as part of the standard library and
> distribution.
>
> There is always a delay after a Python release before Mypy catches up
> to—and that's the type checker hosted in the python organization on
> github.
>
> I believe this is an unfortunate state of affairs for many users. I am
> not aware of any other optionally typed language that underwent core
> changes to support type annotations and yet does not bundle a type
> checker.
>
> Cheers,
>
> Luciano
>
>
>
> On Mon, Apr 12, 2021 at 7:01 AM Hugh Fisher  wrote:
> >
> > > Message: 1
> > > Date: Sun, 11 Apr 2021 13:31:12 -0700
> > > From: Barry Warsaw 
> > > Subject: [Python-Dev] Re: PEP 647 Accepted
> >
> > >
> > > This is something the SC has been musing about, but as it’s not a
> fully formed idea, I’m a little hesitant to bring it up.  That said, it’s
> somewhat relevant: We wonder if it may be time to in a sense separate the
> typing syntax from Python’s regular syntax.  TypeGuards are a case where if
> typing had more flexibility to adopt syntax that wasn’t strictly legal
> “normal” Python, maybe something more intuitive could have been proposed.
> I wonder if the typing-sig has discussed this possibility (in the future,
> of course)?
> >
> > [ munch ]
> >
> > >
> > > Agreed.  It’s interesting that PEP 593 proposes a different approach
> to enriching the typing system.  Typing itself is becoming a little
> ecosystem of its own, and given that many Python users are still not fully
> embracing typing, maybe continuing to tie the typing syntax to Python
> syntax is starting to strain.
> >
> > I would really like to see either "Typed Python" become a different
> programming
> > language, or progress to building type checking into the CPython
> implementation
> > itself. (Python 4 seems to me the obvious release.) The current halfway
> approach
> > is confusing and slightly ridiculous.
> >
> > The first, a separate programming language, would be like RATFOR and
> CFront
> > in the past and TypeScript today. Typed Python can have whatever syntax
> the
> > designers want because it doesn't have to be compatible with Python,
> just as
> > TypeScript is not constrained by JavaScript. A type checker translates
> > the original
> > Typed Python source into "dynamic" or "classic" Python for execution.
> (Maybe
> > into .pyc instead of .py?)
> >
> > This would mean no overhead for type checking in CPython itself. No need
> to
> > contort the parser into ignoring bits of code that are, in effect,
> > syntax checked
> > comments. And for the typing in Python enthusiasts, you won't have to
> listen
> > to people like me complaining.
> >
> > The second approach is to assume that type checking in Python is useful
> and
> > popular. Not with me, but I'm willing to accept that I'm in the minority
> and can
> > be ignored - after all, I can still write my Python code without type
> > annotations.
> > If so running a type checker as a separate step, as we do at the moment,
> is
> > like asking C programmers to run the preprocessor by hand.
> >
> > In today's world of continuous build and integration, it seems silly
> > to me to have
> > a type checker read the source, scan into lexical tokens, build an
> > abstract syntax
> > tree, perform semantic analysis with type checking, and then throw it
> away
> > before running an 

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

Agreed!

I was trying to figure out why an API from Vaex 3.x was no longer working,
and to my human eye, this quickly pointed me at the issue.  However as a
way to automatically check for versions, this is a mess.  I have no idea
what additional keys the next version might add or remove, for example.
I'm not even sure if this is dynamically determined based on optional
components being installed or not.

Providing this kind of information *somehow* feels like a useful thing to
do.  But .__version__ is probably not the right way to do it.

On Wed, Apr 14, 2021 at 5:08 PM Christopher Barker 
wrote:

> On Wed, Apr 14, 2021 at 7:48 AM David Mertz  wrote:
>
>> >>> vaex.__version__
>> {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
>> '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
>> '0.6.0', 'vaex-ml': '0.11.1'}
>>
>
> Well, THAT is a great argument for some official standardization!
>
> There is sometimes a need for that sort of thing, but I think it's best
> handled by either putting __version__ in each sub_package, or having a
> different attribute altogether.
>
> -CHB
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/CWEX6QRKSB3E3IYHTPUMIMY6WCYIR7FK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Christopher Barker]

Simon,

I'm not sure your note made it to the list -- bringing it back on.

On Wed, Apr 14, 2021 at 1:15 AM Simon Cross 
wrote:

> I would be +1 on having a small PEP like this one to give __version__
> an official blessing and some well-defined expected behaviour.
>
> I don't have a deep opinion on the specifics of the specification, but
> I'm guessing they should be thought about again even if the answers
> end up being the same. Quite a lot has changed in the Python ecosystem
> in the last 13 years.
>

Yes indeed. Critically, over on the packaging side, standardization of
versioning specs.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/H3U7IFNOBWAZ7GFG3WIGCV4HNUFOUI64/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Christopher Barker]

On Wed, Apr 14, 2021 at 7:48 AM David Mertz  wrote:

> >>> vaex.__version__
> {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
> '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
> '0.6.0', 'vaex-ml': '0.11.1'}
>

Well, THAT is a great argument for some official standardization!

There is sometimes a need for that sort of thing, but I think it's best
handled by either putting __version__ in each sub_package, or having a
different attribute altogether.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/DAZGU7U7HU6TEBTM7DKRU2P4L5KBFY6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[David Mertz]

I recently encountered this, which is very useful, but only for a
human-readable perspective.

>>> import vaex
>>> vaex.__version__
{'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0', 'vaex-hdf5':
'0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0', 'vaex-jupyter':
'0.6.0', 'vaex-ml': '0.11.1'}



On Wed, Apr 14, 2021 at 2:01 PM Barney Gale  wrote:

> > In my Python projects, I like to provide the version as a tuple which
> > can be used directly for comparison
>
> To add to this, comparing tuples doesn't always work well for projects
> where multiple release lines are maintained simultaneously, e.g.
> user-facing changes introduced in minor/point releases across several major
> versions. People use version numbers in wildly different ways.
>
> Barney
>
> On Wed, 14 Apr 2021 at 13:26, Victor Stinner  wrote:
>
>> On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker 
>> wrote:
>> > So what do you'all think? After thirteen years, it would be nice to put
>> this to bed.
>>
>> There are two main use cases for versions:
>>
>> * Display them to the user
>> * Compare versions to check if one is newer, older or the same
>>
>> I dislike using strings for comparison. You need to use
>> packaging.version for that:
>> https://packaging.pypa.io/en/latest/version.html
>>
>> Many C libraries provide the version as a number of as 3 numbers
>> (major, minor, micro). In its C API, Python provides all of them:
>>
>> * PY_VERSION_HEX: single number
>> * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION,
>> PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers
>> * PY_VERSION: string
>>
>> In my Python projects, I like to provide the version as a tuple which
>> can be used directly for comparison: version_a <= version_b. Example:
>>
>> VERSION = (2, 2, 1)
>> __version__ = '.'.join(map(str, VERSION))
>>
>> The tuple might contain strings like "beta" or "rc", as soon as
>> comparison makes sense ;-) Sadly, such tuple is no standardized. Which
>> part is the major version? How to format it as a string?
>>
>> Good luck with trying to standardize that ;-)
>>
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> ___
>> 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/MBBYB5AWX76O3TOUFATRKSU2QND2TPKS/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/4XWIWIKDJJRWVKNGIOENJ2ZJVQR4PP23/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/YNQ2QSJ35B2IAAQ2YCTKH2NJYNQD4DZK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making staticmethod callable, any oposite?

[Mark Shannon]

On 14/04/2021 2:20 am, Inada Naoki wrote:

Hi, all.

I am implementing PEP 597. During review, Victor suggested to
deprecate `OpenWrapper`. `OpenWrapper` is defined only for
compatibility between C function and Python function:

```
from _pyio import open as py_open
from _io import open as c_open

class C:
 py_open = py_open
 c_open = c_open

C().c_open("README.rst")  # works
C().py_open("README.rst")  # TypeError: expected str, bytes or
os.PathLike object, not C
```

So builtin open is not io.open, but io.OpenWrapper in Python 3.9.
Making staticfunction callable fixes this issue.

```
@staticfunction
def open(...): ...
```

Now open defined in Python behaves like C function. We don't need
OpenWrapper anymore.
This has already been committed by Guido's approval. staticmethod is
callable, and OpenWrapper is just an alias of open and deprecated in
master branch.

But Mark Shannon said we shouldn't make such a change without
discussing at python-dev.
I don't know we *should*, but I agree that it is *ideal*.

Then, does anyone oppose this change?


I do (although not strongly).

I think we are changing the wrong thing.

Sometimes code gets moved from C to Python and vice-versa.
The differences in descriptor behavior between builtin function and 
Python functions trips people up. We agree on that.


However I don't think changing the behavior of static methods is the way 
to fix that.


A staticmethod is not a function, builtin or otherwise. It is a method 
that, when called, ignores the object it is attached to.


If we want Python functions to behave like a builtin function, then 
marking them `@staticmethod` is misleading, IMO.


I'm also worried about corner cases where this change in behavior will 
break code.


I'm all in favor of replacing C code with Python and don't want to make 
it difficult.

So, why not add a new descriptor, that clearly describes the intent:

`@non_method` or just `@function`?

The decorator would make a new object that behaves like a 
builtin-function, even though it is implemented in Python.


Cheers,
Mark.

___
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/WRHFP4FKWCCJWOU2JTRVFXB6LSFRATKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Larry Hastings]

On 4/12/21 7:24 PM, Guido van Rossum wrote:
To be honest, the most pressing issue with annotations is the clumsy 
way that type variables have to be introduced. The current convention, 
`T = TypeVar('T')`, is both verbose (why do I have to repeat the 
name?) and widely misunderstood (many help request for mypy and 
pyright follow from users making a mistaken association between two 
type variables that are unrelated but share the same TypeVar definition).



This repeat-the-name behavior has been in Python for a long time, e.g.

   Point = namedtuple('Point', ['x', 'y'])

namedtuple() shipped with Python 2.6 in 2008.  So if that's the most 
pressing issue with annotations, annotations must be going quite well, 
because we've known about this for at least 13 years without attempting 
to solve it.


I've always assumed that this repetition was worth the minor 
inconvenience.  You only have to retype the name once, and the resulting 
code is clear and readable, with predictable behavior. A small price to 
pay to preserve Python's famous readability.



For what it's worth--and forgive me for straying slightly into 
python-ideas territory--/if/ we wanted to eliminate the need to repeat 
the name, I'd prefer a general-purpose solution rather than something 
tailored specifically for type hints.  In a recent private email 
conversation on a different topic, I proposed this syntax:


   bind  

This statement would be equivalent to

   id = expression('id')


Cheers,


//arry/

___
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/L5EBHWHUOQZDW33FH5VI2D6KFN75LLVW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Guido van Rossum]

It looks like a small subset of PEP 484, syntactically. So it should be
fine. Possibly cython might be interested in using a relaxed notation if it
is ever introduced, e.g. ‘long long’ or ‘static int’ (for a return type)?

On Wed, Apr 14, 2021 at 02:27 Antoine Pitrou  wrote:

>
> For the record, Cython allows using annotations for typing:
>
> https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#pep-484-type-annotations
>
> I don't know if they are fully compatible with the type hints we're
> talking about here.
>
> Regards
>
> Antoine.
>
>
> On Wed, 14 Apr 2021 10:58:07 +0900
> Inada Naoki  wrote:
> > On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings 
> wrote:
> > >
> > >
> > > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> > >
> > >
> > > Because typing is, to many folks, a Really Important Concept, and it's
> confusing to use the same syntax ("x: blah blah") for different purposes,
> in a way that makes it hard to tell whether a particular "blah blah" is
> meant as a type or as something else -- because you have to know what's
> introspecting the annotations before you can tell. And that introspection
> could be signalled by a magical decorator, but it could also be implicit:
> maybe you have a driver that calls a function based on a CLI entry point
> name, and introspects that function even if it's not decorated.
> > >
> > >
> > > I'm not sure I understand your point.  Are you saying that we need to
> take away the general-purpose functionality of annotations, that's been in
> the language since 3.0, and restrict annotations to just type hints...
> because otherwise an annotation might not be used for a type hint, and then
> the programmer would have to figure out what it means?  We need to take
> away the functionality from all other use cases in order to lend clarity to
> one use case?
> > >
> >
> > I don't think we need to take away "general purpose functionality".
> > But if we define type hinting is 1st class use case of annotations,
> > annotations should be optimized for type hinting.  General purpose use
> > case should accept some limitation and overhead.
> >
> > On the other hand, if we decide general purpose functionality is 1st
> > class too, we shouldn't annotation syntax different from Python
> > syntax.
> >
> > But annotations should be optimized for type hinting anyway. General
> > purpose use case used only is a limited part of application. On the
> > other hand, type hint can be used almost everywhere in application
> > code base. It must cheap enough.
> >
> > Regards,
> >
>
>
>
> ___
> 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/VJWVKMQFAOMYNORX3F4557KWINO4Z7GG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/5FA2AEILDTSWYPFSSGPIJC734PFNZNKB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making staticmethod callable, any oposite?

[Ethan Furman]

On 4/13/21 6:20 PM, Inada Naoki wrote:


Then, does anyone oppose this change?


Having staticmethod, etc., be callable would make my code much easier in at 
least two different projects.

Please make this change.

--
~Ethan~
___
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/U6PSB4NEI4UI3PSOE63CQHBFIP5X555L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Barney Gale]

> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison

To add to this, comparing tuples doesn't always work well for projects
where multiple release lines are maintained simultaneously, e.g.
user-facing changes introduced in minor/point releases across several major
versions. People use version numbers in wildly different ways.

Barney

On Wed, 14 Apr 2021 at 13:26, Victor Stinner  wrote:

> On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker 
> wrote:
> > So what do you'all think? After thirteen years, it would be nice to put
> this to bed.
>
> There are two main use cases for versions:
>
> * Display them to the user
> * Compare versions to check if one is newer, older or the same
>
> I dislike using strings for comparison. You need to use
> packaging.version for that:
> https://packaging.pypa.io/en/latest/version.html
>
> Many C libraries provide the version as a number of as 3 numbers
> (major, minor, micro). In its C API, Python provides all of them:
>
> * PY_VERSION_HEX: single number
> * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION,
> PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers
> * PY_VERSION: string
>
> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison: version_a <= version_b. Example:
>
> VERSION = (2, 2, 1)
> __version__ = '.'.join(map(str, VERSION))
>
> The tuple might contain strings like "beta" or "rc", as soon as
> comparison makes sense ;-) Sadly, such tuple is no standardized. Which
> part is the major version? How to format it as a string?
>
> Good luck with trying to standardize that ;-)
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/MBBYB5AWX76O3TOUFATRKSU2QND2TPKS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/4XWIWIKDJJRWVKNGIOENJ2ZJVQR4PP23/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Paul Moore]

On Wed, 14 Apr 2021 at 13:28, Victor Stinner  wrote:
> There are two main use cases for versions:
>
> * Display them to the user
> * Compare versions to check if one is newer, older or the same
>
> I dislike using strings for comparison. You need to use
> packaging.version for that:
> https://packaging.pypa.io/en/latest/version.html

Agreed, programmatic use should really conform to PEP 440 versioning,
as implemented in packaging.version, if it's to align with existing
packaging standards (which currently focus on *project* versions
rather than package versions, but the distinction is not something we
should be making a big deal of).

> Many C libraries provide the version as a number of as 3 numbers
> (major, minor, micro). In its C API, Python provides all of them:
>
> * PY_VERSION_HEX: single number
> * (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION,
> PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers
> * PY_VERSION: string
>
> In my Python projects, I like to provide the version as a tuple which
> can be used directly for comparison: version_a <= version_b. Example:
>
> VERSION = (2, 2, 1)
> __version__ = '.'.join(map(str, VERSION))
>
> The tuple might contain strings like "beta" or "rc", as soon as
> comparison makes sense ;-) Sadly, such tuple is no standardized. Which
> part is the major version? How to format it as a string?
>
> Good luck with trying to standardize that ;-)

Agreed. We should stick to PEP 440 format strings, and not try to
dictate other formats like (named) tuples.

But does the PEP want to cover programmatic use *at all*? It would be
possible to define __version__ as "a human-readable string in PEP 440
format" and note that any use other than for display to a person is
outside the scope of the PEP. That's closer in spirit to the 13-year
old version we currently have, but it does miss an opportunity as we
now do have a standard version class ("standard" in the sense of "a
packaging standard", but not "in the stdlib").

Paul
___
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/5LFCLXIPXF3PO6PZ5ZLS7TD2OE4U35OD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

[Victor Stinner]

On Wed, Apr 14, 2021 at 7:48 AM Christopher Barker  wrote:
> So what do you'all think? After thirteen years, it would be nice to put this 
> to bed.

There are two main use cases for versions:

* Display them to the user
* Compare versions to check if one is newer, older or the same

I dislike using strings for comparison. You need to use
packaging.version for that:
https://packaging.pypa.io/en/latest/version.html

Many C libraries provide the version as a number of as 3 numbers
(major, minor, micro). In its C API, Python provides all of them:

* PY_VERSION_HEX: single number
* (PY_MAJOR_VERSION, PY_MINOR_VERSION, PY_MICRO_VERSION,
PY_RELEASE_LEVEL, PY_RELEASE_SERIAL): as 5 numbers
* PY_VERSION: string

In my Python projects, I like to provide the version as a tuple which
can be used directly for comparison: version_a <= version_b. Example:

VERSION = (2, 2, 1)
__version__ = '.'.join(map(str, VERSION))

The tuple might contain strings like "beta" or "rc", as soon as
comparison makes sense ;-) Sadly, such tuple is no standardized. Which
part is the major version? How to format it as a string?

Good luck with trying to standardize that ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/MBBYB5AWX76O3TOUFATRKSU2QND2TPKS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Boundaries between numbers and identifiers

[Victor Stinner]

Also, would it be possible to enhance to tokenizer to report a
SyntaxWarning, rather than a SyntaxError?

Victor
___
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/CH7SLXKIKX47KVCWEJEMOB35BCIM7Y5U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 0xfor 3. Parser bug?

[Serhiy Storchaka]

14.04.21 13:22, Stefano Borini пише:
> This was just posted on SO
> 
> https://stackoverflow.com/questions/67083039/why-does-python-return-15-for-0xfor-x-in-1-2-3
> 
> I can reproduce it with a simpler example
> 
 0xfor 3
> 15
> 
> Is it a bug in the parser, or working as intended? It's not only for
> hex. This works to
> 
 3or 50
> 3
> 
> 
> 

It is already discussed in thread >
https://mail.python.org/archives/list/python-dev@python.org/thread/D2WPCITHG2LBQAP7DBTC6CY26WQUBAKP/

It does not contradict specification, but looks pretty confusing, so we
will likely change specification and implementation to prevent confusion.

___
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/QODMSOOHZFGL7HL4VDAKZMZ23RPYTIQO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] 0xfor 3. Parser bug?

[Stefano Borini]

This was just posted on SO

https://stackoverflow.com/questions/67083039/why-does-python-return-15-for-0xfor-x-in-1-2-3

I can reproduce it with a simpler example

>>> 0xfor 3
15

Is it a bug in the parser, or working as intended? It's not only for
hex. This works to

>>> 3or 50
3



-- 
Kind regards,

Stefano Borini
___
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/V6HMVBY4DO7IB7MQO2CAZFY7RJWAV7BB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Antoine Pitrou]

On Wed, 14 Apr 2021 10:12:19 +1000
Hugh Fisher  wrote:
> 
> For example, type equivalence by name only is used in Ada (or was,
> it's been many years) and probably other languages. In equivalence
> by name, the following code would not pass the type checker.
> x : list[int]
> y : list[int]
> x = y # Type error
> 
> But I'm not aware of anyone implementing type by name equivalence
> for Python, and the original PEP 483 seems to explicitly close off that
> possibility. Instead the assumption seems to be Java/C++ structural
> equivalence for types.

Can you explain why you think C++ typing is based on structural
equivalence?

Regards

Antoine.


___
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/T7CDYAOV5RHMJI2N6ND6QXQWKWSPFQCV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Antoine Pitrou]

For the record, Cython allows using annotations for typing:
https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#pep-484-type-annotations

I don't know if they are fully compatible with the type hints we're
talking about here.

Regards

Antoine.


On Wed, 14 Apr 2021 10:58:07 +0900
Inada Naoki  wrote:
> On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings  wrote:
> >
> >
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> >
> >
> > Because typing is, to many folks, a Really Important Concept, and it's 
> > confusing to use the same syntax ("x: blah blah") for different purposes, 
> > in a way that makes it hard to tell whether a particular "blah blah" is 
> > meant as a type or as something else -- because you have to know what's 
> > introspecting the annotations before you can tell. And that introspection 
> > could be signalled by a magical decorator, but it could also be implicit: 
> > maybe you have a driver that calls a function based on a CLI entry point 
> > name, and introspects that function even if it's not decorated.
> >
> >
> > I'm not sure I understand your point.  Are you saying that we need to take 
> > away the general-purpose functionality of annotations, that's been in the 
> > language since 3.0, and restrict annotations to just type hints... because 
> > otherwise an annotation might not be used for a type hint, and then the 
> > programmer would have to figure out what it means?  We need to take away 
> > the functionality from all other use cases in order to lend clarity to one 
> > use case?
> >  
> 
> I don't think we need to take away "general purpose functionality".
> But if we define type hinting is 1st class use case of annotations,
> annotations should be optimized for type hinting.  General purpose use
> case should accept some limitation and overhead.
> 
> On the other hand, if we decide general purpose functionality is 1st
> class too, we shouldn't annotation syntax different from Python
> syntax.
> 
> But annotations should be optimized for type hinting anyway. General
> purpose use case used only is a limited part of application. On the
> other hand, type hint can be used almost everywhere in application
> code base. It must cheap enough.
> 
> Regards,
> 



___
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/VJWVKMQFAOMYNORX3F4557KWINO4Z7GG/
Code of Conduct: http://python.org/psf/codeofconduct/