On Tue, May 21, 2019, 12:00 Guido van Rossum wrote:
> My guess, without delving into the implementation, is that a Protocol is
> *always* about the class, and that this is entirely a red herring.
>
I think you're right. It makes sense. I must have missed it somehow.
FYI, some protocols (like
(I did see your post in the moderation queue and let it through -- however
the mypy team, which would be most responsible for answering your question,
has been busy fighting some fires.)
I'm trying to understand what the PEP is saying and how you're
interpreting, and I'm not getting very far. I kn
[originally I sent this to typing-sig but I guess it got caught up in
moderation.]
In PEP 554 [1] it says:
- Implement metaclass functionality to detect whether a class is a
protocol or not. Add a class attribute _is_protocol = True if that is
the case. Verify that a protocol class only
On Sun, Oct 7, 2018 at 7:55 AM Guido van Rossum wrote:
>
> OK, then maybe someone (not me) can merge
> https://github.com/python/peps/pull/799 for me.
>
Per discussion, merged.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
OK, then maybe someone (not me) can merge
https://github.com/python/peps/pull/799 for me.
On Sat, Oct 6, 2018 at 7:54 AM Nick Coghlan wrote:
> On Sat, 6 Oct 2018 at 07:57, Brett Cannon wrote:
> >
> > I think whatever governance we end up with would have named you
> BDFL-delegate anyway, Guido,
On Sat, 6 Oct 2018 at 07:57, Brett Cannon wrote:
>
> I think whatever governance we end up with would have named you BDFL-delegate
> anyway, Guido, so I think you're just taking the time machine for a spin
> again. ;)
I was going to suggest that Guido list himself as BDFL-Delegate as
then it co
I think whatever governance we end up with would have named you
BDFL-delegate anyway, Guido, so I think you're just taking the time machine
for a spin again. ;)
On Wed, 3 Oct 2018 at 09:40, Guido van Rossum wrote:
> The process for PEP 544 is off-topic for that thread so I'm starting a new
> one
The process for PEP 544 is off-topic for that thread so I'm starting a new
one.
I have promised its author to approve it after certain minor changes (that
we both agree on) have been made. It's not an example of how PEP acceptance
in general will works until governance is sorted out though -- PEP
On 30 June 2018 at 23:54, Tin Tvrtković wrote:
> [...]
>
> An attrs class has a special class-level field, __attrs_attrs__, which
> holds the attribute definitions. So maybe we can define a protocol:
>
> class AttrsClass(Protocol):
> __attrs_attrs__: ClassVar[Tuple[Attribute, ...]]
>
> then w
Hi,
PEP 544 specifies this address as "Discussions-To" so I hope I'm at the
right address.
I think protocols as defined in the PEP are a very interesting idea and I'm
thinking of ways of applying them. The first use case is in the context of
attrs.
attrs has a number of functions that work only
On Wed, Oct 04, 2017 at 03:56:14PM -0700, VERY ANONYMOUS wrote:
> i want to learn
Start by learning to communicate in full sentences. You want to learn
what? Core development? Python? How to program? English?
This is not a mailing list for Python beginners. Try the "tutor" or
"python-list" mai
i want to learn
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Python-Dev 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 tests.
Note that pytypes (https://github.com/Stewori/pytypes) already supports this.
It can dump PEP 484 style
uot;
Cc: Python-Dev
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 the concepts of 'runtime' and 'static' types as implied by p
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 concept) and classes (a runtime c
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
> type
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 events.
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 wrote:
>>> [...]
>>>
>>> Thank you for very detailed answers! I have pra
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 nothing to add.
>> It seems to me that most of the Kevin's
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 unnecessary
> focus
> on runtime type check
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:
* Add the word "static"
[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 what one would normally do in
>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 register
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 typing)" -- hope
> that's not too long to fit
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 as "Interfaces". What is unique about this proposal
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 industry standard language?
> 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, beyond
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 for
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 to ABCs. It just
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 of
> the PEP as is cur
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 this
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 discussion on python-dev
> >> https://mail.python.org/pipermail/pyth
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
>> https://mail.python.org/pipermail/python-dev/2017-March/thread.html#147629
>> and playing with i
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 version of PEP 544.
>
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
A link for those who don't like reading long e-mails:
https://
On Tue, Mar 21, 2017 at 11:05 AM, Ivan Levkivskyi
wrote:
> There are two places where PEP draft says:
>
> "Note that there is no conceptual difference between explicit and implicit
> subtypes"
>
> and
>
> "The general philosophy is that protocols are mostly like regular ABCs,
> but a static type
On 21 March 2017 at 18:03, Brett Cannon wrote:
> I do think it's fine, though, to make it very clear that whether you
> subclass or not makes absolutely no difference to tools validating the type
> soundness of the code.
>
There are two places where PEP draft says:
"Note that there is no concep
On Tue, 21 Mar 2017 at 09:17 Matthias Kramm via Python-Dev <
python-dev@python.org> wrote:
> On Mon, Mar 20, 2017 at 2:42 PM, Ivan Levkivskyi
> wrote:
>
> 1. Backward compatibility: People are already using ABCs, including
> generic ABCs from typing module.
> If we prohibit explicit subclassing o
Technically, `__eq__` is implemented by `object` so a `Mapping`
implementation that didn't implement it would still be considered valid.
But probably not very useful (since the default implementation in this case
is implemented by comparing object identity).
On Tue, Mar 21, 2017 at 9:36 AM, Ivan L
On 21 March 2017 at 17:09, Matthias Kramm wrote:
>
> The one thing that isn't clear to me is how type checkers will distinguish
> between
> 1.) Protocol methods in A that need to implemented in B so that B is
> considered a structural subclass of A.
> 2.) Extra methods you get for free when you e
On Mon, Mar 20, 2017 at 2:42 PM, Ivan Levkivskyi
wrote:
> 1. Backward compatibility: People are already using ABCs, including
> generic ABCs from typing module.
> If we prohibit explicit subclassing of these ABCs, then quite a lot of
> code will break.
>
Fair enough. Backwards compatibility is a
On 21 March 2017 at 00:23, Barry Warsaw wrote:
> On Mar 20, 2017, at 01:00 PM, Ivan Levkivskyi wrote:
>
> [SNIP]
>
> IIUC, the Python 3 way to spell this is with a decorator.
>
Thanks, I will update this.
> [SNIP]
> (also, since this is Python 3, do you really need to inherit from object?)
>
On Mar 20, 2017, at 01:00 PM, Ivan Levkivskyi wrote:
>from zope.interface import Interface, Attribute, implements
>
>class IEmployee(Interface):
>
>name = Attribute("Name of employee")
>
>def do(work):
>"""Do some work"""
>
>class Employee(object):
>
On 20 March 2017 at 22:11, Matthias Kramm wrote:
> I'm a big fan of this. I really want structural subtyping for
> http://github.com/google/pytype.
>
>
I am glad you like it.
>
>
On Mon, Mar 20, 2017 at 5:00 AM, Ivan Levkivskyi
> wrote:
>
>> Explicitly declaring implementation
>> -
I'm a big fan of this. I really want structural subtyping for
http://github.com/google/pytype.
On Mon, Mar 20, 2017 at 5:00 AM, Ivan Levkivskyi
wrote:
> Explicitly declaring implementation
> ---
>
> To explicitly declare that a certain class implements the given p
On Mon, Mar 20, 2017, at 14:07, Brett Cannon wrote:
> What is a "trivial body"? I don't know of any such definition anywhere in
> Python so this is too loosely defined. You also don't say what happens if
> the body isn't trivial. Are tools expected to raise an error?
My assumption would be that a
On 20 March 2017 at 19:07, Brett Cannon wrote:
> I'm overall very supportive of seeing something like this make it into
> Python to further strengthen duck typing in the language.
>
Thanks!
> Personally, I think even an abstract method should be properly typed.
>
[SNIP]
>
or raise NotImplement
I'm overall very supportive of seeing something like this make it into
Python to further strengthen duck typing in the language. I know I've
wanted something something like this since ABCs were introduced.
I personally only have one issue/clarification for the PEP.
On Mon, 20 Mar 2017 at 05:02 Iv
Hi all,
PEP 484 specifies semantics for type hints. These type hints are used by
various tools, including static type checkers. However, PEP 484 only
specifies the semantics for nominal subtyping (subtyping based on
subclassing). Here we propose a specification for semantics of structural
subtypin
50 matches
Mail list logo
