With the new variable annotation syntax, it is possible to implement a
useful "modifiers" library, all used as superclasses.
Possible modifiers:
* Named / Struct: annotation-defined fields. No monkey patching.
* Immutable / Const
* Sealed / Final: unsubclassable class
* Array: a mutable tu
On Fri, Sep 16, 2016 at 4:26 AM, Guido van Rossum wrote:
> Please update the docs.
Roger that.
http://bugs.python.org/issue28172
ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of
On Fri, Sep 16, 2016 at 03:54:18AM +1000, Chris Angelico wrote:
> On Fri, Sep 16, 2016 at 3:03 AM, Steven D'Aprano wrote:
> > On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
> >
> >> Perhaps the advice needs to be along the lines of: Decide what the
> >> purpose of the enum is, and
Please update the docs.
On Thu, Sep 15, 2016 at 11:14 AM, Chris Angelico wrote:
> On Fri, Sep 16, 2016 at 4:06 AM, Guido van Rossum wrote:
>>> Sometimes they function as integer constants (esp IntEnum), and
>>> sometimes more as just arbitrary values. See the examples in the docs
>>> [1] for Col
On Fri, Sep 16, 2016 at 4:06 AM, Guido van Rossum wrote:
>> Sometimes they function as integer constants (esp IntEnum), and
>> sometimes more as just arbitrary values. See the examples in the docs
>> [1] for Color and Mood, where the exact value is immaterial, just as
>> long as Color.red is not C
On Thu, Sep 15, 2016 at 10:54 AM, Chris Angelico wrote:
> On Fri, Sep 16, 2016 at 3:03 AM, Steven D'Aprano wrote:
>> On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
>>
>>> Perhaps the advice needs to be along the lines of: Decide what the
>>> purpose of the enum is, and follow a n
On Fri, Sep 16, 2016 at 3:03 AM, Steven D'Aprano wrote:
> On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
>
>> Perhaps the advice needs to be along the lines of: Decide what the
>> purpose of the enum is, and follow a naming convention accordingly.
>> Uppercase if you're basically
On 09/15/2016 10:03 AM, Steven D'Aprano wrote:
On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
Perhaps the advice needs to be along the lines of: Decide what the
purpose of the enum is, and follow a naming convention accordingly.
Uppercase if you're basically making constants;
On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
> Perhaps the advice needs to be along the lines of: Decide what the
> purpose of the enum is, and follow a naming convention accordingly.
> Uppercase if you're basically making constants; lowercase if you're
> not; etcetera.
I can't
On 15 September 2016 at 21:11, אלעזר 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 some
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
On 15 September 2016 at 19:53, Ivan Levkivskyi wrote:
>
>
> On 15 September 2016 at 11:46, אלעזר 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__
On 15 September 2016 at 11:46, אלעזר 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 a
And that thread is only about variance. What about the generic syntax?
On Thu, Sep 15, 2016 at 12:44 PM אלעזר wrote:
> Does that mean that if I did, it would be reconsidered?
>
> On Thu, Sep 15, 2016 at 12:43 PM Ivan Levkivskyi
> wrote:
>
>> On 15 September 2016 at 11:21, אלעזר wrote:
>>
Does that mean that if I did, it would be reconsidered?
On Thu, Sep 15, 2016 at 12:43 PM Ivan Levkivskyi
wrote:
> On 15 September 2016 at 11:21, אלעזר 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 a
On 15 September 2016 at 11:21, אלעזר 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
the
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,
17 matches
Mail list logo
