This suggestion is so obvious that it's likely has been discussed, but I can't find any reference (It's not what PEP-3124 talks about). Generic class syntax, now: _T_co = TypeVar('_T', covariant=True) class Container(Generic[_T_co]): @abstractmethod def __contains__(self, x: _T_co) -> bool: ... (yes it's object in reality) Generic class syntax, suggested: class Container[+T]: @abstractmethod def __contains__(self, x: T) -> bool: ... The + signifies covariant type, as in Scala. The need for underscore prefix and explicit name for covariant types is gone, since it's class-scoped. The + is a bit cryptic, but so are term "covariant" and Generic[_T_co]. The syntax by large is exactly what users coming from statically-typed languages will expect. Giving a bound can be done using "T <: AnyStr", "T: AnyStr" or any other syntax. Again, I assume it was discussed before, but my Google skills are failing me; a pointer will be helpful. ~Elazar
On 15 September 2016 at 11:21, אלעזר <elazarg@gmail.com> wrote:
This suggestion is so obvious that it's likely has been discussed, but I can't find any reference (It's not what PEP-3124 talks about).
You might want to read this tread https://github.com/python/typing/issues/211 and another tread mentioned there at the start. In short, this idea has been discussed, but nobody had seen it as good enough to sacrifice his time for implementing the changes. -- Ivan
Does that mean that if I did, it would be reconsidered? On Thu, Sep 15, 2016 at 12:43 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 15 September 2016 at 11:21, אלעזר <elazarg@gmail.com> wrote:
This suggestion is so obvious that it's likely has been discussed, but I can't find any reference (It's not what PEP-3124 talks about).
You might want to read this tread https://github.com/python/typing/issues/211 and another tread mentioned there at the start. In short, this idea has been discussed, but nobody had seen it as good enough to sacrifice his time for implementing the changes.
-- Ivan
And that thread is only about variance. What about the generic syntax? On Thu, Sep 15, 2016 at 12:44 PM אלעזר <elazarg@gmail.com> wrote:
Does that mean that if I did, it would be reconsidered?
On Thu, Sep 15, 2016 at 12:43 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 15 September 2016 at 11:21, אלעזר <elazarg@gmail.com> wrote:
This suggestion is so obvious that it's likely has been discussed, but I can't find any reference (It's not what PEP-3124 talks about).
You might want to read this tread https://github.com/python/typing/issues/211 and another tread mentioned there at the start. In short, this idea has been discussed, but nobody had seen it as good enough to sacrifice his time for implementing the changes.
-- Ivan
On 15 September 2016 at 11:46, אלעזר <elazarg@gmail.com> wrote:
And that thread is only about variance. What about the generic syntax?
If you mean code like this: class Container[+T]: @abstractmethod def __contains__(self, x: T) -> bool: ... then there is little chance that this will be accepted because it requires changes to Python syntax. You have how much friction PEP 526 caused, here it will be even more.
On Thu, Sep 15, 2016 at 12:44 PM אלעזר <elazarg@gmail.com> wrote:
Does that mean that if I did, it would be reconsidered?
Maybe, Guido will decide on this. -- Ivan
On 15 September 2016 at 19:53, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 15 September 2016 at 11:46, אלעזר <elazarg@gmail.com> wrote:
And that thread is only about variance. What about the generic syntax?
If you mean code like this:
class Container[+T]: @abstractmethod def __contains__(self, x: T) -> bool: ...
then there is little chance that this will be accepted because it requires changes to Python syntax.
If the proposed spelling is tweaked to be "class Container(Generic[+T]):", then it doesn't require a syntax change, as that's merely a matter of implementing unary plus on type vars: >>> +object() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for unary +: 'object' >>> class UnaryPlus: ... def __pos__(self): ... return self ... >>> +UnaryPlus() <__main__.UnaryPlus object at 0x7f5e0fe91c50> (I have no opinion on the value of providing a simpler spelling for covariance, I'm just noting that if you keep the "Generic[T]" aspect of the current spelling it wouldn't require any changes to Python's syntax and will work as far back as you care to support it) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Yes the "class A[T]:" syntax requires on the ability to express variance as an operator, but not the other way around. It might be an argument in favor of switching to the + syntax: to make possible future syntax change in class definition somewhat easier to swallow. ~Elazar On Thu, Sep 15, 2016 at 2:03 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
On 15 September 2016 at 19:53, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 15 September 2016 at 11:46, אלעזר <elazarg@gmail.com> wrote:
And that thread is only about variance. What about the generic syntax?
If you mean code like this:
class Container[+T]: @abstractmethod def __contains__(self, x: T) -> bool: ...
then there is little chance that this will be accepted because it
requires
changes to Python syntax.
If the proposed spelling is tweaked to be "class Container(Generic[+T]):", then it doesn't require a syntax change, as that's merely a matter of implementing unary plus on type vars:
>>> +object() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: bad operand type for unary +: 'object' >>> class UnaryPlus: ... def __pos__(self): ... return self ... >>> +UnaryPlus() <__main__.UnaryPlus object at 0x7f5e0fe91c50>
(I have no opinion on the value of providing a simpler spelling for covariance, I'm just noting that if you keep the "Generic[T]" aspect of the current spelling it wouldn't require any changes to Python's syntax and will work as far back as you care to support it)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 15 September 2016 at 21:11, אלעזר <elazarg@gmail.com> wrote:
Yes the "class A[T]:" syntax requires on the ability to express variance as an operator, but not the other way around.
It might be an argument in favor of switching to the + syntax: to make possible future syntax change in class definition somewhat easier to swallow.
A future syntax change is very unlikely, as people encountering "class SomeName(Generic[+T]):" for the first time can easily google "python generic class" and hopefully find useful answers in the documentation for typing.Generic. By contrast, "class SomeName[+T]:" would have to be covered directly in the class statement documentation, which runs completely counter to the notion of type hints as executable code annotations (rather than being an unavoidable core part of the language the way they are in statically typed languages). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Ivan Levkivskyi -
Nick Coghlan -
אלעזר