[Python-ideas] typing.modifiers

[אלעזר]

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 tuple. (No "+" or "*" operators)

There of course may be others. Subclasses of the modifiers get default
methods and behavior.
The modifiers can used in combinations. For example:

class Command(Immutable, Named):
cmd : str = "NOP"
value : int = None

load = Command(cmd="load", value=1000)  # no positional arguments

The syntax for Array is less pretty:

class Command(Array):
_0 : str = "NOP"
_1 : int = None

load = Command("load", 1000)  # no positional arguments

Many other combinations are useful too. "Sealed" is almost orthogonal to
the others,  Obviously, some combinations already exists:
  * (Immutable, Array) is similar to Tuple
  * NamedTuple is another name for (Immutable, Named, Array).
  * Enum should be on this list too

Some less promising modifiers:
  * Namespace / Static: uninstantiable class. A module.
  * Volatile, for externally facing classes. Hints the static checkers /
jitters that they should not assume they know the values.
 * Abstract

Alternatives and cons :
I suggest base classes instead of decorators since NamedTuple and tuple go
this way, and since it is static information. I am not sure which is better
though.
Metaclass parameters can be used (and actually used in my implementation,
and in NamedTuple's), but the syntax is uglier.
"array" is only for numeric values in Python, so this name is
problematic.So is struct.

I have a rough implementation for most of the above; much of it is not hard
in general, though some details are hard to get right.
---

Benefits of putting such a collection in stdlib (instead of as an external
package) include:
1. This information can be used by typecheckers, and also by users, to
reason about programs. If isinstance(x, ImmutableArray), then x is an
instantiation of ImmutableArray.
2. A conventional syntax and a single answer for "How do I make my class
immutable", "How do I make my class unsubclassable"
3. The syntax, especially for Struct as above, is pretty and clean. The
Array syntax is less so.
4. I think that the array implementation can use internal CPython details
to be implemented efficiently.

I am not sure that typing.modifiers is the right place, since these are not
exactly type hints; they generate methods, and are intended to be enforced
at runtime.

I think that even if this idea is not accepted, the general theme is
something that might be useful to keep in mind, stdlib might accumulate
such modifiers, and it will be nice to keep things uniform.

Opinions?

~Elazar
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Naming convention for Enums

[Steven D'Aprano]

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 follow a naming convention accordingly.
> >> Uppercase if you're basically making constants; lowercase if you're
> >> not; etcetera.
> >
> > I can't think of any situation where Enums would *not* be treated as
> > constants. Can you give an example?
> 
> 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 Color.blue. Even though they happen to have
> integer values, they're not intended to be used as actual integers.

Yes, but when would you write something like this?

Color.red = 


That's not to be confused with the case:

text_colour = Color.RED
# later...
text_colour = Color.BLUE

where *text_colour* is clearly used as a variable, not a constant. But 
the enumerations themselves are still constant.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Naming convention for Enums

[Chris Angelico]

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 Color.blue. Even though they happen to have
>> integer values, they're not intended to be used as actual integers.
>> For those cases, it's not as clear that they ought to be Color.RED and
>> Color.BLUE - it's equally acceptable to have them in lowercase.
>
> I disagree. The whole point of an enum is to define a new *kind* of
> constant. Clearly RED and BLUE are new constants. (The uppercase
> convention is not just for giving names to literals -- that's not what
> "constant" means.)

Well, my view was largely colored [1] by the official docs. Your view
is broadly the same as my ideal preference, just without the caveats
and flexibility of accepting it the other way. So should the docs be
updated to upper-case everything?

With or without an actual PEP 8 change, that would send a strong
message to the community. I'm sure I'm not the only person who looks
at official examples as a style guide as well as a syntax demo.

ChrisA

[1] Sorry [2], that pun was just terrible
[2] Actually I'm not sorry. But the pun was still terrible.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Naming convention for Enums

[Guido van Rossum]

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 naming convention accordingly.
>>> Uppercase if you're basically making constants; lowercase if you're
>>> not; etcetera.
>>
>> I can't think of any situation where Enums would *not* be treated as
>> constants. Can you give an example?
>
> 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 Color.blue. Even though they happen to have
> integer values, they're not intended to be used as actual integers.
> For those cases, it's not as clear that they ought to be Color.RED and
> Color.BLUE - it's equally acceptable to have them in lowercase.

I disagree. The whole point of an enum is to define a new *kind* of
constant. Clearly RED and BLUE are new constants. (The uppercase
convention is not just for giving names to literals -- that's not what
"constant" means.)

> But if one convention or the other had to be picked for all enums, I
> would go with all-caps, since they're most often going to be
> representing constant integers, per Guido's post. I don't know of
> _any_ real-world cases where they're not integers, though there are
> some examples in the docs.

Amen.

> ChrisA
>
> [1] https://docs.python.org/3/library/enum.html

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Naming convention for Enums

[Chris Angelico]

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 making constants; lowercase if you're
>> not; etcetera.
>
> I can't think of any situation where Enums would *not* be treated as
> constants. Can you give an example?

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 Color.blue. Even though they happen to have
integer values, they're not intended to be used as actual integers.
For those cases, it's not as clear that they ought to be Color.RED and
Color.BLUE - it's equally acceptable to have them in lowercase.

But if one convention or the other had to be picked for all enums, I
would go with all-caps, since they're most often going to be
representing constant integers, per Guido's post. I don't know of
_any_ real-world cases where they're not integers, though there are
some examples in the docs.

ChrisA

[1] https://docs.python.org/3/library/enum.html
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Naming convention for Enums

[Ethan Furman]

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; lowercase if you're
not; etcetera.


I can't think of any situation where Enums would *not* be treated as
constants. Can you give an example?


Besides being CONSTANTS enum members are also Singletons, and since I find 
CamelCase easier to read than UPPERCASE I may use that instead; otherwise I 
leave it all lowercase.

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Naming convention for Enums

[Steven D'Aprano]

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 think of any situation where Enums would *not* be treated as 
constants. Can you give an example?


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Generics Syntax

[אלעזר]

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  wrote:

> 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__(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 "", line 1, in 
> 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   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Generics Syntax

[Nick Coghlan]

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__(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 "", line 1, in 
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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Generics Syntax

[אלעזר]

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:
>>
>>> 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
>>
>>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Generics Syntax

[אלעזר]

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 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
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Generics Syntax

[Ivan Levkivskyi]

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
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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Generics Syntax

[אלעזר]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/