t;levkivs...@gmail.com> Cc: Markus Wissinger
<markus.wissin...@gmail.com>, Python-Dev <python-dev@python.org> Betreff: Re:
[Python-Dev] PEP 544: Protocols - second round
>> I am currently exploring a type hint generator that produces hints out of
>> types used in unit
;Markus Wissinger" <markus.wissin...@gmail.com>
Cc: Python-Dev <python-dev@python.org>
Betreff: Re: [Python-Dev] PEP 544: Protocols - second round
On 22 June 2017 at 10:44, Markus Wissinger <markus.wissin...@gmail.com> wrote:
I have to admit I am not happy with separating
On 22 June 2017 at 10:44, Markus Wissinger
wrote:
> I have to admit I am not happy with separating the concepts of 'runtime'
> and 'static' types as implied by pep544.
>
This is not something new, already PEP 483 makes a clear distinction
between types (a static
On Thu, Jun 22, 2017 at 10:44 AM, Markus Wissinger <
markus.wissin...@gmail.com> wrote:
> Hi,
>
> I have to admit I am not happy with separating the concepts of 'runtime'
> and 'static' types as implied by pep544.
>
> I am currently exploring a type hint generator that produces hints out of
>
Hi,
I have to admit I am not happy with separating the concepts of 'runtime'
and 'static' types as implied by pep544.
I am currently exploring a type hint generator that produces hints out of
types used in unit tests. It debugs the tests and collects the parameter
types of call and return
On Fri, Jun 2, 2017 at 3:10 PM, Ivan Levkivskyi
wrote:
> On 1 June 2017 at 00:10, Guido van Rossum wrote:
>
>>
>> On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi
>> wrote:
>>
>>> On 31 May 2017 at 00:58, Guido van Rossum
On 1 June 2017 at 00:10, Guido van Rossum wrote:
>
> On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi
> wrote:
>
>> On 31 May 2017 at 00:58, Guido van Rossum wrote:
>> [...]
>>
>> Thank you for very detailed answers! I have practically
On Wed, May 31, 2017 at 2:16 AM, Ivan Levkivskyi
wrote:
> On 31 May 2017 at 00:58, Guido van Rossum wrote:
> [...]
>
> Thank you for very detailed answers! I have practically nothing to add.
> It seems to me that most of the Kevin's questions stem from
Hi,
I'm interested in startup time too, not only execution time.
Here is very rough test:
with open('with_abc.py', 'w') as f:
print("import abc", file=f)
for i in range(1, 1001):
print(f"class A{i}(metaclass=abc.ABCMeta): pass", file=f)
with open('without_abc.py', 'w') as f:
On 31 May 2017 at 00:58, Guido van Rossum wrote:
[...]
Thank you for very detailed answers! I have practically nothing to add.
It seems to me that most of the Kevin's questions stem from unnecessary
focus
on runtime type checking. Here are two ideas about how to fix this:
*
[I added some blank lines to separate the PEP quotes from Kevin's
responses.]
On Mon, May 29, 2017 at 7:51 AM, Kevin Conway
wrote:
> From the PEP:
> > The problem with them is that a class has to be explicitly marked to
> support them, which is unpythonic and unlike
>From the PEP:
> The problem with them is that a class has to be explicitly marked to
support them, which is unpythonic and unlike what one would normally do in
idiomatic dynamically typed Python code.
> The same problem appears with user-defined ABCs: they must be explicitly
subclassed or
On 28 May 2017 at 19:40, Guido van Rossum wrote:
> On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi
> wrote:
>
[...]
> Regarding the title, I'd like to keep the word Protocol in the title too,
> so I'd go with "Protocols: Structural subtyping (duck
On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi
wrote:
> On 28 May 2017 at 16:13, Kevin Conway wrote:
>
>> > Some of the possible options for the title are
>> It seems like you're talking about something most other languages would
>> refer to
On 28 May 2017 at 16:13, Kevin Conway wrote:
> > Some of the possible options for the title are
> It seems like you're talking about something most other languages would
> refer to as "Interfaces". What is unique about this proposal that would
> call for not using the
> Some of the possible options for the title are
It seems like you're talking about something most other languages would
refer to as "Interfaces". What is unique about this proposal that would
call for not using the industry standard language?
> Type-hints should not have runtime semantics,
Thanks everyone for interesting suggestions!
@Antoine @Guido:
Some of the possible options for the title are:
* Protocols (structural subtyping)
* Protocols (static duck typing)
* Structural subtyping (static duck typing)
which one do you prefer?
@Nick:
Yes, explicit imports are not necessary
On Thu, May 25, 2017 at 10:49 AM, Mark Shannon wrote:
> I really like this PEP in general. I think this brings the type system for
> type-hints closer to Python semantics.
>
Thank you.
> But there are a few points I disagree with.
> I don't think Protocol types should be tied
On Thu, May 25, 2017 at 7:19 AM, Nick Coghlan wrote:
> Given the abstract, I'd suggest "Structural Subtyping" as a suitable
> title for the PEP.
>
Maybe even "Structural Subtyping (a.k.a. Duck Typing)"
> That said, I think it's fine to use "protocol" throughout the rest
On 24/05/17 14:31, Ivan Levkivskyi wrote:
Hi all,
After collecting suggestions in the previous discussion on python-dev
https://mail.python.org/pipermail/python-dev/2017-March/thread.html#147629
and playing with implementation, here is an updated version of PEP 544.
--
Ivan
I really like
2017-05-25 7:19 GMT-07:00 Nick Coghlan :
> On 25 May 2017 at 21:26, Antoine Pitrou wrote:
> > On Wed, 24 May 2017 23:31:47 +0200
> > Ivan Levkivskyi wrote:
> >
> >> Hi all,
> >>
> >> After collecting suggestions in the previous
On 25 May 2017 at 21:26, Antoine Pitrou wrote:
> On Wed, 24 May 2017 23:31:47 +0200
> Ivan Levkivskyi wrote:
>
>> Hi all,
>>
>> After collecting suggestions in the previous discussion on python-dev
>>
On Wed, 24 May 2017 23:31:47 +0200
Ivan Levkivskyi wrote:
> Hi all,
>
> After collecting suggestions in the previous discussion on python-dev
> https://mail.python.org/pipermail/python-dev/2017-March/thread.html#147629
> and playing with implementation, here is an updated
23 matches
Mail list logo