It's probably big enough to make it a new PEP.
On Wed, Jan 18, 2017 at 7:45 AM, Ivan Levkivskyi
wrote:
> On 18 January 2017 at 16:35, Guido van Rossum wrote:
>
>> I'd rather wait until support for protocols has been added to PEP 484.
>>
>
> Sorry for offtopic but do you think this should be an
On 18 January 2017 at 16:35, Guido van Rossum wrote:
> I'd rather wait until support for protocols has been added to PEP 484.
>
Sorry for offtopic but do you think this should be an addition to PEP 484
or a separate PEP?
I am interested in writing the specification (based on what Jukka proposed
I'd rather wait until support for protocols has been added to PEP 484.
On Wed, Jan 18, 2017 at 2:25 AM, Ivan Levkivskyi
wrote:
> A random thought: typing has ABCs for protocols, even more than
> collections.abc has (e.g. typing.SupportsInt). Some support for descriptors
> has been added to mypy
A random thought: typing has ABCs for protocols, even more than
collections.abc has (e.g. typing.SupportsInt). Some support for descriptors
has been added to mypy recently.
Maybe it makes sense to add support for descriptor protocol in typing?
--
Ivan
On 18 January 2017 at 05:44, Raymond Hetting
> On Jan 17, 2017, at 11:41 AM, Roberto Martínez
> wrote:
>
> Oh, I understand. Maybe is not worth the effort anyway.
FWIW, I'm also in the camp of thinking it is not worth the effort. Until there
is a demonstrated need (something than can't be met by checking for __set__),
the default posi
Oh, I understand. Maybe is not worth the effort anyway.
Thank you
El mar., 17 ene. 2017 a las 19:40, Guido van Rossum ()
escribió:
But you can never get people to use the new ABCs consistently.
Anyway, I'm not -1, I'm just -0 -- I don't think it'll make any difference
and you're better off just
But you can never get people to use the new ABCs consistently.
Anyway, I'm not -1, I'm just -0 -- I don't think it'll make any difference
and you're better off just checking for __set__ (if it only has __set__ but
not __get__, do you care what it is?).
On Tue, Jan 17, 2017 at 10:18 AM, Roberto Ma
Well, for me having to check both __get__ and __str__ for a data descriptor
feels inelegant.
After read the documentation of collections.abc again "This module provides
abstract base classes that can be used to test whether a class provides a
particular interface; for example, whether it is hashab
For this use case I see nothing wrong with hasattr(myobj, '__set__').
On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
> I need to check if some objects obey the descriptor protocol in the
> construction of a metaclass. I expect to be able to write something
I need to check if some objects obey the descriptor protocol in the
construction of a metaclass. I expect to be able to write something like:
if isinstance(myobj, abc.DataDescriptor):
# do something
The other idea crossing my mind is something like:
if all(hasattr(myobj, attr) for attr in ('_
Well, these are an example of the purest duck typing. Just implement
__get__ and/or __set__ (and __delete__) and you're good.
What's the situation where you miss them?
--Guido
On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
> Hi,
>
> I miss abstract base c
Hi,
I miss abstract base classes in collections.abc implementing the descriptor
protocol. Any reason why they do not exist?
What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
Best regards,
Roberto
___
Python-Dev mailing list
Python-
12 matches
Mail list logo
