Luciano,
Thank you for such a thoughtful and eloquent response. Your wisdom is
definitely appreciated, and I agree this is an opportunity to go forward
with more clarity. I'm so proud of the Python dev community for their
thoughtful and respectful conversation.
All, Without the efforts of Larry,
My personal motivating example for PEP 637 was shorthand for protocols.
`x: Protocol[foo=int, bar=Callable[str, int]]` could say x has attribute
foo which is an int and method bar from str to int.
On Wed, Apr 21, 2021 at 4:23 PM Paul Bryan wrote:
> I agree, that's duck typing with a protocol,
On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
> On Tue, Apr 20, 2021 at 3:15 AM Irit Katriel
> wrote:
> > 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
I agree, that's duck typing with a protocol, and precisely the tedious
type style I would want to avoid.
I don't know what would be a good suggestion. Something where you
reference a "fully equipped" type and cherry pick the attributes you
want? Something like `Protocol[Duck, ("quack",
El mié, 21 abr 2021 a las 15:30, Paul Bryan () escribió:
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes to be used by the consumer. I want this
> duck to
On Wed, Apr 21, 2021 at 11:22 PM Nathaniel Smith wrote:
>
>
> Saying that you have to make a new API every time you start using
> concurrency inside a function is extremely restrictive.
You don't need a new API when you start using concurrency inside a
function. You need a new API when you
As demonstrated, protocols don't get us there because duck typing isn't
a matter of having an object exhibit all of the attributes of a duck,
but rather some subset of attributes to be used by the consumer. I want
this duck to quack; someone else will want it to waddle. I don't see
how type hints
On Tue, Apr 20, 2021 at 3:15 AM Irit Katriel wrote:
> 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
I think what Christopher says is fair. My question (with little understanding
of the underlying infrastructure) is can we define a 'type' that communicates
that? Something like 'object that implements .read', or '.upper and .__iter__
for a spring-like object's?
toonarmycaptain
On Tue, Apr 20, 2021 at 2:15 PM 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
Thanks Mark for posting this. I know some of us are uneasy about the pace
of the typing train
On Tue, Apr 20, 2021 at 11:20 AM Nathaniel Smith wrote:
> > 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
On Wed, Apr 21, 2021 at 11:50 AM srku...@mail.de wrote:
>
> Removing two concepts and preserving semantics simplifies the matter for
> users. People need less to memorize and less to learn.
>
> Or am I missing something here? Couldn’t we achieve our goal without these
> two new classes?
No, we
Removing two concepts and preserving semantics simplifies the matter for users.
People need less to memorize and less to learn.
Or am I missing something here? Couldn’t we achieve our goal without these two
new classes?
Splitting, wrapping and exception handling semantics are perfectly fine
While I have not been involved in the release process for like 15 years or
more, I would like to point out that breaking changes mean the distros are
less likely to ship them, and be less likely to trust updates.
Trying to get RH to stop shipping 1.5.2 was a huge effort.
Always, any time when
Am 20.04.2021 um 19:03 schrieb Mark Shannon:
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.
I'm not sure what inheriting from Protocol has to do with nominal
typing, even though I would
20.04.21 17:56, 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;
20.04.21 22:01, Guido van Rossum пише:
> So to be clear, that one user wants f"{Color.RED}" to return "1" and not
> " Color.RED" (or something like that).
The user should write f"{int(Color.RED)}" or f"{Color.RED.value}".
I have also an idea to support of additional conversion characters, so
17 matches
Mail list logo
