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
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:
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
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
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
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,
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
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 --
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
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
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__ =
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?
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
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
(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
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
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
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,
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
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
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
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`
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
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
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
>
> 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
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
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
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
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
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
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:
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
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
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
35 matches
Mail list logo
