Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-05 Thread Wolfgang 
Hi,

first if something like this is needed I am fine with the syntax.

But I think this changes comes to late for 3.6. There is more time needed
to discuss all of this and there is more time needed to mature the type
checkers. Don't rush with such a change because it affects the language at 
whole.
So please defer it.

Saying the syntax is fine means not I am happy with the addition.
Fundamentally I think don't add this at Python language syntax level.
Years come and it will be misused misunderstood by new users.
It will affect all other users reading the code and even misguiding them.

If Variable and Attribute Annotation is needed keep it simply at the
stub file level on *.pyi files. Only there for the type checking stuff.
Other users must not bother with them.

And for stub files it can be as simple as:

myvar = typing.Int()

or all other valid syntax.


For me the whole specifying of types in Python comes down to:
It can be useful to document a user interface (most of the time a function
or method) and say if you call it these types are supported.

At some day a documentation generator can use this type information
and I have no longer the need to specify it also in the docstring.

Personally I would like to extend the pyi stub files to carry also the
documentation and keep the code as clean and short as possible.
Sometimes the documentation is longer than the code and the code is no longer
easy to find.
Instead of putting everything into the language put more into the stub files.
Even micropython or other implementations with limited constraints don't need
to carry all of this. Even if it is only part of the AST, it is overhead.


Have someone checked if there is a possibility if this is added to slow
down the interpreter or interpreter startup or increase the memory
consumption?


Regards,

Wolfgang


On 30.08.2016 23:20, Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:
> https://www.python.org/dev/peps/pep-0526/ (HTML)
> https://github.com/python/peps/blob/master/pep-0526.txt (source)
> 
> There's also an implementation ready:
> https://github.com/ilevkivskyi/cpython/tree/pep-526
> 
> I don't want to post the full text here but I encourage feedback on
> the high-order ideas, including but not limited to
> 
> - Whether (given PEP 484's relative success) it's worth adding syntax
> for variable/attribute annotations.
> 
> - Whether the keyword-free syntax idea proposed here is best:
>   NAME: TYPE
>   TARGET: TYPE = VALUE
> 
> Note that there's an extensive list of rejected ideas in the PEP;
> please be so kind to read it before posting here:
> https://www.python.org/dev/peps/pep-0526/#rejected-proposals-and-things-left-out-for-now
> 
> 

___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-05 Thread Wolfgang 
Hi,

first if something like this is needed I am fine with the syntax.

But I think this changes comes to late for 3.6. There is more time needed
to discuss all of this and there is more time needed to mature the type
checkers. Don't rush with such a change because it affects the language at 
whole.
So please defer it.

Saying the syntax is fine means not I am happy with the addition.
Fundamentally I think don't add this at Python language syntax level.
Years come and it will be misused misunderstood by new users.
It will affect all other users reading the code and even misguiding them.

If Variable and Attribute Annotation is needed keep it simply at the
stub file level on *.pyi files. Only there for the type checking stuff.
Other users must not bother with them.

And for stub files it can be as simple as:

myvar = typing.Int()

or all other valid syntax.


For me the whole specifying of types in Python comes down to:
It can be useful to document a user interface (most of the time a function
or method) and say if you call it these types are supported.

At some day a documentation generator can use this type information
and I have no longer the need to specify it also in the docstring.

Personally I would like to extend the pyi stub files to carry also the
documentation and keep the code as clean and short as possible.
Sometimes the documentation is longer than the code and the code is no longer
easy to find.
Instead of putting everything into the language put more into the stub files.
Even micropython or other implementations with limited constraints don't need
to carry all of this. Even if it is only part of the AST, it is overhead.


Have someone checked if there is a possibility if this is added to slow
down the interpreter or interpreter startup or increase the memory
consumption?


Regards,

Wolfgang


On 30.08.2016 23:20, Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:
> https://www.python.org/dev/peps/pep-0526/ (HTML)
> https://github.com/python/peps/blob/master/pep-0526.txt (source)
> 
> There's also an implementation ready:
> https://github.com/ilevkivskyi/cpython/tree/pep-526
> 
> I don't want to post the full text here but I encourage feedback on
> the high-order ideas, including but not limited to
> 
> - Whether (given PEP 484's relative success) it's worth adding syntax
> for variable/attribute annotations.
> 
> - Whether the keyword-free syntax idea proposed here is best:
>   NAME: TYPE
>   TARGET: TYPE = VALUE
> 
> Note that there's an extensive list of rejected ideas in the PEP;
> please be so kind to read it before posting here:
> https://www.python.org/dev/peps/pep-0526/#rejected-proposals-and-things-left-out-for-now
> 
> 

___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-03 Thread Yury Selivanov 



On 2016-08-30 2:20 PM, Guido van Rossum wrote:

I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)

There's also an implementation ready:
https://github.com/ilevkivskyi/cpython/tree/pep-526

I don't want to post the full text here but I encourage feedback on
the high-order ideas, including but not limited to

- Whether (given PEP 484's relative success) it's worth adding syntax
for variable/attribute annotations.

- Whether the keyword-free syntax idea proposed here is best:
   NAME: TYPE
   TARGET: TYPE = VALUE


I'm in favour for the PEP, and I like the syntax.  I find it much better 
than any previously discussed alternatives.


Static typing is becoming increasingly more popular, and the benefits of 
using static type checkers for big code bases are clear.  The PEP 
doesn't really change the semantics of the language, it only allows 
better tooling (using comments for annotations was fine too, but 
dedicated syntax makes this feature a first class citizen).


Yury

___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-03 Thread Nick Coghlan 
On 3 September 2016 at 02:17, Guido van Rossum  wrote:
> Pinning down the semantics is not why I am pushing for PEP 526 -- I
> only want to pin down the *syntax* to the point where we won't have to
> change it again for many versions, since it's much harder to change
> the syntax than it is to change the behavior of type checkers (which
> have fewer backwards compatibility constraints, a faster release
> cycle, and narrower user bases than core Python itself).

+1 from me as well for omitting any new type semantics that aren't
absolutely necessary from the PEP (i.e. nothing beyond ClassVar) - I
only figured it was worth bringing up here as the question had already
arisen.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-02 Thread Ivan Levkivskyi 
On 2 September 2016 at 18:17, Guido van Rossum  wrote:
> On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi 
wrote:
> > On 2 September 2016 at 04:38, Nick Coghlan  wrote:
> >> However, a standalone Ellipsis doesn't currently have a meaning as a
> >> type annotation (it's only meaningful when subscripting Tuple and
> >> Callable), so a spelling like this might work:
> >>
> >> NAME: ...
> >>
> >> That spelling could then also be used in function definitions to say
> >> "infer the return type from the return statements rather than assuming
> >> Any"
> >
> > Interesting idea.
> > This is somehow similar to one of the existing use of Ellipsis: in
numpy it
> > infers how many dimensions needs to have the full slice, it is like
saying
> > "You know what I mean". So I am +1 on this solution.
>
> I like it too, but I think it's better to leave any firm promises
> about the *semantics* of variable annotations out of the PEP. I just
> spoke to someone who noted that the PEP is likely to evoke an outsize
> emotional response. (Similar to what happened with PEP 484.)
>
> Pinning down the semantics is not why I am pushing for PEP 526 -- I
> only want to pin down the *syntax* to the point where we won't have to
> change it again for many versions, since it's much harder to change
> the syntax than it is to change the behavior of type checkers (which
> have fewer backwards compatibility constraints, a faster release
> cycle, and narrower user bases than core Python itself).

This is a good point. I totally agree.

--
Ivan
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-02 Thread Guido van Rossum 
On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi  wrote:
> On 2 September 2016 at 04:38, Nick Coghlan  wrote:
>> However, a standalone Ellipsis doesn't currently have a meaning as a
>> type annotation (it's only meaningful when subscripting Tuple and
>> Callable), so a spelling like this might work:
>>
>> NAME: ...
>>
>> That spelling could then also be used in function definitions to say
>> "infer the return type from the return statements rather than assuming
>> Any"
>
> Interesting idea.
> This is somehow similar to one of the existing use of Ellipsis: in numpy it
> infers how many dimensions needs to have the full slice, it is like saying
> "You know what I mean". So I am +1 on this solution.

I like it too, but I think it's better to leave any firm promises
about the *semantics* of variable annotations out of the PEP. I just
spoke to someone who noted that the PEP is likely to evoke an outsize
emotional response. (Similar to what happened with PEP 484.)

Pinning down the semantics is not why I am pushing for PEP 526 -- I
only want to pin down the *syntax* to the point where we won't have to
change it again for many versions, since it's much harder to change
the syntax than it is to change the behavior of type checkers (which
have fewer backwards compatibility constraints, a faster release
cycle, and narrower user bases than core Python itself).

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-02 Thread Ivan Levkivskyi 
On 1 September 2016 at 22:37, Guido van Rossum  wrote:
> On Thu, Sep 1, 2016 at 9:30 AM, Ivan Levkivskyi 
wrote:
> > There is a convention for function annotations in PEP 484 that a missing
> > annotation is equivalent to Any, so that I like your first option more.
>
> But Steven wasn't proposing it to mean Any, he was proposing it to
> mean "type checker should infer". Where I presume the inference should
> be done based on the assignment in __init__ only.

Sorry for misunderstanding.

On 2 September 2016 at 04:38, Nick Coghlan  wrote:
> However, a standalone Ellipsis doesn't currently have a meaning as a
> type annotation (it's only meaningful when subscripting Tuple and
> Callable), so a spelling like this might work:
>
> NAME: ...
>
> That spelling could then also be used in function definitions to say
> "infer the return type from the return statements rather than assuming
> Any"

Interesting idea.
This is somehow similar to one of the existing use of Ellipsis: in numpy it
infers how many dimensions needs to have the full slice, it is like saying
"You know what I mean". So I am +1 on this solution.

--
Ivan
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Nick Coghlan 
On 2 September 2016 at 02:21, Steven D'Aprano  wrote:
> Unless I've missed something, there's no way to pre-declare an instance
> attribute without specifying a type. (Even if that type is Any.) So how
> about we allow None as a type-hint on its own:
>
> NAME: None

None already has a meaning as an annotation - it's a shorthand for "type(None)".

While for variables and parameters, that's usually only seen in
combination with Union, and even though Union[T, None] has a preferred
spelling as Optional[T], there's also the "-> None" case to specify
that a function doesn't return a value. Having "-> None" mean "no
return value" and "NAME: None" mean "infer type from later assignment"
would be quite confusing.

However, a standalone Ellipsis doesn't currently have a meaning as a
type annotation (it's only meaningful when subscripting Tuple and
Callable), so a spelling like this might work:

NAME: ...

That spelling could then also be used in function definitions to say
"infer the return type from the return statements rather than assuming
Any":

def inferred_return_type(): -> ...
return some_other_function()

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Guido van Rossum 
On Thu, Sep 1, 2016 at 9:30 AM, Ivan Levkivskyi  wrote:
> On 1 September 2016 at 18:21, Steven D'Aprano  wrote:
[...]
>> Unless I've missed something, there's no way to pre-declare an instance
>> attribute without specifying a type. (Even if that type is Any.) So how
>> about we allow None as a type-hint on its own:
>>
>> NAME: None
>>
>> as equivalent to a declaration *without* a hint. The reader, and the
>> type-checker, can see that there's an instance attribute called NAME,
>> but in the absense of an actual hint, the type will have to be inferred,
>> just as if it wasn't declared at all.

> There is a convention for function annotations in PEP 484 that a missing
> annotation is equivalent to Any, so that I like your first option more.

But Steven wasn't proposing it to mean Any, he was proposing it to
mean "type checker should infer". Where I presume the inference should
be done based on the assignment in __init__ only.

I'm not sure if this needs special syntax (a type checker might behave
the same way without this, so we could just use a comment) but even if
we did decide we wanted to support

  NAME: None

for this case, we don't have to change Python, since this already
conforms to the syntax in PEP 526 (the type is None). We'd still have
to update the PEP to tell the authors of type checkers about this
special feature, since otherwise it would mean "NAME has type
NoneType" (remember that PEP 484 defines None as a shortcut for
NoneType == type(None)). But that's not a very useful type for a
variable...

But I'm not in a hurry for that -- I'm only hoping to get the basic
syntax accepted by Python 3.6 beta 1 so that we can start using this
in 5 years from now rather than 7 years from now.

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Guido van Rossum 
On Thu, Sep 1, 2016 at 10:01 AM, Koos Zevenhoven  wrote:
> On Thu, Sep 1, 2016 at 5:46 PM, Guido van Rossum  wrote:
>> IOW, PEP 3157 is not dead yet. Indeed.
>>
>
> PEP 3157? Is that a typo or is there such a thing somewhere?

Sorry, 3107 (the original Function Annotations PEP).

> [...]
> I hope there will at least be a recommendation somewhere (PEP 8?) to not
> mix the two styles of attribute annotation (beginning of class / in
> method). The whole readability benefit turns against itself if there
> are some non-ClassVar variables annotated outside __init__ and then
> the rest somewhere in __init__ and in whatever initialization helper
> methods __init__ happens to call.

Yeah, but then again, in general I don't believe you can legislate the
writing of readable code using crude syntactic means. Not mixing the
two in the same class sounds like pretty good advice though, and a
linter should be able to catch that easily.

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Guido van Rossum 
On Thu, Sep 1, 2016 at 10:30 AM, Steven D'Aprano  wrote:
> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
>
>> - Whether (given PEP 484's relative success) it's worth adding syntax
>> for variable/attribute annotations.
>
> The PEP makes a good case that it does.

Thanks, I agree. :-)

>> - Whether the keyword-free syntax idea proposed here is best:
>>   NAME: TYPE
>>   TARGET: TYPE = VALUE
>
> I think so.
>
> That looks like similar to the syntax used by TypeScript:
>
> http://www.typescriptlang.org/docs/handbook/type-inference.html
>
> let zoo: Animal[] = [new Rhino(), new Elephant(), new Snake()];

And Rust.

In the tracker issue we're still tweaking this, e.g. the latest idea
is that after all we'd like to simplify the syntax to

TARGET: TYPE [= VALUE]

Please read the end of the tracker discussion:
https://github.com/python/typing/issues/258#issuecomment-244188268

> Some additional thoughts:
>
> Is it okay to declare something as both an instance and class attribute?
>
> class X:
> spam: int
> spam: ClassVar[Str] = 'suprise!'
>
> def __init__(self):
> self.spam = 999
>
>
> I would expect it should be okay.

I think it would be confusing because the class var would be used as
the default if the instance var is not defined.

> It is more common in Python circles to talk about class and instance
> *attributes* than "variables". Class variable might be okay in a
> language like Java where classes themselves aren't first-class values,
> but in Python "class variable" always makes me think it is talking about
> a variable which is a class, just like a string variable or list
> variable. Can we have ClassAttr[] instead of ClassVar[]?

We went back and forth on this. I really don't like to use the word
attribute here, because a method is also an attribute. And instance
variable sounds more natural to me than instance attribute.

Also we now have global variables, class variables, instance
variables, and local variables, all of which can be annotated.

(The PEP's language is actually a bit inconsistent here.)

> Other than that, +1 on the PEP.

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Steven D'Aprano 
On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:

> - Whether (given PEP 484's relative success) it's worth adding syntax
> for variable/attribute annotations.

The PEP makes a good case that it does.


> - Whether the keyword-free syntax idea proposed here is best:
>   NAME: TYPE
>   TARGET: TYPE = VALUE

I think so.

That looks like similar to the syntax used by TypeScript:

http://www.typescriptlang.org/docs/handbook/type-inference.html

let zoo: Animal[] = [new Rhino(), new Elephant(), new Snake()];


Some additional thoughts:

Is it okay to declare something as both an instance and class attribute?

class X:
spam: int
spam: ClassVar[Str] = 'suprise!'

def __init__(self):
self.spam = 999


I would expect it should be okay.



It is more common in Python circles to talk about class and instance 
*attributes* than "variables". Class variable might be okay in a 
language like Java where classes themselves aren't first-class values, 
but in Python "class variable" always makes me think it is talking about 
a variable which is a class, just like a string variable or list 
variable. Can we have ClassAttr[] instead of ClassVar[]?


Other than that, +1 on the PEP.



-- 
Steve
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Koos Zevenhoven 
On Thu, Sep 1, 2016 at 5:46 PM, Guido van Rossum  wrote:
> On Thu, Sep 1, 2016 at 6:11 AM, Koos Zevenhoven  wrote:
>> While a large amount of Python programmers may not be interested in
>> type hinting local variables inside functions, I can see other
>> potential benefits in this.
>
> IOW, PEP 3157 is not dead yet. Indeed.
>

PEP 3157? Is that a typo or is there such a thing somewhere?

[...]
>> Also, when reading code, it may be hard to tell which (instance)
>> attributes the class implements. To have these listed in the beginning
>> of the class could therefore improve the readability.
>
> Right. That has been my observation using PEP 484's type comments
> extensively for annotating instance variables at the class level. E.g.
> much of mypy's own code is written this way, and it really is a huge
> help. But
>
> foo = None  # type: List[int]
>
> while it gives me the info I'm looking for, is not great
> notation-wise, and that's why I started thinking about an alternative:
>
> foo: List[int]
>
> (in either case, the __init__ contains something like `self.foo = []`).
>
>> In this light, I'm not sure it's a good idea to allow attribute type
>> hints inside methods.
>
> Those are meant for the coding style where all attributes are
> initialized in the method and people just want to add annotations
> there. This is already in heavy use in some PEP-484-annotated code
> bases I know of, using # type comments, and I think it will be easier
> to get people to switch to syntactic annotations if they can
> mechanically translate those uses. (In fact we are planning an
> automatic translator.)

I suppose the translator would be somewhat more complicated if it were
to move the type hints to the beginning of the class suite. Anyway, I
hope there will at least be a recommendation somewhere (PEP 8?) to not
mix the two styles of attribute annotation (beginning of class / in
method). The whole readability benefit turns against itself if there
are some non-ClassVar variables annotated outside __init__ and then
the rest somewhere in __init__ and in whatever initialization helper
methods __init__ happens to call.

[...]
>> Note that we could then also have this:
>>
>> def NAME
>>
>> Which would, again for readability (see above), be a way to express
>> that "there is an instance variable called X, but no type hint for
>> now". I can't think of a *good* way to do this with the keyword-free
>> version for people that don't use type hints.
>>
>> And then there could also be a simple decorator like
>> @slotted_attributes that automatically generates "__slots__" from the
>> annotations.
>
> This I like, or something like it. It can be a follow-up design. (I.e.
> a separate PEP, once we have experiece with PEP 526.)

I think there should be a syntax for this that does not involve type
hints, but I can't seem to come up with anything that works with the
keyword-free version :(.

-- Koos


> --
> --Guido van Rossum (python.org/~guido)

-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Ivan Levkivskyi 
On 1 September 2016 at 18:21, Steven D'Aprano  wrote:

> The simplest way would be to say "go on, one type hint won't hurt,
> there's no meaningful runtime cost, just do it".
>
> from typing import Any
>
> class X:
> NAME: Any
>
> Since I'm not running a type checker, it doesn't matter what hint I use,
> but Any is probably the least inaccurate.
>
> But I think there's a better way.
>
> Unless I've missed something, there's no way to pre-declare an instance
> attribute without specifying a type. (Even if that type is Any.) So how
> about we allow None as a type-hint on its own:
>
> NAME: None
>
> as equivalent to a declaration *without* a hint. The reader, and the
> type-checker, can see that there's an instance attribute called NAME,
> but in the absense of an actual hint, the type will have to be inferred,
> just as if it wasn't declared at all.
>

There is a convention for function annotations in PEP 484 that a missing
annotation
is equivalent to Any, so that I like your first option more.

--
Ivan
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Steven D'Aprano 
On Thu, Sep 01, 2016 at 04:11:05PM +0300, Koos Zevenhoven wrote:

> Maybe it's just me, but I've always thought 'def' is Python's least
> logically used keyword. It seems to come from 'define', but what is it
> about 'define' that makes it relate to functions only.

Convention.

You can't use "def" to define both functions and classes:

def function(x): ...
def Class(x): ...

is ambiguous, which is the function and which is the class? So we cannot 
avoid at least one limitation: "def is for functions, or classes, but 
not both". Given that, it isn't that weird to make the rule "def is only 
for functions".



[...]
> Note that we could then also have this:
> 
> def NAME
> 
> Which would, again for readability (see above), be a way to express
> that "there is an instance variable called X, but no type hint for
> now". I can't think of a *good* way to do this with the keyword-free
> version for people that don't use type hints.

The simplest way would be to say "go on, one type hint won't hurt, 
there's no meaningful runtime cost, just do it".

from typing import Any

class X:
NAME: Any

Since I'm not running a type checker, it doesn't matter what hint I use, 
but Any is probably the least inaccurate.

But I think there's a better way.

Unless I've missed something, there's no way to pre-declare an instance 
attribute without specifying a type. (Even if that type is Any.) So how 
about we allow None as a type-hint on its own:

NAME: None

as equivalent to a declaration *without* a hint. The reader, and the 
type-checker, can see that there's an instance attribute called NAME, 
but in the absense of an actual hint, the type will have to be inferred, 
just as if it wasn't declared at all.

The risk is that somebody will "helpfully" correct the "obvious typo" 
and change it to NAME = None, but I think that will usually be harmless. 
I can invent examples where they will behave differently, but they feel 
contrived to me:

class X:
spam: None  # declaration only, without a hint

def method(self):
if not hasattr(self, "spam"):
raise XError("spam not set")
return self.spam

def setup(self, arg):
if hasattr(self, "spam"):
raise XError("spam already set")
self.spam = arg


Changing the declaration to an assignment does change the behaviour of 
the class, but I think that will be obvious when it happens.


-- 
Steve
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Guido van Rossum 
On Thu, Sep 1, 2016 at 6:11 AM, Koos Zevenhoven  wrote:
> While a large amount of Python programmers may not be interested in
> type hinting local variables inside functions, I can see other
> potential benefits in this.

IOW, PEP 3157 is not dead yet. Indeed.

> When I start sketching a new class, I'm often tempted to write down
> the names of the attributes first, before starting to implement
> ``__init__``. Sometimes I even write temporary comments for this
> purpose. This syntax would naturally provide a way to sketch the list
> of attributes. Yes, there is already __slots__, but I'm not sure that
> is a good example of readability.

Agreed, it can't get much cleaner than NAME: TYPE.

> Also, when reading code, it may be hard to tell which (instance)
> attributes the class implements. To have these listed in the beginning
> of the class could therefore improve the readability.

Right. That has been my observation using PEP 484's type comments
extensively for annotating instance variables at the class level. E.g.
much of mypy's own code is written this way, and it really is a huge
help. But

foo = None  # type: List[int]

while it gives me the info I'm looking for, is not great
notation-wise, and that's why I started thinking about an alternative:

foo: List[int]

(in either case, the __init__ contains something like `self.foo = []`).

> In this light, I'm not sure it's a good idea to allow attribute type
> hints inside methods.

Those are meant for the coding style where all attributes are
initialized in the method and people just want to add annotations
there. This is already in heavy use in some PEP-484-annotated code
bases I know of, using # type comments, and I think it will be easier
to get people to switch to syntactic annotations if they can
mechanically translate those uses. (In fact we are planning an
automatic translator.)

>> - Whether the keyword-free syntax idea proposed here is best:
>>   NAME: TYPE
>>   TARGET: TYPE = VALUE
>
> I wonder if this would be better:
>
> def NAME: TYPE
> def NAME: TYPE = VALUE
>
> Maybe it's just me, but I've always thought 'def' is Python's least
> logically used keyword. It seems to come from 'define', but what is it
> about 'define' that makes it relate to functions only. Adding an
> optional 'def' for other variables might even be a tiny bit of added
> consistency.

Here I strongly disagree. Everyone will be confused.

> Note that we could then also have this:
>
> def NAME
>
> Which would, again for readability (see above), be a way to express
> that "there is an instance variable called X, but no type hint for
> now". I can't think of a *good* way to do this with the keyword-free
> version for people that don't use type hints.
>
> And then there could also be a simple decorator like
> @slotted_attributes that automatically generates "__slots__" from the
> annotations.

This I like, or something like it. It can be a follow-up design. (I.e.
a separate PEP, once we have experiece with PEP 526.)

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-09-01 Thread Koos Zevenhoven 
On Wed, Aug 31, 2016 at 12:20 AM, Guido van Rossum  wrote:
> I'm happy to present PEP 526 for your collective review:
> https://www.python.org/dev/peps/pep-0526/ (HTML)
> https://github.com/python/peps/blob/master/pep-0526.txt (source)
>
> There's also an implementation ready:
> https://github.com/ilevkivskyi/cpython/tree/pep-526
>
> I don't want to post the full text here but I encourage feedback on
> the high-order ideas, including but not limited to
>
> - Whether (given PEP 484's relative success) it's worth adding syntax
> for variable/attribute annotations.

While a large amount of Python programmers may not be interested in
type hinting local variables inside functions, I can see other
potential benefits in this.

When I start sketching a new class, I'm often tempted to write down
the names of the attributes first, before starting to implement
``__init__``. Sometimes I even write temporary comments for this
purpose. This syntax would naturally provide a way to sketch the list
of attributes. Yes, there is already __slots__, but I'm not sure that
is a good example of readability.

Also, when reading code, it may be hard to tell which (instance)
attributes the class implements. To have these listed in the beginning
of the class could therefore improve the readability.

In this light, I'm not sure it's a good idea to allow attribute type
hints inside methods.

>
> - Whether the keyword-free syntax idea proposed here is best:
>   NAME: TYPE
>   TARGET: TYPE = VALUE
>

I wonder if this would be better:

def NAME: TYPE
def NAME: TYPE = VALUE

Maybe it's just me, but I've always thought 'def' is Python's least
logically used keyword. It seems to come from 'define', but what is it
about 'define' that makes it relate to functions only. Adding an
optional 'def' for other variables might even be a tiny bit of added
consistency.

Note that we could then also have this:

def NAME

Which would, again for readability (see above), be a way to express
that "there is an instance variable called X, but no type hint for
now". I can't think of a *good* way to do this with the keyword-free
version for people that don't use type hints.

And then there could also be a simple decorator like
@slotted_attributes that automatically generates "__slots__" from the
annotations.

-- Koos


> Note that there's an extensive list of rejected ideas in the PEP;
> please be so kind to read it before posting here:
> https://www.python.org/dev/peps/pep-0526/#rejected-proposals-and-things-left-out-for-now
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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/k7hoven%40gmail.com


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-31 Thread Ivan Levkivskyi 
On 31 August 2016 at 13:09, Nick Coghlan  wrote:

> I guess as long as they're included somewhere in the AST for the
> function body, I don't mind if the translation to bytecode throws them
> away - that's essentially saying that a function level type annotation
> is effectively interpreted as if it was:
>
> if False:
> __annotations__[] = 
>
> So the code generator will pick up syntax errors during normal
> execution, but not runtime errors (since the expression never actually
> gets evaluated).
>

Nick, you are right, in current implementation they are included in AST
in exactly the same way as in classes and modules, but compiler throws them
away.

--
Ivan
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-31 Thread Steven D'Aprano 
On Tue, Aug 30, 2016 at 07:15:55PM -0700, Guido van Rossum wrote:
> On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano  wrote:
> > On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> >> I'm happy to present PEP 526 for your collective review:
> >
> > Are you hoping to get this in before 3.6 beta? Because I'm not sure I
> > can give this much attention before then, but I really want to.
> 
> Yes I am hoping for that. Unlike PEP 484, this PEP is forward-looking
> (more like PEP 492, async/await), and the sooner we can get it in the
> sooner people who want to use it won't have to worry about supporting
> older Python versions. (And am I ever looking forward to the day when
> Python 3.5 counts as "older". :-)

Indeed :-)

Okay, I'll bump it up my list of priorities. (Sleep? Who needs that? :-) 


-- 
Steve
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-31 Thread Nick Coghlan 
On 31 August 2016 at 15:40, Guido van Rossum  wrote:
> On Tuesday, August 30, 2016, Nick Coghlan  wrote:
>> What if we included local variable annotations in func.__annotations__
>> as cells, like the entries in func.__closure__?
>>
>> We could also use that as a micro-optimisation technique: once the
>> type annotation cell is populated, CPython would just use it, rather
>> than re-evaluating the local variable type annotation expression every
>> time the function is called.
>
> But what runtime use have the annotations on locals? They are not part of
> any inspectable interface. I don't want to spend any effort on them at
> runtime. (Just the bit that they are treated as locals.)

I guess as long as they're included somewhere in the AST for the
function body, I don't mind if the translation to bytecode throws them
away - that's essentially saying that a function level type annotation
is effectively interpreted as if it was:

if False:
__annotations__[] = 

So the code generator will pick up syntax errors during normal
execution, but not runtime errors (since the expression never actually
gets evaluated).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Guido van Rossum 
On Tuesday, August 30, 2016, Nick Coghlan  wrote:

> On 31 August 2016 at 13:37, Jack Diederich  > wrote:
> > On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum  > wrote:
> >> But myfunc.__annotations__ already exists -- PEP 3107 puts the
> >> signature annotations there. The problem with co_annotations is that
> >> annotations are evaluated (they can be quite complex expressions, e.g.
> >> Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames is
> >> just a list of strings. And code objects must be immutable. The issue
> >> with rejecting duplicate annotations so sternly is the same as for the
> >> previous bullet.
> >>
> >
> > If we disallow re-assignment of types as a syntax error then the conflict
> > with myfunc.__annotations__ goes away for vars that share a name with the
> > function arguments. The fact that variables with types can't be known
> until
> > the function body executes a particular line is .. I'm not sure how to
> deal
> > with that. For modules and classes you can assert that the body at the
> top
> > indent level has been executed. For functions you can only assert that it
> > has been parsed. So myfunc.__annotations__ could say that the type has a
> > definition but only later know what the definition is.
>
> What if we included local variable annotations in func.__annotations__
> as cells, like the entries in func.__closure__?
>
> We could also use that as a micro-optimisation technique: once the
> type annotation cell is populated, CPython would just use it, rather
> than re-evaluating the local variable type annotation expression every
> time the function is called.
>

But what runtime use have the annotations on locals? They are not part of
any inspectable interface. I don't want to spend any effort on them at
runtime. (Just the bit that they are treated as locals.)

--Guido


-- 
--Guido (mobile)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Nick Coghlan 
On 31 August 2016 at 13:37, Jack Diederich  wrote:
> On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum  wrote:
>> But myfunc.__annotations__ already exists -- PEP 3107 puts the
>> signature annotations there. The problem with co_annotations is that
>> annotations are evaluated (they can be quite complex expressions, e.g.
>> Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames is
>> just a list of strings. And code objects must be immutable. The issue
>> with rejecting duplicate annotations so sternly is the same as for the
>> previous bullet.
>>
>
> If we disallow re-assignment of types as a syntax error then the conflict
> with myfunc.__annotations__ goes away for vars that share a name with the
> function arguments. The fact that variables with types can't be known until
> the function body executes a particular line is .. I'm not sure how to deal
> with that. For modules and classes you can assert that the body at the top
> indent level has been executed. For functions you can only assert that it
> has been parsed. So myfunc.__annotations__ could say that the type has a
> definition but only later know what the definition is.

What if we included local variable annotations in func.__annotations__
as cells, like the entries in func.__closure__?

We could also use that as a micro-optimisation technique: once the
type annotation cell is populated, CPython would just use it, rather
than re-evaluating the local variable type annotation expression every
time the function is called.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Jack Diederich 
On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum  wrote:

> On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich 
> wrote:
> > +0. We should try and be consistent even if this is a thing I don't want.
> > And trust me, I don't!
>
> No problem. You won't have to!
>
>
Yes! I don't have to want it, it is here!


> > That said, as long as pro-mypy people are willing to make everyone else
> pay
> > a mypy reading tax for code let's try and reduce the cognitive burden.
> >
> > * Duplicate type annotations should be a syntax error.
> >   Duplicate annotations aren't possible in functions so that wasn't an
> issue
> > in 484. 526 makes some things syntax errors and some things runtime
> errors
> > (for good reason -- function bodies aren't evaluated right away).
> > Double-annotating a variable is something we can figure out at compile
> time
> > and doing the double annotating is non-sensical so we should error on it
> > because we can.
>
> Actually I'm not so sure that double-annotating is always nonsensical.
> In the mypy tracker we're seeing some requests for type *inference*
> that allows a variable to be given another type later, e.g.
>
> x = 'abc'
> test_func(x)
> x = 42
> another_test_func(x)
>
> Maybe there's a use for explicit annotations too. I would rather not
> get in the way of letting type checkers decide such semantics.
>
>
Other languages (including rpython) don't allow rebinding types (or
sometimes even re-assignment to same type). We are going for clarity [and
bondage, and discipline]. If we are doing types let's do types like other
people do. I think *disallowing* redefining the type is general to
enforcing types. +1 on being consistent with other langs. If plain
redoubling of types is allowed I'm OK "i: int = 0" doesn't summon horrors
when said three times into a mirror. But we can't always know what "int"
evaluates to so I'd just disallow it.


> > *  Dissallowing annotations on global and nonlocal
> >   Agreed, allowing it would be confusing because it would either be a
> > re-definition or a hard to read annotation-at-a-distance.
> >
> > * Where __annotations__ live
> >   It is strange to allow modules.__annotations__ and
> MyClass.__annotations__
> > but not myfunc.__annotations__ (or more in line with existing function
> > implementations a myfunc.__code__.co_annotations). If we know enough
> from
> > the syntax parse to have func.__code__.co_varnames be known then we
> should
> > try to do that with annotations.  Let's raise a SyntaxError for function
> > body annotations that conflict with same-named variables that are
> annotated
> > in the function signature as well.
>
> But myfunc.__annotations__ already exists -- PEP 3107 puts the
> signature annotations there. The problem with co_annotations is that
> annotations are evaluated (they can be quite complex expressions, e.g.
> Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames is
> just a list of strings. And code objects must be immutable. The issue
> with rejecting duplicate annotations so sternly is the same as for the
> previous bullet.
>
>
If we disallow re-assignment of types as a syntax error then the conflict
with myfunc.__annotations__ goes away for vars that share a name with the
function arguments. The fact that variables with types can't be known until
the function body executes a particular line is .. I'm not sure how to deal
with that. For modules and classes you can assert that the body at the top
indent level has been executed. For functions you can only assert that it
has been parsed. So myfunc.__annotations__ could say that the type has a
definition but only later know what the definition is.

> I did C++ for years before I did Python and wrote C++ in many languages
> > (including Python). So ideally I'm -1000 on all this stuff for cultural
> > reasons -- if you let a C++ person add types they will for false comfort.
> > But again, I'm +0 on this specific proposal because we have already gone
> > down the garden path.
>
> As long as you run mypy the comfort shouldn't be false. (But your
> starting with C++ before Python explains a lot. :-)
>

We've talked about this and we have different relationships with tools. I'm
a monk who thinks using a debugger is an admission of failure; you think
linters are a fine method of dissuading others of sin.
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Guido van Rossum 
On Tue, Aug 30, 2016 at 7:44 PM, Jack Diederich  wrote:
> +0. We should try and be consistent even if this is a thing I don't want.
> And trust me, I don't!

No problem. You won't have to!

> That said, as long as pro-mypy people are willing to make everyone else pay
> a mypy reading tax for code let's try and reduce the cognitive burden.
>
> * Duplicate type annotations should be a syntax error.
>   Duplicate annotations aren't possible in functions so that wasn't an issue
> in 484. 526 makes some things syntax errors and some things runtime errors
> (for good reason -- function bodies aren't evaluated right away).
> Double-annotating a variable is something we can figure out at compile time
> and doing the double annotating is non-sensical so we should error on it
> because we can.

Actually I'm not so sure that double-annotating is always nonsensical.
In the mypy tracker we're seeing some requests for type *inference*
that allows a variable to be given another type later, e.g.

x = 'abc'
test_func(x)
x = 42
another_test_func(x)

Maybe there's a use for explicit annotations too. I would rather not
get in the way of letting type checkers decide such semantics.

> *  Dissallowing annotations on global and nonlocal
>   Agreed, allowing it would be confusing because it would either be a
> re-definition or a hard to read annotation-at-a-distance.
>
> * Where __annotations__ live
>   It is strange to allow modules.__annotations__ and MyClass.__annotations__
> but not myfunc.__annotations__ (or more in line with existing function
> implementations a myfunc.__code__.co_annotations). If we know enough from
> the syntax parse to have func.__code__.co_varnames be known then we should
> try to do that with annotations.  Let's raise a SyntaxError for function
> body annotations that conflict with same-named variables that are annotated
> in the function signature as well.

But myfunc.__annotations__ already exists -- PEP 3107 puts the
signature annotations there. The problem with co_annotations is that
annotations are evaluated (they can be quite complex expressions, e.g.
Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames is
just a list of strings. And code objects must be immutable. The issue
with rejecting duplicate annotations so sternly is the same as for the
previous bullet.

> I did C++ for years before I did Python and wrote C++ in many languages
> (including Python). So ideally I'm -1000 on all this stuff for cultural
> reasons -- if you let a C++ person add types they will for false comfort.
> But again, I'm +0 on this specific proposal because we have already gone
> down the garden path.

As long as you run mypy the comfort shouldn't be false. (But your
starting with C++ before Python explains a lot. :-)

> -Jack

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Jack Diederich 
+0. We should try and be consistent even if this is a thing I don't
want. And trust me, I don't!

That said, as long as pro-mypy people are willing to make everyone else pay
a mypy reading tax for code let's try and reduce the cognitive burden.

* Duplicate type annotations should be a syntax error.
  Duplicate annotations aren't possible in functions so that wasn't an
issue in 484. 526 makes some things syntax errors and some things runtime
errors (for good reason -- function bodies aren't evaluated right away).
Double-annotating a variable is something we can figure out at compile time
and doing the double annotating is non-sensical so we should error on it
because we can.

*  Dissallowing annotations on global and nonlocal
  Agreed, allowing it would be confusing because it would either be a
re-definition or a hard to read annotation-at-a-distance.

* Where __annotations__ live
  It is strange to allow modules.__annotations__ and
MyClass.__annotations__ but not myfunc.__annotations__ (or more in line
with existing function implementations a myfunc.__code__.co_annotations).
If we know enough from the syntax parse to have func.__code__.co_varnames
be known then we should try to do that with annotations.  Let's raise a
SyntaxError for function body annotations that conflict with same-named
variables that are annotated in the function signature as well.

I did C++ for years before I did Python and wrote C++ in many languages
(including Python). So ideally I'm -1000 on all this stuff for cultural
reasons -- if you let a C++ person add types they will for false comfort.
But again, I'm +0 on this specific proposal because we have already gone
down the garden path.

-Jack


On Tue, Aug 30, 2016 at 9:00 PM, Steven D'Aprano 
wrote:

> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> > I'm happy to present PEP 526 for your collective review:
>
> Are you hoping to get this in before 3.6 beta? Because I'm not sure I
> can give this much attention before then, but I really want to.
>
>
> --
> Steve
> ___
> 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/
> jackdied%40gmail.com
>
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Guido van Rossum 
On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano  wrote:
> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
>> I'm happy to present PEP 526 for your collective review:
>
> Are you hoping to get this in before 3.6 beta? Because I'm not sure I
> can give this much attention before then, but I really want to.

Yes I am hoping for that. Unlike PEP 484, this PEP is forward-looking
(more like PEP 492, async/await), and the sooner we can get it in the
sooner people who want to use it won't have to worry about supporting
older Python versions. (And am I ever looking forward to the day when
Python 3.5 counts as "older". :-)

While some of the details are better, this is substantially the same
proposal that we discussed at length in python-ideas, starting at
https://mail.python.org/pipermail/python-ideas/2016-August/041294.html
(and you participated vigorously in that thread, so very little in the
PEP should be news to you).

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Steven D'Aprano 
On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
> I'm happy to present PEP 526 for your collective review:

Are you hoping to get this in before 3.6 beta? Because I'm not sure I 
can give this much attention before then, but I really want to.


-- 
Steve
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Brett Cannon 
On Tue, 30 Aug 2016 at 14:21 Guido van Rossum  wrote:

> I'm happy to present PEP 526 for your collective review:
> https://www.python.org/dev/peps/pep-0526/ (HTML)
> https://github.com/python/peps/blob/master/pep-0526.txt (source)
>
> There's also an implementation ready:
> https://github.com/ilevkivskyi/cpython/tree/pep-526
>
> I don't want to post the full text here but I encourage feedback on
> the high-order ideas, including but not limited to
>
> - Whether (given PEP 484's relative success) it's worth adding syntax
> for variable/attribute annotations.
>

I think so, otherwise type hints are in this weird "half in, half out"
situation in terms of support that only non-OO code can fully utilize.
Either we're going to have type hints for those that want it and properly
support it for full use, or we shouldn't have type hints at all and this
syntax fills in a nice gaps that was a bit awkward to use before.


>
> - Whether the keyword-free syntax idea proposed here is best:
>   NAME: TYPE
>   TARGET: TYPE = VALUE
>

I personally like it. I've been learning Rust lately and it matches up with
their syntax (sans `let`) and I have been happy with it (same goes for
TypeScript's use of the same syntax that Rust uses).

-Brett


>
> Note that there's an extensive list of rejected ideas in the PEP;
> please be so kind to read it before posting here:
>
> https://www.python.org/dev/peps/pep-0526/#rejected-proposals-and-things-left-out-for-now
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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/brett%40python.org
>
___
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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Sven R. Kunze 

Thanks Guido, also to the rest of the PEP team (4 people) :)


On 30.08.2016 23:20, Guido van Rossum wrote:

I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)

There's also an implementation ready:
https://github.com/ilevkivskyi/cpython/tree/pep-526

I don't want to post the full text here but I encourage feedback on
the high-order ideas, including but not limited to

- Whether (given PEP 484's relative success) it's worth adding syntax
for variable/attribute annotations.


I'd say no, especially because of the negative feedback by not a few 
thread participants.



- Whether the keyword-free syntax idea proposed here is best:
   NAME: TYPE
   TARGET: TYPE = VALUE


If it will come, it's the best because of its similarity with parameter 
annotations and IIRC there are languages that already do it like this.



Note that there's an extensive list of rejected ideas in the PEP;
please be so kind to read it before posting here:
https://www.python.org/dev/peps/pep-0526/#rejected-proposals-and-things-left-out-for-now


I find everything else well covered in the PEP especially corner-cases 
like variables without initialization, scopes etc.



Sven
___
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] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

2016-08-30 Thread Guido van Rossum 
I'm happy to present PEP 526 for your collective review:
https://www.python.org/dev/peps/pep-0526/ (HTML)
https://github.com/python/peps/blob/master/pep-0526.txt (source)

There's also an implementation ready:
https://github.com/ilevkivskyi/cpython/tree/pep-526

I don't want to post the full text here but I encourage feedback on
the high-order ideas, including but not limited to

- Whether (given PEP 484's relative success) it's worth adding syntax
for variable/attribute annotations.

- Whether the keyword-free syntax idea proposed here is best:
  NAME: TYPE
  TARGET: TYPE = VALUE

Note that there's an extensive list of rejected ideas in the PEP;
please be so kind to read it before posting here:
https://www.python.org/dev/peps/pep-0526/#rejected-proposals-and-things-left-out-for-now


-- 
--Guido van Rossum (python.org/~guido)
___
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