[Python-Dev] Re: PEP 563 in light of PEP 649

[Inada Naoki]

Just an idea: do not save co_name and co_firstlineno in code object
for function annotations.
When creating a function object from a code object, they can be copied
from annotated function.

I think co_name and co_firstlineno are preventing code object is
shared in compile time.
We can share only co_names and co_consts for now. If we can share the
entire code object, it will reduce pyc file size and unmarshal time
(e.g. part of import time).

On Tue, Apr 20, 2021 at 6:15 AM Larry Hastings  wrote:
>
> On 4/19/21 1:37 PM, Ethan Furman wrote:
>
> On 4/19/21 10:51 AM, Larry Hastings wrote:
>
> Something analogous /could/ happen in the PEP 649 branch but currently 
> doesn't.  When running Inada Noki's benchmark, there are a total of nine 
> possible annotations code objects.  Except, each function generated by the 
> benchmark has a unique name, and I incorporate that name into the name given 
> to the code object (f"{function_name}.__co_annotations__"). Since each 
> function name is different, each code object name is different, so each code 
> object /hash/ is different, and since they aren't /exact/ duplicates they are 
> never consolidated.
>
>
> I hate anonymous functions, so the name is very important to me.  The primary 
> code base I work on does have hundreds of methods with the same signature -- 
> unfortunately, many of the also have the same name (four levels of super() 
> calls is not unusual, and all to the same read/write/create parent methods 
> from read/write/create child methods).  In such a case would the name make a 
> meaningful difference?
>
> Or maybe the name can be store when running in debug mode, and not stored 
> with -O ?
>
>
> I think it needs to have a name.  But if it made a difference, perhaps it 
> could use f"{function_name}.__co_annotations__" normally, and simply 
> "__co_annotations__" with -O.
>
> Note also that this is the name of the annotations code object, although I 
> think the annotations function object reuses the name too.  Anyway, under 
> normal circumstances, the Python programmer would have no reason to interact 
> directly with the annotations code/function object, so it's not likely it 
> will affect them one way or another.  The only time they would see it would 
> be, say, if the calculation of an annotation threw an exception, in which 
> case it seems like seeing f"{function_name}.__co_annotations__" in the 
> traceback might be a helpful clue in diagnosing the problem.
>
>
> I'd want to see some real numbers before considering changes here.  If it has 
> a measurable and beneficial effect on real-world code, okay! let's change it! 
>  But my suspicion is that it doesn't really matter.
>
>
> 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/ZAPCP4MFDOF34E3G2TWAVY7JUQRHDOOB/
> Code of Conduct: http://python.org/psf/codeofconduct/



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

[Python-Dev] Re: PEP 563 in light of PEP 649

[Inada Naoki]

On Tue, Apr 20, 2021 at 4:24 PM Inada Naoki  wrote:
>
> Just an idea: do not save co_name and co_firstlineno in code object
> for function annotations.
> When creating a function object from a code object, they can be copied
> from annotated function.
>

I created a pull request. It use `__co_annotations__` for name, but
use `.__co_annotations__` for qualname.
https://github.com/larryhastings/co_annotations/pull/11


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

[Python-Dev] Re: Should Python typing leverage PEP 263 as a pre-processor step?

[Victor Stinner]

I proposed PEP 511 "API for code transformers" for Python 3.6 (in
2016) and it was rejected:
https://www.python.org/dev/peps/pep-0511/#rejection-notice

"""
This PEP was rejected by its author.

This PEP was seen as blessing new Python-like programming languages
which are close but incompatible with the regular Python language. It
was decided to not promote syntaxes incompatible with Python.

This PEP was also seen as a nice tool to experiment new Python
features, but it is already possible to experiment them without the
PEP, only with importlib hooks. If a feature becomes useful, it should
be directly part of Python, instead of depending on an third party
Python module.

Finally, this PEP was driven was the FAT Python optimization project
which was abandoned in 2016, since it was not possible to show any
significant speedup, but also because of the lack of time to implement
the most advanced and complex optimizations.
"""

IMO the most important part of the PEP 511 was to change the pyc
filename depending on the code transformer used to modify the code.

Victor

On Mon, Apr 19, 2021 at 8:21 PM Luciano Ramalho  wrote:
>
> How about leveraging the `# coding=` hook that exists
> since 2001 to enable the alternative syntax some are advocating for
> type hints?
>
> PEP 263—Defining Python Source Code Encodings
> https://www.python.org/dev/peps/pep-0263/
>
> I've seen experiments in the wild using that to support syntax
> extensions to Python. Just for fun, years ago I wrote a POC for
> Sucuri—a Python dialect with the keywords in Portuguese. The
> pre-processor simply replaced the Portuguese keywords with the English
> ones.
>
> Cheers,
>
> Luciano
>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
> ___
> 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/XRLAOOIJZRPDT2AW6LW4UVBEJD5NKLV5/
> 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/7HTSTMQK53APVR2OLUTDSYBZLTN2OQSM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 563 in light of PEP 649

[Inada Naoki]

And I tried removing co_firstfileno in optimize branch.
https://github.com/larryhastings/co_annotations/pull/9

Microbenchmarks.
(https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d)

```
# co_annotations branch (63b415c3)
$ ./python ~/ann_test.py 3
code size: 229679 bytes
memory: 209077 bytes
unmarshal: avg: 639.631ms +/-0.254ms
exec: avg: 95.979ms +/-0.033ms

$ ./python ~/ann_test_method.py 3
code size: 245729 bytes
memory: 339109 bytes
unmarshal: avg: 672.997ms +/-9.039ms
exec: avg: 259.286ms +/-4.841ms

# optimize branch (fbf0ad725f)
$ ./python ~/ann_test.py 3
code size: 113082 bytes
memory: 209077 bytes
unmarshal: avg: 318.437ms +/-0.171ms
exec: avg: 100.187ms +/-0.141ms

$ ./python ~/ann_test_method.py 3
code size: 129134 bytes
memory: 284565 bytes
unmarshal: avg: 357.157ms +/-0.971ms
exec: avg: 262.066ms +/-5.258ms
```

By the way, this microbenchmark uses 3 arguments and 1 return value.
annotation value is chosen from 3 (e.g. ["int", "str", "foo.bar.baz"]).
So there are 3*3*3*3=81 signatures, not only 27.

Anyway, 81/1000 may not be realistic.
When I changed ann_test to chose annotation value from 5 (e.g. 625/1000):

```
# co_annotations
$ ./python ~/ann_test.py 3
code size: 236106 bytes
memory: 208261 bytes
unmarshal: avg: 653.788ms +/-1.257ms
exec: avg: 95.783ms +/-0.169ms

# optimize
$ ./python ~/ann_test.py 3
code size: 162097 bytes
memory: 208261 bytes
unmarshal: avg: 458.959ms +/-0.163ms
exec: avg: 98.327ms +/-0.065ms
```


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

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Irit Katriel via Python-Dev]

On Tue, Apr 20, 2021 at 2:48 AM Nathaniel Smith  wrote:

>
> The problem is that most of the time, even if you're using concurrency
> internally so multiple things *could* go wrong at once, only one thing
> actually *does* go wrong. So it's unfortunate if some existing code is
> prepared for a specific exception that it knows can be raised, that
> exact exception is raised... and the existing code fails to catch it
> because now it's wrapped in an EG.
>

Yes, this was discussed at length on this list. Raising an exception group
is an API-breaking change. If a function starts raising exception groups
its callers need to be prepared for that. Realistically we think exception
groups will be raised by new APIs.  We tried and were unable to define
exception group semantics for except that would be reasonable and backwards
compatible. That's why we added except*.


> > It is easy enough to write a denormalize() function in traceback.py that
> constructs this from the current EG structure, if you need it (use the
> leaf_generator from the PEP). I'm not sure I see why we should trouble the
> interpreter with this.
>
> In the current design, once an exception is wrapped in an EG, then it
> can never be unwrapped, because its traceback information is spread
> across the individual exception + the EG tree around it. This is
> confusing to users ("how do I check errno?"), and makes the design
> more complicated (the need for topology-preserving .split(), the
> inability to define a sensible EG.__iter__, ...). The advantage of
> making the denormalized form the native form is that now the leaf
> exceptions would be self-contained objects like they are now, so you
> don't need EG nesting at all, and users can write intuitive code like:
>
> except OSError as *excs:
> remainder = [exc for exc in excs if exc.errno != ...]
> if remainder:
> raise ExceptionGroup(remainder)
>

We have this precise example in the PEP:
   match, rest = excs.split(lambda e: e.errno != ...)

You use split() instead of iteration for that.  split() preserves all
__context__, __cause__ and __traceback__ information, on all leaf and
non-leaf exceptions.


> For display purposes, it is probably nicer to look at a normalized
> traceback where common parts are not repeated.
>
> Yeah, I agree; display code would want to re-normalize before
> printing. But now it's only the display code that needs to care about
> figuring out shared parts of the traceback, rather than something that

has to be maintained as an invariant everywhere.
>

If you *do* want iteration, we show in the PEP how to write a
leaf_generator() that gives you the leaf exceptions with their tracebacks
(as a list of chunks). It is easy to copy the chunks into a single flat
traceback. We didn't propose to add it to traceback.py yet because the use
case is unclear but if people need it we're talking about 10-15 lines in
traceback.py.

So for your suggestion:

Pros:
1. Those who want a denormalized traceback (if they exist) won't need to
call traceback.denormalize().

Cons:
1. A significant change in the interpreter that will make it less efficient
(both time and space).
2. Display code will need to normalize the traceback, which is much more
complicated than denormalizing because you need to discover the shared
parts.

Am I missing something?


>
> > It sounds like you want some way to enrich exceptions. This should be
> optional (we wouldn't want EG to require additional metadata for
> exceptions) so yeah, I agree it should sit on the leaf exception and not on
> the group. In that sense it's orthogonal to this PEP.
>
> Well, the extra metadata would specifically be at "join" points in the
> traceback, which are a thing that this PEP is creating :-). And it's
> useful for every user of EGs, since by definition, an EG is
> multiplexing exceptions from multiple sources, so it's nice to tell
> the user which sources those are.

That said, you're right, if we want to handle this by defining a new
> kind of traceback entry that code like Trio/asyncio/hypothesis can
> manually attach to exceptions, then that could be written as a
> separate-but-complementary PEP. In my original design, instead of
> defining a new kind of traceback entry, I was storing this on the EG
> itself, so that's why I was thinking about it needing to be part of
> this PEP.
>

You can also create an ExceptionGroup subclass with whatever extra data you
want to include.

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

[Python-Dev] Re: Should Python typing leverage PEP 263 as a pre-processor step?

[Paul Sokolovsky]

Hello,

On Mon, 19 Apr 2021 20:23:08 -0700
Guido van Rossum  wrote:

[]

> > How does this "similar thing" compare to the recently announced
> > imphook module?
> >  
> 
> For one, pyxl is a better name. :-)

I would humbly disagree ;-).

> Seriously, as long as the purpose is to allow using a different
> grammar (for part of the file) that is then transpiled to proper
> Python, all but the first issue apply exactly the same.

That's one of the biggest differences - imphook
(https://pypi.org/project/imphook/) written with the idea that macro
capabilities have always been first-class citizen of the Python
ecosystem (well, maybe 25 years of its 30 years).

But it's also written with the full understanding and acknowledgment
that there's a disconnect between advanced Python users, who have been
using Python macro capabilities for decades, and mainstream community.
For the latter, the use of these facilities was always complicated and
esoteric.

And given the attitude of some core CPython developers (examples:
self-policing like in PEP511 or telling pyxl anecdotes), there's
suspicion that the state of complication and confusion is held on the
purpose (of course, with the good intentions of saving users from even
more confusion).

> Getting the hook to run (my first bullet) actually sounds *more*
> complicated, because you have to include code in your `__main__`
> module that installs the hook(s).

Right, importing a module is a complicated task for Python users, or
should be presented as such.

Well, then there's also a runner which allows to not patch your code to
use macro facilities:

  python3 -m imphook -i mod_conf example_conf.py

But that's command line, so of course it's still complicated. Well,
maybe not that much, and people who were able to deal with "python2",
"python3", "python3.5", "python3.6", "py", etc. can deal with that too.

> But I have zero experience with imphook, I just skimmed its PyPI home
> page, which has an example that calls
> ```
> imphook.add_import_hook(hook, (".conf",))
> ```

That's the code which needs to be run by "macro" implementations, not
by users of a particular "macro".


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

[Python-Dev] Re: Should Python typing leverage PEP 263 as a pre-processor step?

[Paul Sokolovsky]

Hello,

On Tue, 20 Apr 2021 11:08:56 +0200
Victor Stinner  wrote:

> I proposed PEP 511 "API for code transformers" for Python 3.6 (in
> 2016) and it was rejected:
> https://www.python.org/dev/peps/pep-0511/#rejection-notice

Well, it wasn't rejected, it was self-rejected on the thought-crime
grounds.

It's however a big philosophical question what's worse for Python -
adding questionable re: implementation aspects features (PEP649), NIH
way to handle exceptions (PEP654) (a couple of random examples,
really), - or embrace macro-level extensibility, which is usually a
part of any advanced programming language out there. (And which is
de-facto available for Python either).

[]

> IMO the most important part of the PEP 511 was to change the pyc
> filename depending on the code transformer used to modify the code.

Right, for "production" macro usage, the question of tracking macro
dependencies for precompiled bytecode (and invalidating it if
dependencies changed) is important. PEP 638
(https://www.python.org/dev/peps/pep-0638/) also touches on that, but I
also don't see it to be well thought out/articulated. Instead of adhoc
version/flavor identifiers (which in large-scale will likely lead to
version hell as we know), it literally should be that a .pyc file
can depend on multiple (not one, like now) .py files (or maybe
module names).

[]


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

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Steve Holden]

On Fri, Apr 16, 2021 at 7:15 PM Denis Kotov  wrote:

> Ethan Furman wrote:
> > On 4/16/21 10:43 AM, redrad...@gmail.com wrote:
> > > Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU
> > > or read some articles ... otherwise I will need to spend too many time
> providing evidences to you and after all you will probably will reject
> anyway (because lots of people is biased and they even do not understand
> that, it is not about you, it is in general)
> > > You are the one proposing the change, so it's up to you to provide the
> evidence for it.  If you aren't willing to put in
> > a few hours for that effort, why should we put the weeks and months to
> port the code over?
> > --
> > ~Ethan~
>
> I do not ask porting code, I ask using new code with C++ and if code was
> tested enough to reimplement it in C++ with RAII, 
>
> Also I suggest using C++ excepting that most of the people here now it ...
> It was not intended to teach C++ here, especially in Mail List )))
>
> And reason why you at least should try learn other languages, it is
> because it will make you better developer
>
Hi Denis,

While I can accept that your intentions are honourable, did you stop to
think that you are casting aspersions at a very capable and in many cases
senior developers by suggesting that the reason they will not adopt C++ as
an implementation language?

You are correct that there is a deal of inertia behind C as the
implementation language for CPython, as indeed there should be. It
represents a huge investment, and has created valuable artefacts. As
someone who isn't a core developer but manages programmers professionally
it seems to me that you are ignoring many easily detectable issues, some
technical and some social.

   - Who will put in the engineering effort to ensure that C++ code is
   supported within CPython codebase on all supported platforms?
   - Who will create and maintain the extra tests this would require?
   - Who will handle the inevitable deep bugs that the introduction of a
   not-fully-compatible technology will create?
   - By how much would such a change enlarge the core developer community?
   I so far know of one person it would add—you! What's the return on the
   effort?

Remember, relatively few people are paid to work on CPython. Most do it for
love and/or to scratch personal technical itches. What would they get out
of the adoption of C++. While your enthusiasm is welcome, it's beginning to
become a little wearing. Perhaps there's some history in the
python-dev archives that would inform you of previous discussions and help
you repeating already-considered arguments. I'm struggling to see the
benefits here, and your presumption that experienced team members should
immediately be persuaded by your arguments seems a little, well,
presumptuous.


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

[Python-Dev] str() vs format(): trivia question

[Ethan Furman]

urllib.urlencode currently uses `str()` on its non-bytes objects before encoding the result.  This causes a 
compatibility break when integer module constants are converted to IntEnum, as `str(IntEnum.MEMBER)` no longer returns 
the integer representation; however, `format()` does still return the integer representation.


The fix is to add a separate branch to check if the argument is an Enum, and use the value if so -- but it got me 
wondering: in general, are there differences between calling str() vs calling format() on Python objects?


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

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Skip Montanaro]

>
> Perhaps there's some history in the python-dev archives that would inform
> you of previous discussions and help you repeating already-considered
> arguments.
>

This topic has come up a few times over the years. Maybe it would be
worthwhile to have an informational PEP which documents the various
arguments pro and con to short-circuit or inform future discussions. I'm
not volunteering to write it. Denis, maybe you could make a run at it.

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

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Chris Angelico]

On Wed, Apr 21, 2021 at 1:05 AM Skip Montanaro  wrote:
>>
>> Perhaps there's some history in the python-dev archives that would inform 
>> you of previous discussions and help you repeating already-considered 
>> arguments.
>
>
> This topic has come up a few times over the years. Maybe it would be 
> worthwhile to have an informational PEP which documents the various arguments 
> pro and con to short-circuit or inform future discussions. I'm not 
> volunteering to write it. Denis, maybe you could make a run at it.
>

The arguments should be being made the other way around. Status quo
should not need to debate its own value; a proposed change needs to
convince people of its worth. CPython is currently written in C, and
anyone who suggests rewriting it has to be the one to submit evidence.

(Or if not rewriting it, then whatever the change is. I'm really not
sure what's being proposed - wholesale reimplementation? Permitting
new modules to be written in C++? The ability to write extension
modules in C++? In any case, it's been quite empty of supporting
evidence.)

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

[Python-Dev] Re: str() vs format(): trivia question

[Guido van Rossum]

I'd guess it is totally up to the object, since str() calls `__str__` and
format() calls `__format__`. Of course this now begs the question whether
those enums should perhaps change their `__format__` to match their
`__str__`...? But that would not suit your purpose. Then again, how would
one get the pretty IntEnum-specific representation in a format- or
f-string? I guess f"{flag!s}" would work.

On Tue, Apr 20, 2021 at 7:59 AM Ethan Furman  wrote:

> urllib.urlencode currently uses `str()` on its non-bytes objects before
> encoding the result.  This causes a
> compatibility break when integer module constants are converted to
> IntEnum, as `str(IntEnum.MEMBER)` no longer returns
> the integer representation; however, `format()` does still return the
> integer representation.
>
> The fix is to add a separate branch to check if the argument is an Enum,
> and use the value if so -- but it got me
> wondering: in general, are there differences between calling str() vs
> calling format() on Python objects?
>
> --
> ~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/24OF6XMFYK4PO2VPY6UFT2S3CBZFNOKB/
> 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/VCF3JTEQ53756EZMDXQNEF24PEQWZEZD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: str() vs format(): trivia question

[Eric V. Smith]

On 4/20/2021 10:56 AM, Ethan Furman wrote:
urllib.urlencode currently uses `str()` on its non-bytes objects 
before encoding the result.  This causes a compatibility break when 
integer module constants are converted to IntEnum, as 
`str(IntEnum.MEMBER)` no longer returns the integer representation; 
however, `format()` does still return the integer representation.


The fix is to add a separate branch to check if the argument is an 
Enum, and use the value if so -- but it got me wondering: in general, 
are there differences between calling str() vs calling format() on 
Python objects? 


If there's no format string, then object___format___impl() just calls 
PyObject_Str(). So unless the object overrides __format__, they're the same.


int does override __format__, in _PyLong_FormatAdvancedWriter(). It has 
a comment that says:


    /* check for the special case of zero length format spec, make
   it equivalent to str(obj) */

So even in the case of it, str(obj) should be the same as format(obj).

I thoughtPEP 3101 specifies this behavior, but I don't see it there. 
It's hopelessly out of date, anyway. The docs for format() say these 
weasel words: "The default /format_spec/ is an empty string which 
usually gives the same effect as calling |str(value)| 
.". They're vague 
because a user defined type could do anything in __format__, including 
ignore this advice. But I think all of the built-in types conform to it.


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

[Python-Dev] Keeping Python a Duck Typed Language.

[Mark Shannon]

Hi everyone,

Once upon a time Python was a purely duck typed language.

Then came along abstract based classes, and some nominal typing starting 
to creep into the language.


If you guarded your code with `isinstance(foo, Sequence)` then I could 
not use it with my `Foo` even if my `Foo` quacked like a sequence. I was 
forced to use nominal typing; inheriting from Sequence, or explicitly 
registering as a Sequence.



Then came type hints. PEP 484 explicitly said that type hints were 
optional and would *always* be optional.


Then came along many typing PEPs that assumed that type hints would only 
used for static typing, making static typing a bit less optional.
Not only that, but the type system proposed by many of these PEPs was 
clearly nominal, not structural.


PEP 544 supports structural typing, but to declare a structural type you 
must inherit from Protocol.

That smells a lot like nominal typing to me.

Then came PEP 563 and said that if you wanted to access the annotations 
of an object, you needed to call typing.get_type_hints() to get 
annotations in a meaningful form.

This smells a bit like enforced static typing to me.

Then came PEP 634 (structural pattern matching). Despite having the word 
'structural' in the name, PEP 634 insists on nominal typing to 
distinguish between sequences and mappings.



Nominal typing in a dynamically typed language makes little sense. It 
gains little or no safety, but restricts the programs you can write.
Because a class can claim to be a nominal type, but not match it 
structurally, it can appear to be type safe but fail at runtime. 
Conversely nominal typing errors can result in failures where 
structurally typed programs would work.


An extreme example of that is this:

# Some magic code to mess with collections.abc.Sequence
>>> match {}:
... case []:
...print("WTF!")
...
WTF!

With duck typing this would be impossible (unless you use ctypes to mess 
with the dict object).


To be fair, nominal typing is not always a problem. All exceptions must 
inherit from BaseException, and it doesn't seem to be a problem in practice.



So, lets stick to our promise that type hints will always be optional, 
and restore duck typing.



I'm not suggesting that we get rid type hints and abstract base classes.
They are popular for a reason.
But let's treat them as useful tools, not warp the rest of the language 
to fit them.


Cheers,
Mark.


Quick summaries of type systems:

https://en.wikipedia.org/wiki/Nominal_type_system

https://en.wikipedia.org/wiki/Structural_type_system

https://en.wikipedia.org/wiki/Duck_typing

Or, if you're really keen:

https://www.cis.upenn.edu/~bcpierce/tapl/

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

[Python-Dev] Re: str() vs format(): trivia question

[Eric V. Smith]

On 4/20/2021 11:13 AM, Eric V. Smith wrote:

On 4/20/2021 10:56 AM, Ethan Furman wrote:
urllib.urlencode currently uses `str()` on its non-bytes objects 
before encoding the result.  This causes a compatibility break when 
integer module constants are converted to IntEnum, as 
`str(IntEnum.MEMBER)` no longer returns the integer representation; 
however, `format()` does still return the integer representation.


The fix is to add a separate branch to check if the argument is an 
Enum, and use the value if so -- but it got me wondering: in general, 
are there differences between calling str() vs calling format() on 
Python objects? 


If there's no format string, then object___format___impl() just calls 
PyObject_Str(). So unless the object overrides __format__, they're the 
same.


I should mention that if you're going to implement __format__ and you 
don't care about the format specifier, then I'd do what 
object.__format__ does and raise an error for any non-empty format 
specifier. That way you can add a format specifier in the future and not 
worry that people are relying on passing in arbitrary format specs, 
which is a backward compatibility problem. That's why the error case was 
added to object.__format__: see https://bugs.python.org/issue7994 .


Eric

int does override __format__, in _PyLong_FormatAdvancedWriter(). It 
has a comment that says:


    /* check for the special case of zero length format spec, make
   it equivalent to str(obj) */

So even in the case of it, str(obj) should be the same as format(obj).

I thoughtPEP 3101 specifies this behavior, but I don't see it there. 
It's hopelessly out of date, anyway. The docs for format() say these 
weasel words: "The default /format_spec/ is an empty string which 
usually gives the same effect as calling |str(value)| 
.". They're vague 
because a user defined type could do anything in __format__, including 
ignore this advice. But I think all of the built-in types conform to it.


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


--
Eric V. Smith

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

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Chris Angelico]

On Wed, Apr 21, 2021 at 3:04 AM Mark Shannon  wrote:
> Then came type hints. PEP 484 explicitly said that type hints were
> optional and would *always* be optional.
>
> Then came along many typing PEPs that assumed that type hints would only
> used for static typing, making static typing a bit less optional.

How do they make type hints less optional?

> Then came PEP 563 and said that if you wanted to access the annotations
> of an object, you needed to call typing.get_type_hints() to get
> annotations in a meaningful form.
> This smells a bit like enforced static typing to me.

How?

> An extreme example of that is this:
>
> # Some magic code to mess with collections.abc.Sequence
>  >>> match {}:
> ... case []:
> ...print("WTF!")
> ...
> WTF!
>
> With duck typing this would be impossible (unless you use ctypes to mess
> with the dict object).

Why would you want to? A dict is not a sequence.

> So, lets stick to our promise that type hints will always be optional,
> and restore duck typing.
>
>
> I'm not suggesting that we get rid type hints and abstract base classes.
> They are popular for a reason.
> But let's treat them as useful tools, not warp the rest of the language
> to fit them.

So if you're not asking for them to be removed, then what ARE you
asking for? Is there any evidence that type hints will, in the future,
become mandatory?

I don't understand.

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

[Python-Dev] Re: str() vs format(): trivia question

[Ethan Furman]

On 4/20/21 8:46 AM, Guido van Rossum wrote:

I'd guess it is totally up to the object, since str() calls `__str__` and format() calls `__format__`. Of course this 
now begs the question whether those enums should perhaps change their `__format__` to match their `__str__`...?


When Enum was designed we made sure and captured `__repr__` and `__str__`, but not `__format__`.  So at this point, 
`__format__` is the mixed-in data type's -- so `int.__format__` in the case of IntEnum.  However, if a user updates the 
`__str__` of their Enum, then that will be used in the format:


```python
from enum import IntEnum

class Color(IntEnum):
RED = 1

format(Color.RED)
# '1'

class Color(IntEnum):
RED = 1
def __str__(self):
return 'one'

format(Color.RED)
# 'one'
```

But that 
would not suit your purpose. Then again, how would one get the pretty IntEnum-specific representation in a format- or 
f-string? I guess f"{flag!s}" would work.


Yup, that does work.

There is at least one user who is depending on `format()` using `int.__format__` because they filed a bug report when I 
broke it.


Moving forward, I'm not sure having format() and str() ever be different is a good idea, especially since users who 
need, for example, Color.RED to be '1' can simply add a `__str__ = int.__str__` to their own custom base IntEnum class 
and be good to go.  If we deprecate the current behavior now we could change it in 3.12.


Thoughts?

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

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Nathaniel Smith]

On Tue, Apr 20, 2021 at 10:07 AM Mark Shannon  wrote:
>
> Hi everyone,
>
> Once upon a time Python was a purely duck typed language.
>
> Then came along abstract based classes, and some nominal typing starting
> to creep into the language.
>
> If you guarded your code with `isinstance(foo, Sequence)` then I could
> not use it with my `Foo` even if my `Foo` quacked like a sequence. I was
> forced to use nominal typing; inheriting from Sequence, or explicitly
> registering as a Sequence.

You say this like it's a bad thing, but how is this avoidable, even in
principle? Structural typing lets you check whether Foo is duck-shaped
-- has appropriate attribute names, etc. But quacking like a duck is
harder: you also have to implement the Sequence behavioral contract,
and realistically the only way to know that is if the author of Foo
tells you.

I'm not even sure that this *is* nominal typing. You could just as
well argue that "the operation `isinstance(..., Sequence)` returns
`True`" is just another of the behavioral constraints that are
required to quack like a sequence.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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/GKQV6MXBIDL3AISZE6TFPZBUSMAGPSKD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Larry Hastings]

On 4/20/21 10:03 AM, Mark Shannon wrote:
Then came PEP 563 and said that if you wanted to access the 
annotations of an object, you needed to call typing.get_type_hints() 
to get annotations in a meaningful form.

This smells a bit like enforced static typing to me.


I'm working to address this.  We're adding a new function to the 
standard library called inspect.get_annotations().  It's a lot less 
opinionated than typing.get_type_hints()--it simply returns the 
un-stringized annotations.  It also papers over some other awkward 
annotations behaviors, such as classes inheriting annotations from base 
classes.  I propose that it be the official new Best Practice for 
accessing annotations (as opposed to type hints, you should still use 
typing.get_type_hints() for that).


   https://bugs.python.org/issue43817

This will get checked in in time for Python 3.10b1.

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

[Python-Dev] Re: str() vs format(): trivia question

[Brandt Bucher]

It has always bugged me that for Enums mixed in with int or str (a common 
pattern in my code), `f"{MyEnum.X}"` is not the same as `str(MyEnum.X)`.

I'd be happy to see it changed!
___
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/FAQ7QYJMUBMNM4PZSMKFV3NHF26WKVT3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 563 and Python 3.10.

[Thomas Wouters]

(Starting a new thread so as not to derail any of the ongoing discussions.)

Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP
563 (postponed evaluation of annotations) becoming the default. The
Steering Council has considered the issue carefully, along with many of the
proposed alternatives and solutions, and we’ve decided that at this point,
we simply can’t risk the compatibility breakage of PEP 563. We need to roll
back the change that made stringified annotations the default, at least for
3.10. (Pablo is already working on this.)

To be clear, we are not reverting PEP 563 itself. The future import will
keep working like it did since Python 3.7. We’re delaying making PEP 563
string-based annotations the default until Python 3.11. This will give us
time to find a solution that works for everyone (or to find a feasible
upgrade path for users who currently rely on evaluated annotations). Some
considerations that led us to this decision:

 - PEP 563’s default change is clearly too disruptive to downstream users
and third-party libraries to happen right now. We can’t risk breaking even
a small subset of the FastAPI/pydantic users, not to mention other uses of
evaluated type annotations that we’re not aware of yet.
 - PEP 563 provides no warning to users of the feature it’s disabling.
Without that, we can’t expect users to be aware of the upcoming breakage.
The lack of a warning was by design, and made sense in a world where type
annotations were only consumed by static type checkers --- but that’s not
actually the situation we’re in.  There are clearly existing real-world,
run-time uses of type annotations that would be adversely affected by this
change.
 - Originally, PEP 563 was scheduled to take effect in Python 4, and this
changed recently (after the discussion in the Language Summit of 2020).
It's possible that third-party libraries and users didn’t plan to react in
the current time frame as they were not aware of this change in timing.
 - There isn’t enough time to properly discuss PEP 649 or any of the
alternatives before the beta 1 deadline, and we really need to make sure we
don’t compound errors here.  We need to look for a long term solution,
which isn’t possible while still maintaining the release deadlines of
Python 3.10.  That means we’re also deferring PEP 649 to Python 3.11.

In the Steering Council’s unanimous opinion, rolling back the default flip
for stringified annotations in Python 3.10 is the least disruptive of all
the options.

We need to continue discussing the issue and potential solutions, since
this merely postpones the problem until 3.11. (For the record, postponing
the change further is not off the table, either, for example if the final
decision is to treat evaluated annotations as a deprecated feature, with
warnings on use.)

For what it’s worth, the SC is also considering what we can do to reduce
the odds of something like this happening again, but that’s a separate
consideration, and a multi-faceted one at that.

For the Steering Council,
Thomas.
-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: str() vs format(): trivia question

[Guido van Rossum]

On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman  wrote:

> On 4/20/21 8:46 AM, Guido van Rossum wrote:
>
> > I'd guess it is totally up to the object, since str() calls `__str__`
> and format() calls `__format__`. Of course this
> > now begs the question whether those enums should perhaps change their
> `__format__` to match their `__str__`...?
>
> When Enum was designed we made sure and captured `__repr__` and `__str__`,
> but not `__format__`.  So at this point,
> `__format__` is the mixed-in data type's -- so `int.__format__` in the
> case of IntEnum.  However, if a user updates the
> `__str__` of their Enum, then that will be used in the format:
>
> ```python
> from enum import IntEnum
>
> class Color(IntEnum):
>  RED = 1
>
> format(Color.RED)
> # '1'
>
> class Color(IntEnum):
>  RED = 1
>  def __str__(self):
>  return 'one'
>
> format(Color.RED)
> # 'one'
> ```
>
> > But that
> > would not suit your purpose. Then again, how would one get the pretty
> IntEnum-specific representation in a format- or
> > f-string? I guess f"{flag!s}" would work.
>
> Yup, that does work.
>
> There is at least one user who is depending on `format()` using
> `int.__format__` because they filed a bug report when I
> broke it.
>
> Moving forward, I'm not sure having format() and str() ever be different
> is a good idea, especially since users who
> need, for example, Color.RED to be '1' can simply add a `__str__ =
> int.__str__` to their own custom base IntEnum class
> and be good to go.  If we deprecate the current behavior now we could
> change it in 3.12.
>
> Thoughts?
>

So to be clear, that one user wants f"{Color.RED}" to return "1" and not "
Color.RED" (or  something like that). And you want f"{Color.RED}" and
str(Color.RED) to return the same value. Then together that means that
str(Color.RED) must also return "1".

Did I get that right? And are you happy with that outcome?

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

[Python-Dev] Re: [python-committers] PEP 563 and Python 3.10.

[Guido van Rossum]

Thanks to the Steering Council! You have the wisdom of Solomon. Rolling
back the code that made PEP 563 the default behavior is the only sensible
solution for 3.10.

On Tue, Apr 20, 2021 at 11:58 AM Thomas Wouters  wrote:

>
> (Starting a new thread so as not to derail any of the ongoing discussions.)
>
> Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP
> 563 (postponed evaluation of annotations) becoming the default. The
> Steering Council has considered the issue carefully, along with many of the
> proposed alternatives and solutions, and we’ve decided that at this point,
> we simply can’t risk the compatibility breakage of PEP 563. We need to roll
> back the change that made stringified annotations the default, at least for
> 3.10. (Pablo is already working on this.)
>
> To be clear, we are not reverting PEP 563 itself. The future import will
> keep working like it did since Python 3.7. We’re delaying making PEP 563
> string-based annotations the default until Python 3.11. This will give us
> time to find a solution that works for everyone (or to find a feasible
> upgrade path for users who currently rely on evaluated annotations). Some
> considerations that led us to this decision:
>
>  - PEP 563’s default change is clearly too disruptive to downstream users
> and third-party libraries to happen right now. We can’t risk breaking even
> a small subset of the FastAPI/pydantic users, not to mention other uses of
> evaluated type annotations that we’re not aware of yet.
>  - PEP 563 provides no warning to users of the feature it’s disabling.
> Without that, we can’t expect users to be aware of the upcoming breakage.
> The lack of a warning was by design, and made sense in a world where type
> annotations were only consumed by static type checkers --- but that’s not
> actually the situation we’re in.  There are clearly existing real-world,
> run-time uses of type annotations that would be adversely affected by this
> change.
>  - Originally, PEP 563 was scheduled to take effect in Python 4, and this
> changed recently (after the discussion in the Language Summit of 2020).
> It's possible that third-party libraries and users didn’t plan to react in
> the current time frame as they were not aware of this change in timing.
>  - There isn’t enough time to properly discuss PEP 649 or any of the
> alternatives before the beta 1 deadline, and we really need to make sure we
> don’t compound errors here.  We need to look for a long term solution,
> which isn’t possible while still maintaining the release deadlines of
> Python 3.10.  That means we’re also deferring PEP 649 to Python 3.11.
>
> In the Steering Council’s unanimous opinion, rolling back the default flip
> for stringified annotations in Python 3.10 is the least disruptive of all
> the options.
>
> We need to continue discussing the issue and potential solutions, since
> this merely postpones the problem until 3.11. (For the record, postponing
> the change further is not off the table, either, for example if the final
> decision is to treat evaluated annotations as a deprecated feature, with
> warnings on use.)
>
> For what it’s worth, the SC is also considering what we can do to reduce
> the odds of something like this happening again, but that’s a separate
> consideration, and a multi-faceted one at that.
>
> For the Steering Council,
> Thomas.
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
> Code of Conduct: https://www.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/4BFSYEKU3P7FNRKVDD7RZXTNEEA6PRXU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[srku...@mail.de]

Hi Irit,

reading this subthread specifically, I just got a wild idea and I couldn‘t find 
any related information in the PEP:

Why not extending BaseException by __group__ among __cause__ and __context__?

Would this reduce some of the added complexity and thus increase broader 
acceptance?

Cheers,
Sven


> On 7. Apr 2021, at 20:26, Irit Katriel via Python-Dev  
> wrote:
> 
> 
> On Mon, Apr 5, 2021 at 2:59 PM Chris Jerdonek  
> wrote:
>> This point reminded me again of this issue in the tracker ("Problems with 
>> recursive automatic exception chaining" from 2013): 
>> https://bugs.python.org/issue18861
>> I'm not sure if it's exactly the same, but you can see that a couple of the 
>> later comments there talk about "exception trees" and other types of 
>> annotations.
>> 
>> If that issue were addressed after ExceptionGroups were introduced, does 
>> that mean there would then be two types of exception-related trees layered 
>> over each other (e.g. groups of trees, trees of groups, etc)? It makes me 
>> wonder if there's a more general tree structure that could accommodate both 
>> use cases...
>> 
>> --Chris 
> 
> Interesting, I commented on that issue - I think we may be able to solve it 
> without adding more trees. 
> 
> That said, we will have groups-of-trees/trees-of-groups.  Already today, an 
> exception plus its chained __cause__s and __context__s is the root of a 
> binary tree of exceptions.  The nodes of this tree represent the times that 
> the exceptions were caught.
> 
> An exception group is a tree where the nodes represent the times when 
> exceptions were grouped together and raised. 
> 
> Irit
> ___
> 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/BZWELKDUAKCOXSH5KQRFGQJRQWJ2OHKW/
> 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/B7LTPCJIOMTIHO5D3FUZ76DVQDIAMNPY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: str() vs format(): trivia question

[Ethan Furman]

On 4/20/21 12:01 PM, Guido van Rossum wrote:
> On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:

>> Moving forward, I'm not sure having format() and str() ever be different
>> is a good idea, especially since users who need, for example, Color.RED
>> to be '1' can simply add a `__str__ = int.__str__` to their own custom
>> base IntEnum class and be good to go.  If we deprecate the current behavior
>> now we could change it in 3.12.
>>
>> Thoughts?

> So to be clear, that one user wants f"{Color.RED}" to return "1" and not
> " Color.RED" (or  something like that). And you want f"{Color.RED}" and
> str(Color.RED) to return the same value. Then together that means that
> str(Color.RED) must also return "1".
>
> Did I get that right? And are you happy with that outcome?

Almost right. They should both return `Color.RED`.  Any users who want something different will need to do some work on 
their end:


class MyIntEnum(IntEnum):
def __format__ = int.__format__

class Color(MyIntEnum):
RED = 1

format(Color.RED)
# '1'

The deprecation period will give that user, and others like them, time to add their own Enum base classes with the 
`__format__` method they desire.


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

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Irit Katriel via Python-Dev]

Hi Sven,

I don’t follow.  What would the value of __group__ be and how would it work?

Irit

> On 20 Apr 2021, at 20:44, srku...@mail.de wrote:
> 
> 
> Hi Irit,
> 
> reading this subthread specifically, I just got a wild idea and I couldn‘t 
> find any related information in the PEP:
> 
> Why not extending BaseException by __group__ among __cause__ and __context__?
> 
> Would this reduce some of the added complexity and thus increase broader 
> acceptance?
> 
> Cheers,
> Sven

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

[Python-Dev] Re: [python-committers] PEP 563 and Python 3.10.

[Sebastián Ramírez]

This is amazing news!

On behalf of the FastAPI/pydantic communities, thanks to the Steering
Council, and everyone involved!

I understand the big effort and commitment the Steering Council is making
with this decision to support the pydantic and FastAPI communities
(especially with our short notice), and the last-minute extra work involved
in reverting the default for 3.10.

This will give us all the time to figure out how to handle it taking into
account pydantic/FastAPI and the use cases that would benefit from PEP 563
and PEP 649.

Thanks!

Sebastián

On Tue, Apr 20, 2021 at 9:14 PM Guido van Rossum  wrote:

> Thanks to the Steering Council! You have the wisdom of Solomon. Rolling
> back the code that made PEP 563 the default behavior is the only sensible
> solution for 3.10.
>
> On Tue, Apr 20, 2021 at 11:58 AM Thomas Wouters  wrote:
>
>>
>> (Starting a new thread so as not to derail any of the ongoing
>> discussions.)
>>
>> Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP
>> 563 (postponed evaluation of annotations) becoming the default. The
>> Steering Council has considered the issue carefully, along with many of the
>> proposed alternatives and solutions, and we’ve decided that at this point,
>> we simply can’t risk the compatibility breakage of PEP 563. We need to roll
>> back the change that made stringified annotations the default, at least for
>> 3.10. (Pablo is already working on this.)
>>
>> To be clear, we are not reverting PEP 563 itself. The future import will
>> keep working like it did since Python 3.7. We’re delaying making PEP 563
>> string-based annotations the default until Python 3.11. This will give us
>> time to find a solution that works for everyone (or to find a feasible
>> upgrade path for users who currently rely on evaluated annotations). Some
>> considerations that led us to this decision:
>>
>>  - PEP 563’s default change is clearly too disruptive to downstream users
>> and third-party libraries to happen right now. We can’t risk breaking even
>> a small subset of the FastAPI/pydantic users, not to mention other uses of
>> evaluated type annotations that we’re not aware of yet.
>>  - PEP 563 provides no warning to users of the feature it’s disabling.
>> Without that, we can’t expect users to be aware of the upcoming breakage.
>> The lack of a warning was by design, and made sense in a world where type
>> annotations were only consumed by static type checkers --- but that’s not
>> actually the situation we’re in.  There are clearly existing real-world,
>> run-time uses of type annotations that would be adversely affected by this
>> change.
>>  - Originally, PEP 563 was scheduled to take effect in Python 4, and this
>> changed recently (after the discussion in the Language Summit of 2020).
>> It's possible that third-party libraries and users didn’t plan to react in
>> the current time frame as they were not aware of this change in timing.
>>  - There isn’t enough time to properly discuss PEP 649 or any of the
>> alternatives before the beta 1 deadline, and we really need to make sure we
>> don’t compound errors here.  We need to look for a long term solution,
>> which isn’t possible while still maintaining the release deadlines of
>> Python 3.10.  That means we’re also deferring PEP 649 to Python 3.11.
>>
>> In the Steering Council’s unanimous opinion, rolling back the default
>> flip for stringified annotations in Python 3.10 is the least disruptive of
>> all the options.
>>
>> We need to continue discussing the issue and potential solutions, since
>> this merely postpones the problem until 3.11. (For the record, postponing
>> the change further is not off the table, either, for example if the final
>> decision is to treat evaluated annotations as a deprecated feature, with
>> warnings on use.)
>>
>> For what it’s worth, the SC is also considering what we can do to reduce
>> the odds of something like this happening again, but that’s a separate
>> consideration, and a multi-faceted one at that.
>>
>> For the Steering Council,
>> Thomas.
>> --
>> Thomas Wouters 
>>
>> Hi! I'm an email virus! Think twice before sending your email to help me
>> spread!
>> ___
>> python-committers mailing list -- python-committ...@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-committ...@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
>> Code of Conduct: https://www.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.

[Python-Dev] Re: [python-committers] PEP 563 and Python 3.10.

[Samuel Colvin]

This is great news!

Thanks so much for hearing us and putting up with our last minute request.

I'm sure we can find a solution that, while not perfect, can satisfy most
of the people most of the time.

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

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[srku...@mail.de]

So, forgive me my relatively simple mental model about ExceptionGroup. I still 
try to create one for daily use.

As noted in the discussion, an EG provides a way to collect exceptions from 
different sources and raise them as a bundle. They have no apparent relation up 
until this point in time (for whatever reason they have been separate and for 
whatever reason they are bundled now). The result would be a tree graph in any 
case.

A usual datastructure for a tree is to store all child nodes at the parent node.

That was the idea behind the content of BaseException.__group__: it’s the list 
of child exceptions bundled at a specific point in time and raise as such a 
bundle. So all exceptions could become EGs with the additional semantics you‘ve 
described in the PEP.

Illustrative Example:
>>> bundle_exc.__group__
[IOError(123), RuntimerError(‘issue somewhere’)]

I was wondering what of the PEP could be removed to make it simpler and more 
acceptable/less confusing (also looking at reactions from Twitter etc.) and I 
found these additional classes to be a part of it. Additionally, I fail to see 
how to access these bundled exceptions in an easy manner like __cause__ and 
__context__. (As the PEP also referring to them). So, I removed the classes and 
added a regular attribute.

The reason I brought this up what the section “rejected ideas” didn’t showed 
anything in this direction (or I managed to missed that).

Sven

> 
> On 20. Apr 2021, at 22:05, Irit Katriel  wrote:
> 
> Hi Sven,
> 
> I don’t follow.  What would the value of __group__ be and how would it work?
> 
> Irit
> 
>> On 20 Apr 2021, at 20:44, srku...@mail.de wrote:
>> 
>> Hi Irit,
>> reading this subthread specifically, I just got a wild idea and I couldn‘t 
>> find any related information in the PEP:
>> Why not extending BaseException by __group__ among __cause__ and __context__?
>> Would this reduce some of the added complexity and thus increase broader 
>> acceptance?
>> Cheers,
>> Sven

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

[Python-Dev] Re: str() vs format(): trivia question

[MRAB]

On 2021-04-20 20:42, Ethan Furman wrote:

On 4/20/21 12:01 PM, Guido van Rossum wrote:
  > On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:

  >> Moving forward, I'm not sure having format() and str() ever be different
  >> is a good idea, especially since users who need, for example, Color.RED
  >> to be '1' can simply add a `__str__ = int.__str__` to their own custom
  >> base IntEnum class and be good to go.  If we deprecate the current behavior
  >> now we could change it in 3.12.
  >>
  >> Thoughts?

  > So to be clear, that one user wants f"{Color.RED}" to return "1" and not
  > " Color.RED" (or  something like that). And you want f"{Color.RED}" and
  > str(Color.RED) to return the same value. Then together that means that
  > str(Color.RED) must also return "1".
  >
  > Did I get that right? And are you happy with that outcome?

Almost right. They should both return `Color.RED`.  Any users who want 
something different will need to do some work on
their end:

  class MyIntEnum(IntEnum):
  def __format__ = int.__format__

  class Color(MyIntEnum):
  RED = 1

  format(Color.RED)
  # '1'

The deprecation period will give that user, and others like them, time to add 
their own Enum base classes with the
`__format__` method they desire.


Couldn't the format accept 'd' if they want an int, i.e. f"{Color.RED:d}"?
___
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/IZH66WUEQJVEFBFBCOXXY3TMHJVLOEBF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Irit Katriel via Python-Dev]

I don’t see what this simplifies. We still need to implement split, and to 
worry about wrapping or not wrapping BaseExceptions and we still need to define 
exception handling semantics (except/except*).


> On 20 Apr 2021, at 22:12, srku...@mail.de wrote:
> 
> So, forgive me my relatively simple mental model about ExceptionGroup. I 
> still try to create one for daily use.
> 
> As noted in the discussion, an EG provides a way to collect exceptions from 
> different sources and raise them as a bundle. They have no apparent relation 
> up until this point in time (for whatever reason they have been separate and 
> for whatever reason they are bundled now). The result would be a tree graph 
> in any case.
> 
> A usual datastructure for a tree is to store all child nodes at the parent 
> node.
> 
> That was the idea behind the content of BaseException.__group__: it’s the 
> list of child exceptions bundled at a specific point in time and raise as 
> such a bundle. So all exceptions could become EGs with the additional 
> semantics you‘ve described in the PEP.
> 
> Illustrative Example:
 bundle_exc.__group__
> [IOError(123), RuntimerError(‘issue somewhere’)]
> 
> I was wondering what of the PEP could be removed to make it simpler and more 
> acceptable/less confusing (also looking at reactions from Twitter etc.) and I 
> found these additional classes to be a part of it. Additionally, I fail to 
> see how to access these bundled exceptions in an easy manner like __cause__ 
> and __context__. (As the PEP also referring to them). So, I removed the 
> classes and added a regular attribute.
> 
> The reason I brought this up what the section “rejected ideas” didn’t showed 
> anything in this direction (or I managed to missed that).
> 
> Sven
> 
>> 
>> On 20. Apr 2021, at 22:05, Irit Katriel  wrote:
>> 
>> Hi Sven,
>> 
>> I don’t follow.  What would the value of __group__ be and how would it work?
>> 
>> Irit
>> 
 On 20 Apr 2021, at 20:44, srku...@mail.de wrote:
>>> 
>>> Hi Irit,
>>> reading this subthread specifically, I just got a wild idea and I couldn‘t 
>>> find any related information in the PEP:
>>> Why not extending BaseException by __group__ among __cause__ and 
>>> __context__?
>>> Would this reduce some of the added complexity and thus increase broader 
>>> acceptance?
>>> Cheers,
>>> Sven
> 
___
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/OJJXMPBD4ZUZOUZ2ULWT4Q6ULI75HLDE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Eric Casteleijn]

On Tue, Apr 20, 2021 at 10:03 AM Mark Shannon  wrote:

> ...
> PEP 544 supports structural typing, but to declare a structural type you
> must inherit from Protocol.
> That smells a lot like nominal typing to me.
>

Note that to implement a protocol you do not have to inherit from anything.
You create a structural type that subclasses Protocol, but then any object
that satisfies that protocol can be passed where that type is expected,
without having to inherit anything, so I would argue that this really is
structural typing.


-- 
- eric casteleijn (he/him)
___
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/R3VP4KORAWI6KK4CNFL6JNYCATWR47EV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Luciano Ramalho]

I am not taking sides now, but I want to share with you a useful
diagram to reason about typing support in Python.

I struggled to explain what Python offers until I came up with this diagram:

https://standupdev.com/wiki/doku.php?id=python_protocols#the_typing_map

The Typing Map has two orthogonal axis:

- when are types checked:
-- runtime checking
-- static checking

- how are type checked:
-- structural types
-- nominal types

The quadrants are informally labeled with the terms in ALL CAPS below.

Traditionally, mainstream languages supported one of two diagonally
opposite quadrants: STATIC TYPING and DUCK TYPING.

Now the situation is more complicated.

- Java supports only STATIC TYPING: static checking of nominal types;
Python started supporting nominal types with PEP 484

- Before ABCs, Python supported only DUCK TYPING: runtime checking of
structural types;

- With ABCs, Python started supporting GOOSE TYPING (a term invented
by Alex Martelli, in cc because I just quoted him): runtime checking
of nominal types (with subclass hook which is a backdoor to support
explicit checks on structural types as well);

- With PEP 544, Python started supporting STATIC DUCK TYPING: static
checking of structural types;

There are languages that support multiple quadrants:

- TypeScript, like Python, supports all four quadrants.

- Go supports STATIC TYPING, but it also famously popularized STATIC
DUCK TYPING, and even supports GOOSE TYPING with features like type
assertions and type switches [1] designed for explicit runtime
checking of nominal or structural types.

[1] https://tour.golang.org/methods/16

The Typing Map will be featured in my upcoming PyCon US talk [2]

[2] https://us.pycon.org/2021/schedule/presentation/80/

Cheers,

Luciano


PS. If you are aware of other languages that support more than one of
these quadrants, please let me know!




On Tue, Apr 20, 2021 at 6:53 PM Eric Casteleijn  wrote:
>
>
>
> On Tue, Apr 20, 2021 at 10:03 AM Mark Shannon  wrote:
>>
>> ...
>> PEP 544 supports structural typing, but to declare a structural type you
>> must inherit from Protocol.
>> That smells a lot like nominal typing to me.
>
>
> Note that to implement a protocol you do not have to inherit from anything. 
> You create a structural type that subclasses Protocol, but then any object 
> that satisfies that protocol can be passed where that type is expected, 
> without having to inherit anything, so I would argue that this really is 
> structural typing.
>
>
> --
> - eric casteleijn (he/him)
> ___
> 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/R3VP4KORAWI6KK4CNFL6JNYCATWR47EV/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/DYFZORZKWAB7BFCXMDPNTGSWH6IPPIRL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Mark Shannon]

Hi Luciano,

On 20/04/2021 11:35 pm, Luciano Ramalho wrote:

I am not taking sides now, but I want to share with you a useful
diagram to reason about typing support in Python.

I struggled to explain what Python offers until I came up with this diagram:

https://standupdev.com/wiki/doku.php?id=python_protocols#the_typing_map


That's really nice, thanks.



The Typing Map has two orthogonal axis:

- when are types checked:
-- runtime checking
-- static checking

- how are type checked:
-- structural types
-- nominal types

The quadrants are informally labeled with the terms in ALL CAPS below.

Traditionally, mainstream languages supported one of two diagonally
opposite quadrants: STATIC TYPING and DUCK TYPING.

Now the situation is more complicated.

- Java supports only STATIC TYPING: static checking of nominal types;
Python started supporting nominal types with PEP 484

- Before ABCs, Python supported only DUCK TYPING: runtime checking of
structural types;

- With ABCs, Python started supporting GOOSE TYPING (a term invented
by Alex Martelli, in cc because I just quoted him): runtime checking
of nominal types (with subclass hook which is a backdoor to support
explicit checks on structural types as well);

- With PEP 544, Python started supporting STATIC DUCK TYPING: static
checking of structural types;

There are languages that support multiple quadrants:

- TypeScript, like Python, supports all four quadrants.

- Go supports STATIC TYPING, but it also famously popularized STATIC
DUCK TYPING, and even supports GOOSE TYPING with features like type
assertions and type switches [1] designed for explicit runtime
checking of nominal or structural types.

[1] https://tour.golang.org/methods/16

The Typing Map will be featured in my upcoming PyCon US talk [2]

[2] https://us.pycon.org/2021/schedule/presentation/80/

Cheers,

Luciano


PS. If you are aware of other languages that support more than one of
these quadrants, please let me know!




On Tue, Apr 20, 2021 at 6:53 PM Eric Casteleijn  wrote:




On Tue, Apr 20, 2021 at 10:03 AM Mark Shannon  wrote:


...
PEP 544 supports structural typing, but to declare a structural type you
must inherit from Protocol.
That smells a lot like nominal typing to me.



Note that to implement a protocol you do not have to inherit from anything. You 
create a structural type that subclasses Protocol, but then any object that 
satisfies that protocol can be passed where that type is expected, without 
having to inherit anything, so I would argue that this really is structural 
typing.


--
- eric casteleijn (he/him)
___
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/R3VP4KORAWI6KK4CNFL6JNYCATWR47EV/
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/UXBP7AII3Z4Z7COK7P4OETAR7J5F5XP5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Luciano Ramalho]

Now, given the terms I used in the last e-mail, it does worry me that
the push towards supporting STATIC TYPING in Python sometimes ignores
the needs of people who use the other typing disciplines. For example,
Pydantic is an example of using type hints for GOOSE TYPING.

And it alwo worries me that many of those not concerned with STATIC
TYPING are not following closely the decisions being made in the 19
(and counting) typing PEPs., some of which affect everyone who uses
Python.

Here are two examples:


PEP 484 DISMISSES THE NUMBERS ABCs

Direct quote from section "The Numeric Tower" [0]:

"There are some issues with these ABCs".

[0] https://www.python.org/dev/peps/pep-0484/#the-numeric-tower

No further explanation is given. The PEP then proposes ad-hoc rules to
support int, float and complex, leaving users of the Numbers ABCs,
Fraction, Decimal, and the huge NumPy community in the dark as to how
to handle other numeric types.

Now, I understand that the Numeric tower, as defined, cannot be used
for STATIC TYPING because the root class—Number—has no methods. Also,
there are deeper arguments regarding the soundness of that hierarchy.
See for example "Bad Ideas In Type Theory" [1].

[1] https://www.yodaiken.com/2017/09/15/bad-ideas-in-type-theory/

However, I think a package in the standard library, and more
importantly, the users of that package, deserve more attention.

If PEP 484 et. al. wants to serve all the Python community, it must be
part of its mission to address the problem of the Numbers ABCs, either
fixing it, or deprecating it while proposing something better, but not
creating an ad-hoc rule for three built-in types, ignoring all others.


PEP 563 EMBRACES THEN DEPRECATES ALL OTHER USES OF ANNOTATIONS

Section "Non-typing usage of annotations" [2] of PEP 563 starts with:

"While annotations are still available for arbitrary use besides type
checking..."

but ends in a very different tone:

"uses for annotations incompatible with the aforementioned PEPs should
be considered deprecated."

[2] https://www.python.org/dev/peps/pep-0563/#non-typing-usage-of-annotations

I think if more eyes beyond the STATIC TYPING community were looking
at the PEP, that inconsistency would have been flagged and dealt with
in some way.


OUR PROBLEM

There is a rift that need to work to close in the Python community.

Some people invested in STATIC TYPING are involved with million-line
codebases where performance is paramount and the cost of bugs may be
very high, and that creates a big motivation to use Python in a more
constrained way. They are not paying attention to other uses of type
hints—which are no deviations at all, because PEP 3107 explicitly
encouraged people to experiment with the annotations. If that is
deprecated, more people should be part of the conversation—as we are
seeing now.

On the other hand, most people who were attracted to Python *because*
of the flexibility of DUCK TYPING and GOOSE TYPING perhaps don't
follow the typing PEPs so closely—there are many, and most are pretty
hard to read, by the nature of the subject matter.


A BEAUTIFUL BRIDGE

PEP 544 was a *huge* step forward to bridge the gap between static
typing and duck typing in the language. Thank you very much for all
who proposed and implemented it. That's the kind of bridge we need!

(The `SupportsFloat` and similar protocols introduced with PEP 544 are
a way to test number types when they are not limited to float, int and
complex. But they expose some inconsistencies, and we still should do
something about the Numbers ABCs, IMHO)


GOING FORWARD

I think the PEP 563 v. PyDantic et. al. case is a very good
opportunity for us to think of ways to engage in dialog with the
different parts of the Python community on how they use types in the
language, considering STATIC TYPING, DUCK TYPING, STATIC DUCK TYPING,
GOOSE TYPING, without dismissing any of these styles.

If typing.get_type_hints is offered as a bridge for runtime uses of
type hints, it must work well and its shortcomings must be documented
as part of the official Python documentation, so that everyone knows
how reliable they are.

And in the future, if people come up with some new way of handling
types, every new addition must be considered in light of existing
typing styles—after a good, broad conversation involving different
user bases.


Cheers,

Luciano



On Tue, Apr 20, 2021 at 7:35 PM Luciano Ramalho  wrote:
>
> I am not taking sides now, but I want to share with you a useful
> diagram to reason about typing support in Python.
>
> I struggled to explain what Python offers until I came up with this diagram:
>
> https://standupdev.com/wiki/doku.php?id=python_protocols#the_typing_map
>
> The Typing Map has two orthogonal axis:
>
> - when are types checked:
> -- runtime checking
> -- static checking
>
> - how are type checked:
> -- structural types
> -- nominal types
>
> The quadrants are informally labeled with the terms in ALL CAPS below.
>
> Traditionally, mainstrea