Re: [Python-Dev] PEP 484

[Brett Cannon]

On Wed, 4 Jul 2018 at 22:07 Greg Ewing  wrote:

> Shawn Chen wrote:
> > The PEP 484 is proposing a type hint which can annotate the type of each
> > parameters. How ever code written in this format can not be run for
> > python3.5 and below.
>
> You're a bit late. Parameter annotations have been a part
> of the language since at least 3.1. PEP 484 just codifies
> a way of using them to represent types.
>
> Also, PEP 484 does specify a way of using comments to
> indicate types.
>

Actually it does in
https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code
and https://www.python.org/dev/peps/pep-0484/#type-comments. So the OP's
desire to specify in a comment is already specified.
___
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 484

[Greg Ewing]

Shawn Chen wrote:
The PEP 484 is proposing a type hint which can annotate the type of each 
parameters. How ever code written in this format can not be run for 
python3.5 and below.


You're a bit late. Parameter annotations have been a part
of the language since at least 3.1. PEP 484 just codifies
a way of using them to represent types.

Also, PEP 484 does specify a way of using comments to
indicate types.

--
Greg
___
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 484

[Ryan Gonzalez]

Type hints like in PEP 484 work on all Python 3 versions, and something 
similar to your proposal is already supported on Python 2 [1].


[1]: https://mypy.readthedocs.io/en/latest/python2.html


On July 4, 2018 11:08:27 PM Shawn Chen  wrote:


Hello,

Here, I am proposing a change on python type annotation.

Python was born to be a simple and elegant language. However recent change 
has again introduce new incompatibility to python.


The PEP 484 is proposing a type hint which can annotate the type of each 
parameters. How ever code written in this format can not be run for 
python3.5 and below.


It is an exciting new feature to be able to know the data type from the 
code, But I am afraid this is not worth such a incompatibility.


Here I want to propose a new way of annotation in python as follows

def reportAge(name, age):
''' this a a greeting function and some other comment...
!str, int -> str
'''
return name+' is ' + age


we can put the annotation in the comment block and use a symbol '!' or 
other symbol suitable to lead a annotation line.

the annotation should be positionally corresponding to the parameters.

Shawn

Sent from Mail for Windows 10




--
___
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/rymg19%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 484: difference between tuple and ()

[Jelle Zijlstra]

2017-11-08 14:01 GMT-08:00 Jean-Patrick Francoia <
jeanpatrick.franc...@gmail.com>:

> This is my first post on this list, so please don't kill me if I ask it in
> the wrong place, or if the question is stupid.
>
>
> I asked this question on Stack Overflow already:
>
> https://stackoverflow.com/questions/47163048/python-
> annotations-difference-between-tuple-and
>
>
> In very short, which form is correct ?
>
>
> def func() -> Tuple[int, int]
>
>
>
> But this requires to import the typing module.
>
>
> Or this (doesn't crash):
>
>
> def func() -> (int, int):
>
>
> The former is correct. Type checkers should reject the second one. But
because type checking in Python is through static analysis, either will
work at runtime—you need to run a separate static analysis tool like mypy
or pytype to find type errors in your code.

Also, python-dev is a mailing list for the development of Python, not for
questions about Python. The Gitter chatroom at
https://gitter.im/python/typing and the typing issue tracker at
https://github.com/python/typing are better places for questions about
typing in Python.

> ___
> 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/
> jelle.zijlstra%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 484 update proposal: annotating decorated declarations

[Guido van Rossum]

On Fri, Jun 2, 2017 at 1:07 PM, Koos Zevenhoven  wrote:

> [...]
> I suppose it is, especially because there seems to be nothing that
> prevents you from getting runtime annotations in the enclosing class/module
> ​:
>
>
> number: int
>
> @call
> def number():
> return 42
>

Well mypy actually gives an error for that, "Name 'number' already defined".


>
> But for functions one could have (
> ​using
>  the context manager example):
>
>
> def session(url: str) -> ContextManager[DatabaseSession]: ...
>
> @predeclared
> @contextmanager
> def session(url: str) -> Iterator[DatabaseSession]:
> s = DatabaseSession(url)
> try:
> yield s
> finally:
> s.close()
>
>
> This makes it clear that the function is declared elsewhere. But the
> `predeclared` decorator would need tricks like sys._getframe(1) to set
> session.__annotations__ according to the predeclaration.
>

I'm not excited about that.

-- 
--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 484 update proposal: annotating decorated declarations

[Koos Zevenhoven]

On Fri, Jun 2, 2017 at 8:57 PM, Guido van Rossum  wrote:
> On Fri, Jun 2, 2017 at 9:41 AM, Koos Zevenhoven  wrote:
>>
>> I still don't understand what would happen with __annotations__. If
>> the decorator returns a non-function, one would expect the annotations
>> to be in the __annotations__ attribute of the enclosing class or
>> module. If it returns a function, they would be in the __annotations__
>> attribute of the function. And I'm talking about the runtime behavior
>> in Python as explained in PEP484 and PEP526. I would expect these
>> declarations to behave according to the same principles as other ways
>> to annotate variables/functions. If there is no runtime behavior, a
>> comment-based syntax might be more appropriate. Or have I missed
>> something?
>
>
> So when returning a function, the runtime version of the decorator can
> easily update the function's __annotations__. But when returning a
> non-function, the decorator would have a hard time updating
__annotations__
> of the containing class/module without "cheating" (e.g. sys._getframe()).
I
> think the latter is similar to e.g. attributes defined with @property --
> those don't end up in __annotations__ either. I think this is an
acceptable
> deficiency.
>

I suppose it is, especially because there seems to be nothing that prevents
you from getting runtime annotations in the enclosing class/module
​:


number: int

@call
def number():
return 42


But for functions one could have (
​using
 the context manager example):


def session(url: str) -> ContextManager[DatabaseSession]: ...

@predeclared
@contextmanager
def session(url: str) -> Iterator[DatabaseSession]:
s = DatabaseSession(url)
try:
yield s
finally:
s.close()


This makes it clear that the function is declared elsewhere. But the
`predeclared` decorator would need tricks like sys._getframe(1) to set
session.__annotations__ according to the predeclaration.

-- Koos


-- 
+ 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 484 update proposal: annotating decorated declarations

[Guido van Rossum]

On Fri, Jun 2, 2017 at 9:41 AM, Koos Zevenhoven  wrote:

> On Fri, Jun 2, 2017 at 6:34 PM, Naomi Seyfer  wrote:
> > Yep, interested in implementing it!  I will put implementation time on my
> > schedule and tell y'all when it is, for holding myself accountable -- it
> > turns out I never do anything not on my schedule.
>
> I still don't understand what would happen with __annotations__. If
> the decorator returns a non-function, one would expect the annotations
> to be in the __annotations__ attribute of the enclosing class or
> module. If it returns a function, they would be in the __annotations__
> attribute of the function. And I'm talking about the runtime behavior
> in Python as explained in PEP484 and PEP526. I would expect these
> declarations to behave according to the same principles as other ways
> to annotate variables/functions. If there is no runtime behavior, a
> comment-based syntax might be more appropriate. Or have I missed
> something?
>

So when returning a function, the runtime version of the decorator can
easily update the function's __annotations__. But when returning a
non-function, the decorator would have a hard time updating __annotations__
of the containing class/module without "cheating" (e.g. sys._getframe()). I
think the latter is similar to e.g. attributes defined with @property --
those don't end up in __annotations__ either. I think this is an acceptable
deficiency.

-- 
--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 484 update proposal: annotating decorated declarations

[Koos Zevenhoven]

On Fri, Jun 2, 2017 at 6:34 PM, Naomi Seyfer  wrote:
> Yep, interested in implementing it!  I will put implementation time on my
> schedule and tell y'all when it is, for holding myself accountable -- it
> turns out I never do anything not on my schedule.
>

I still don't understand what would happen with __annotations__. If
the decorator returns a non-function, one would expect the annotations
to be in the __annotations__ attribute of the enclosing class or
module. If it returns a function, they would be in the __annotations__
attribute of the function. And I'm talking about the runtime behavior
in Python as explained in PEP484 and PEP526. I would expect these
declarations to behave according to the same principles as other ways
to annotate variables/functions. If there is no runtime behavior, a
comment-based syntax might be more appropriate. Or have I missed
something?


—Koos



-- 
+ 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 484 update proposal: annotating decorated declarations

[Naomi Seyfer]

Yep, interested in implementing it!  I will put implementation time on my
schedule and tell y'all when it is, for holding myself accountable -- it
turns out I never do anything not on my schedule.

On Wed, May 31, 2017 at 3:17 PM, Guido van Rossum  wrote:

> On Wed, May 31, 2017 at 6:16 AM, Ivan Levkivskyi 
> wrote:
>
>> On 30 May 2017 at 23:02, Guido van Rossum  wrote:
>>
>>> All in all I'm still leaning towards Naomi's original proposal -- it
>>> looks simpler to implement as well.
>>>
>>
>> OK, I think having a bit of verbosity is absolutely fine if we win
>> simplicity of implementation (for both static and runtime purposes).
>>
>
> Then I propose to do it this way. We can always add Jukka's way as an
> alternative notation later. I'd like to hear from Jukka before I merge the
> PR for PEP-484.
>
> In the meantime, Naomi, are you interested in trying to implement this?
>
> --
> --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 484 update proposal: annotating decorated declarations

[Guido van Rossum]

On Wed, May 31, 2017 at 6:16 AM, Ivan Levkivskyi 
wrote:

> On 30 May 2017 at 23:02, Guido van Rossum  wrote:
>
>> All in all I'm still leaning towards Naomi's original proposal -- it
>> looks simpler to implement as well.
>>
>
> OK, I think having a bit of verbosity is absolutely fine if we win
> simplicity of implementation (for both static and runtime purposes).
>

Then I propose to do it this way. We can always add Jukka's way as an
alternative notation later. I'd like to hear from Jukka before I merge the
PR for PEP-484.

In the meantime, Naomi, are you interested in trying to implement this?

-- 
--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 484 update proposal: annotating decorated declarations

[Ivan Levkivskyi]

On 30 May 2017 at 23:02, Guido van Rossum  wrote:

>
> All in all I'm still leaning towards Naomi's original proposal -- it looks
> simpler to implement as well.
>
>
OK, I think having a bit of verbosity is absolutely fine if we win
simplicity of implementation (for both static and runtime purposes).

--
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 484 update proposal: annotating decorated declarations

[Guido van Rossum]

> On 15 May 2017 at 10:48, Koos Zevenhoven  wrote:
>
>> Would __annotations__ be set by the decorator? To me, not setting them
>> would seem weird, but cases where the result is not a function could
>> be weird. I also don't see a mention of this only working in stubs.
>>
>
It took me a while to realize which annotations we're talking about here.

I like Jukka's version, as it has a clear distinction between
>> functions and other attributes. But that might require a language
>> change to provide __annotations__ in a clean manner? Maybe that
>> language change would be useful elsewhere.
>
>
I'm not interesting in language changes to solve this problem.

On Mon, May 15, 2017 at 6:20 AM, Ivan Levkivskyi 
wrote:

> With original syntax it is possible to overwrite annotations without
> language changes.
> However with Jukka's syntax it looks difficult. A possible pure-Python way
> could be
> to insert an item in an enclosing __annotations__, if an enclosing scope
> is a class or module scope.
>

I assume we're talking about `session.__annotations__`, which will be
overwritten by the last definition (i.e. the "implementation"). This is
only a runtime problem, and we're actually still a bit better off here than
for @overload -- for @overload, the implementation is often un-annotated or
has very vague annotations (e.g. `*args: Any`), while here the annotations
are in principle preserved by the decorators on the implementation
function. (The main premise of the proposal under discussion is to clarify
the type for the *human* reader, although in some edge cases the explicit
annotation may provide a constraint for the naturally inferred type of the
decorated function.)

But in either case the annotations on the overload variants or the
"declaration" are lost at runtime by the trick of using multiple
definitions, since at runtime the last definition wins. (And we don't want
to go through the contortions used by e.g. @property for collecting getters
and setters belonging to a single attribute.)

The question then is, do we care more about the runtime accessibility of
the type, or do we care more about ease of use in a context of static
analysis? In general with the design of PEP 484 I've tried to balance the
two (and several other constraints like no changes to the core Python
language).

I'm still not decided. Let's compare the two proposals quickly. In Naomi's
version you'd write

@decorated_type(Callable[[str], ContextManager[DbSession]])
@contextmanager
def session(url: str) -> Iterator[DbSession]:


while in Jukka's version you'd write

@declared_type
def session(url: str) -> ContextManager[DbSession]: ...

@contextmanager
def session(url: str) -> Iterator[DbSession]:


There's also a difference in power between the two: in Naomi's proposal,
session's type becomes exactly

Callable[[str], ContextManager[DbSession]]

which can only be called with positional arguments, whereas in Jukka's
proposal session will retain the name and clasiffication (e.g.
keyword-only, varargs) of the arguments. If those are important, in Naomi's
case this can be written using the new "argspecs" form of Callable, i.e.

@decorated_type(Callable[[Arg(str, 'url')], ContextManager[DbSession])
@contextmanager
def session 

which is definitely more verbose and uglier than Jukka's version. OTOH it
does mean that Naomi's proposal has all the *power* of Jukka's version --
and in simple cases it is actually less verbose than Jukka's proposal (in
cases where you want all that power -- if you're happy with a basic
callable it's actually *less* verbose).

Jukka's version also needs another special case where the decorator returns
something that's not a callable. In Naomi's proposal this would simply be

@decorated_type(SomeType)
@some_decorator
def my_thing(url: str) -> int:


Jukka's proposal *seems* to be to just allow overriding a variable
declaration with a function declararion:

my_thing: SomeType

@some_decorator
def my_thing 

This seems fragile to me (since it looks like an accidental redefinition,
although typically the static check would find a discrepancy between the
inferred type of the first and the second definition).

All in all I'm still leaning towards Naomi's original proposal -- it looks
simpler to implement as well.

-- 
--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 484 update proposal: annotating decorated declarations

[Ivan Levkivskyi]

On 15 May 2017 at 10:48, Koos Zevenhoven  wrote:

> > Here's the proposed text (wordsmithing suggestions in the PR please):
> >
> > +Decorators
> > +--
> > +
> > +Decorators can modify the types of the functions or classes they
> > +decorate. Use the ``decorated_type`` decorator to declare the type of
> > +the resulting item after all other decorators have been applied::
> > +
> > + from typing import ContextManager, Iterator, decorated_type
> > + from contextlib import contextmanager
> > +
> > + class DatabaseSession: ...
> > +
> > + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
> > + @contextmanager
> > + def session(url: str) -> Iterator[DatabaseSession]:
> > + s = DatabaseSession(url)
> > + try:
> > + yield s
> > + finally:
> > + s.close()
> > +
> > +The argument of ``decorated_type`` is a type annotation on the name
> > +being declared (``session``, in the example above). If you have
> > +multiple decorators, ``decorated_type`` must be topmost. The
> > +``decorated_type`` decorator is invalid on a function declaration that
> > +is also decorated with ``overload``, but you can annotate the
> > +implementation of the overload series with ``decorated_type``.
> > +
> >
>
> Would __annotations__ be set by the decorator? To me, not setting them
> would seem weird, but cases where the result is not a function could
> be weird. I also don't see a mention of this only working in stubs.
>
> I like Jukka's version, as it has a clear distinction between
> functions and other attributes. But that might require a language
> change to provide __annotations__ in a clean manner? Maybe that
> language change would be useful elsewhere.


With original syntax it is possible to overwrite annotations without
language changes.
However with Jukka's syntax it looks difficult. A possible pure-Python way
could be
to insert an item in an enclosing __annotations__, if an enclosing scope
is a class or module scope.

--
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 484 update proposal: annotating decorated declarations

[Koos Zevenhoven]

On Tue, May 9, 2017 at 8:19 PM, Guido van Rossum  wrote:
> There's a PR to the peps proposal here:
> https://github.com/python/peps/pull/242
>
> The full text of the current proposal is below. The motivation for this is
> that for complex decorators, even if the type checker can figure out what's
> going on (by taking the signature of the decorator into account), it's
> sometimes helpful to the human reader of the code to be reminded of the type
> after applying the decorators (or a stack thereof). Much discussion can be
> found in the PR. Note that we ended up having `Callable` in the type because
> there's no rule that says a decorator returns a function type (e.g.
> `property` doesn't).
>
> This is a small thing but I'd like to run it by a larger audience than the
> core mypy devs who have commented so far. There was a brief discussion on
> python-ideas (my original, favorable reply by Nick, my response).
>
> Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan
> Levkivskyi and Jukka Lehtosalo.
>
> If there's no further debate here I'll merge it into the PEP and an
> implementation will hopefully appear in the next version of the typing
> module (also hopefully to be included in CPython 3.6.2 and 3.5.4).
>

So the change would only affect early adopters of this typing feature,
who are likely to upgrade to newer python versions often? Could this
be called a 3.7 feature with a clearly documented bonus that it also
works in 3.6.2+ and 3.5.4+? I mean, to prevent 3rd-party libraries
tested with 3.5(.4) from being broken in 3.5.3?

> Here's the proposed text (wordsmithing suggestions in the PR please):
>
> +Decorators
> +--
> +
> +Decorators can modify the types of the functions or classes they
> +decorate. Use the ``decorated_type`` decorator to declare the type of
> +the resulting item after all other decorators have been applied::
> +
> + from typing import ContextManager, Iterator, decorated_type
> + from contextlib import contextmanager
> +
> + class DatabaseSession: ...
> +
> + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
> + @contextmanager
> + def session(url: str) -> Iterator[DatabaseSession]:
> + s = DatabaseSession(url)
> + try:
> + yield s
> + finally:
> + s.close()
> +
> +The argument of ``decorated_type`` is a type annotation on the name
> +being declared (``session``, in the example above). If you have
> +multiple decorators, ``decorated_type`` must be topmost. The
> +``decorated_type`` decorator is invalid on a function declaration that
> +is also decorated with ``overload``, but you can annotate the
> +implementation of the overload series with ``decorated_type``.
> +
>

Would __annotations__ be set by the decorator? To me, not setting them
would seem weird, but cases where the result is not a function could
be weird. I also don't see a mention of this only working in stubs.

I like Jukka's version, as it has a clear distinction between
functions and other attributes. But that might require a language
change to provide __annotations__ in a clean manner? Maybe that
language change would be useful elsewhere.

—Koos



-- 
+ 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 484 update proposal: annotating decorated declarations

[Steven D'Aprano]

On Tue, May 09, 2017 at 11:54:26PM +0400, Abdur-Rahmaan Janhangeer wrote:
> I'm really new to the mailing list. Can someone just summarise the
> preceding message in 5 to 10 lines like what it is, what type is it or when
> does it happen

It is an update to PEP 484, adding support for type-checking decorators.

https://www.python.org/dev/peps/pep-0484/

I don't understand what you mean by "what type is it".

When does it happen: if there are no strong or conclusive objections
(and I don't think there have been) it may have already happened by now.
If not, then soon. Depends on Guido's schedule.

As for when it will actually be visible in Python, the original post 
already answered that: Guido hopes to add it to Python 3.6.2 and 3.5.4. 
I don't think this will have much visible impact unless you're using 
MyPy for type checking.

By the way, the original post was less than fifty lines. That already 
is a summary.


-- 
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 484 update proposal: annotating decorated declarations

[Naomi Seyfer]

I think you're right that the redefinition style is easier to read for 
complicated stuff... It also seems more complicated in a way I can't put my 
finger on. 

The overload precedent helps. 

Currently leaning towards Jukka being right, vague worries about extra 
complication be damned. 

Readability is more important. 

> On May 10, 2017, at 5:23 AM, Jukka Lehtosalo  wrote:
> 
> Even if Callable types will soon support keyword arguments, the syntax for 
> Callables will look quite different from function definitions and this 
> inconsistency may hurt readability, at least for more complex signatures. We 
> could work around this by using the def syntax for the declared type of a 
> decorator. For example:
> 
> @declared_type
> def session(url: str) -> ContextManager[DatabaseSession]: ...  # Explicit 
> '...'
> 
> @contextmanager
> def session(url: str) -> Iterator[DatabaseSession]:
> s = DatabaseSession(url)
> ...
> 
> This would be quite similar to how overloads work, so there is a precedent 
> for something like this. We could require or recommend that the declared type 
> comes immediately before the implementation so that the entire definition of 
> a single function would not be too spread out.
> 
> This won't help if the decorated type is not a callable. We could support 
> this use case by using the normal variable annotation syntax:
> 
> thing: Decorated  # Declared type of 'thing'
> 
> @decorator
> def thing() -> int:
> ...
> 
> Jukka
> 
>> On Wed, May 10, 2017 at 12:27 AM, Naomi Seyfer  wrote:
>> Stay tuned for the pep that allows callable to take keyword args. 
>> 
>>> On May 9, 2017, at 3:59 PM, Brett Cannon  wrote:
>>> 
>>> The idea seems reasonable to me when viewing type hints as a form of 
>>> documentation as it helps remind people how they are expected to call the 
>>> final function.
>>> 
>>> One worry I do have, though, is Callable doesn't support keyword-only 
>>> parameters, so declared_type won't work in all cases without Callable 
>>> gaining such support (for those that don't know, Callable didn't start with 
>>> that support as Callable has been meant for callback scenarios up to this 
>>> point).
>>> 
 On Tue, 9 May 2017 at 10:21 Guido van Rossum  wrote:
 There's a PR to the peps proposal here:
 https://github.com/python/peps/pull/242
 
 The full text of the current proposal is below. The motivation for this is 
 that for complex decorators, even if the type checker can figure out 
 what's going on (by taking the signature of the decorator into account), 
 it's sometimes helpful to the human reader of the code to be reminded  of 
 the type after applying the decorators (or a stack thereof). Much 
 discussion can be found in the PR. Note that we ended up having `Callable` 
 in the type because there's no rule that says a decorator returns a 
 function type (e.g. `property` doesn't).
 
 This is a small thing but I'd like to run it by a larger audience than the 
 core mypy devs who have commented so far. There was a brief discussion on 
 python-ideas (my original, favorable reply by Nick, my response).
 
 Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan 
 Levkivskyi and Jukka Lehtosalo.
 
 If there's no further debate here I'll merge it into the PEP and an 
 implementation will hopefully appear in the next version of the typing 
 module (also hopefully to be included in CPython 3.6.2 and 3.5.4).
 
 Here's the proposed text (wordsmithing suggestions in the PR please):
 
 +Decorators
 +--
 +
 +Decorators can modify the types of the functions or classes they
 +decorate. Use the ``decorated_type`` decorator to declare the type of
 +the resulting item after all other decorators have been applied::
 +
 + from typing import ContextManager, Iterator, decorated_type
 + from contextlib import contextmanager
 +
 + class DatabaseSession: ...
 +
 + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
 + @contextmanager
 + def session(url: str) -> Iterator[DatabaseSession]:
 + s = DatabaseSession(url)
 + try:
 + yield s
 + finally:
 + s.close()
 +
 +The argument of ``decorated_type`` is a type annotation on the name
 +being declared (``session``, in the example above). If you have
 +multiple decorators, ``decorated_type`` must be topmost. The
 +``decorated_type`` decorator is invalid on a function declaration that
 +is also decorated with ``overload``, but you can annotate the
 +implementation of the overload series with ``decorated_type``.
 +
 
 -- 
 --Guido van Rossum (python.org/~guido)
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

[Jukka Lehtosalo]

Even if Callable types will soon support keyword arguments, the syntax for
Callables will look quite different from function definitions and this
inconsistency may hurt readability, at least for more complex signatures.
We could work around this by using the def syntax for the declared type of
a decorator. For example:

@declared_type
def session(url: str) -> ContextManager[DatabaseSession]: ...  # Explicit
'...'

@contextmanager
def session(url: str) -> Iterator[DatabaseSession]:
s = DatabaseSession(url)
...

This would be quite similar to how overloads work, so there is a precedent
for something like this. We could require or recommend that the declared
type comes immediately before the implementation so that the entire
definition of a single function would not be too spread out.

This won't help if the decorated type is not a callable. We could support
this use case by using the normal variable annotation syntax:

thing: Decorated  # Declared type of 'thing'

@decorator
def thing() -> int:
...

Jukka

On Wed, May 10, 2017 at 12:27 AM, Naomi Seyfer  wrote:

> Stay tuned for the pep that allows callable to take keyword args.
>
> On May 9, 2017, at 3:59 PM, Brett Cannon  wrote:
>
> The idea seems reasonable to me when viewing type hints as a form of
> documentation as it helps remind people how they are expected to call the
> final function.
>
> One worry I do have, though, is Callable doesn't support keyword-only
> parameters, so declared_type won't work in all cases without Callable
> gaining such support (for those that don't know, Callable didn't start with
> that support as Callable has been meant for callback scenarios up to this
> point).
>
> On Tue, 9 May 2017 at 10:21 Guido van Rossum  wrote:
>
>> There's a PR to the peps proposal here:
>> https://github.com/python/peps/pull/242
>>
>> The full text of the current proposal is below. The motivation for this
>> is that for complex decorators, even if the type checker can figure out
>> what's going on (by taking the signature of the decorator into account),
>> it's sometimes helpful to the human reader of the code to be reminded of
>> the type after applying the decorators (or a stack thereof). Much
>> discussion can be found in the PR. Note that we ended up having `Callable`
>> in the type because there's no rule that says a decorator returns a
>> function type (e.g. `property` doesn't).
>>
>> This is a small thing but I'd like to run it by a larger audience than
>> the core mypy devs who have commented so far. There was a brief discussion
>> on python-ideas (my original
>> ,
>> favorable reply
>>  by
>> Nick, my response
>> ).
>>
>> Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan
>> Levkivskyi and Jukka Lehtosalo.
>>
>> If there's no further debate here I'll merge it into the PEP and an
>> implementation will hopefully appear in the next version of the typing
>> module (also hopefully to be included in CPython 3.6.2 and 3.5.4).
>>
>> Here's the proposed text (wordsmithing suggestions in the PR please):
>>
>> +Decorators
>> +--
>> +
>> +Decorators can modify the types of the functions or classes they
>> +decorate. Use the ``decorated_type`` decorator to declare the type of
>> +the resulting item after all other decorators have been applied::
>> +
>> + from typing import ContextManager, Iterator, decorated_type
>> + from contextlib import contextmanager
>> +
>> + class DatabaseSession: ...
>> +
>> + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
>> + @contextmanager
>> + def session(url: str) -> Iterator[DatabaseSession]:
>> + s = DatabaseSession(url)
>> + try:
>> + yield s
>> + finally:
>> + s.close()
>> +
>> +The argument of ``decorated_type`` is a type annotation on the name
>> +being declared (``session``, in the example above). If you have
>> +multiple decorators, ``decorated_type`` must be topmost. The
>> +``decorated_type`` decorator is invalid on a function declaration that
>> +is also decorated with ``overload``, but you can annotate the
>> +implementation of the overload series with ``decorated_type``.
>> +
>>
>> --
>> --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/
> jlehtosalo%40gmail.com
>
>

Re: [Python-Dev] PEP 484 proposal: don't default to Optional if argument default is None

[Ivan Levkivskyi]

There is a discrepancy now between PEP 484 and PEP 526:

def f(x: int = None): ... # OK
x: int = None # Error

I think the two rules should be "in sync", in view of this I agree with the
proposal.

Concerning verbosity and a long name Optional there are many reasonable
workarounds.
One is already mentioned from typing import Optional as O. Another
(unrelated to `` = None`` pattern)
is https://github.com/python/typing/issues/420 that allows to avoid
Optional altogether in patterns like this:

def func(x: Optional[X]) -> Optional[Y]:
if x is None:
return None
# do some stuff with 'x'

With @maybe decorator proposed in
https://github.com/python/typing/issues/420
this will be simplified to:

@maybe
def func(x: X) -> Y:
if x is None:
return None
# do some stuff with 'x'

Even if @maybe will not make it to typing, one still can define such (or
similar) decorators
(especially with @decorated_type and extended Callable syntax).

In view of this, I think verbosity is not a problem at all.

--
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 484 proposal: don't default to Optional if argument default is None

[Guido van Rossum]

On Tue, May 9, 2017 at 7:37 PM, Nick Coghlan  wrote:

> On 10 May 2017 at 08:51, Brett Cannon  wrote:
> > On Tue, 9 May 2017 at 11:11 Carl Meyer  wrote:
> >> It might be nice to have a less verbose syntax for Optional, but that
> >> can be a separate discussion.
> >
> > You should be able to do that today with `from typing import Optional as
> Eh`
> > or whatever your preferred optional/maybe name is. :)
>
> While "from typing import Optional as Opt" can indeed help, perhaps
> PEP 505 should be updated to discuss this point in addition to the
> current proposals for None-aware binary operators?
>
> If it included a ? prefix operator as a shorthand for
> "typing.Optional[]", that would shorten affected declarations
> back to:
>
> def handle_employee(e: ?Employee = None) -> None: ...
>

I really don't want to go there. And this idea should definitely not be a
condition for removing the existing PEP 484 feature. Whatever gets done
syntax-wise won't affect anyone who needs any kind of backward
compatibility anyways, and that's very important for practical adoption of
PEP 484.

-- 
--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 484 proposal: don't default to Optional if argument default is None

[Nick Coghlan]

On 10 May 2017 at 08:51, Brett Cannon  wrote:
> On Tue, 9 May 2017 at 11:11 Carl Meyer  wrote:
>> It might be nice to have a less verbose syntax for Optional, but that
>> can be a separate discussion.
>
> You should be able to do that today with `from typing import Optional as Eh`
> or whatever your preferred optional/maybe name is. :)

While "from typing import Optional as Opt" can indeed help, perhaps
PEP 505 should be updated to discuss this point in addition to the
current proposals for None-aware binary operators?

If it included a ? prefix operator as a shorthand for
"typing.Optional[]", that would shorten affected declarations
back to:

def handle_employee(e: ?Employee = None) -> None: ...

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 484 update proposal: annotating decorated declarations

[Naomi Seyfer]

Stay tuned for the pep that allows callable to take keyword args. 

> On May 9, 2017, at 3:59 PM, Brett Cannon  wrote:
> 
> The idea seems reasonable to me when viewing type hints as a form of 
> documentation as it helps remind people how they are expected to call the 
> final function.
> 
> One worry I do have, though, is Callable doesn't support keyword-only 
> parameters, so declared_type won't work in all cases without Callable gaining 
> such support (for those that don't know, Callable didn't start with that 
> support as Callable has been meant for callback scenarios up to this point).
> 
>> On Tue, 9 May 2017 at 10:21 Guido van Rossum  wrote:
>> There's a PR to the peps proposal here:
>> https://github.com/python/peps/pull/242
>> 
>> The full text of the current proposal is below. The motivation for this is 
>> that for complex decorators, even if the type checker can figure out what's 
>> going on (by taking the signature of the decorator into account), it's 
>> sometimes helpful to the human reader of the code to be reminded of the type 
>> after applying the decorators (or a stack thereof). Much discussion can be 
>> found in the PR. Note that we ended up having `Callable` in the type because 
>> there's no rule that says a decorator returns a function type (e.g. 
>> `property` doesn't).
>> 
>> This is a small thing but I'd like to run it by a larger audience than the 
>> core mypy devs who have commented so far. There was a brief discussion on 
>> python-ideas (my original, favorable reply by Nick, my response).
>> 
>> Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan 
>> Levkivskyi and Jukka Lehtosalo.
>> 
>> If there's no further debate here I'll merge it into the PEP and an 
>> implementation will hopefully appear in the next version of the typing 
>> module (also hopefully to be included in CPython 3.6.2 and 3.5.4).
>> 
>> Here's the proposed text (wordsmithing suggestions in the PR please):
>> 
>> +Decorators
>> +--
>> +
>> +Decorators can modify the types of the functions or classes they
>> +decorate. Use the ``decorated_type`` decorator to declare the type of
>> +the resulting item after all other decorators have been applied::
>> +
>> + from typing import ContextManager, Iterator, decorated_type
>> + from contextlib import contextmanager
>> +
>> + class DatabaseSession: ...
>> +
>> + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
>> + @contextmanager
>> + def session(url: str) -> Iterator[DatabaseSession]:
>> + s = DatabaseSession(url)
>> + try:
>> + yield s
>> + finally:
>> + s.close()
>> +
>> +The argument of ``decorated_type`` is a type annotation on the name
>> +being declared (``session``, in the example above). If you have
>> +multiple decorators, ``decorated_type`` must be topmost. The
>> +``decorated_type`` decorator is invalid on a function declaration that
>> +is also decorated with ``overload``, but you can annotate the
>> +implementation of the overload series with ``decorated_type``.
>> +
>> 
>> -- 
>> --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 484 update proposal: annotating decorated declarations

[Brett Cannon]

The idea seems reasonable to me when viewing type hints as a form of
documentation as it helps remind people how they are expected to call the
final function.

One worry I do have, though, is Callable doesn't support keyword-only
parameters, so declared_type won't work in all cases without Callable
gaining such support (for those that don't know, Callable didn't start with
that support as Callable has been meant for callback scenarios up to this
point).

On Tue, 9 May 2017 at 10:21 Guido van Rossum  wrote:

> There's a PR to the peps proposal here:
> https://github.com/python/peps/pull/242
>
> The full text of the current proposal is below. The motivation for this is
> that for complex decorators, even if the type checker can figure out what's
> going on (by taking the signature of the decorator into account), it's
> sometimes helpful to the human reader of the code to be reminded of the
> type after applying the decorators (or a stack thereof). Much discussion
> can be found in the PR. Note that we ended up having `Callable` in the type
> because there's no rule that says a decorator returns a function type (e.g.
> `property` doesn't).
>
> This is a small thing but I'd like to run it by a larger audience than the
> core mypy devs who have commented so far. There was a brief discussion on
> python-ideas (my original
> ,
> favorable reply
>  by
> Nick, my response
> ).
>
> Credit for the proposal goes to Naomi Seyfer, with discussion by Ivan
> Levkivskyi and Jukka Lehtosalo.
>
> If there's no further debate here I'll merge it into the PEP and an
> implementation will hopefully appear in the next version of the typing
> module (also hopefully to be included in CPython 3.6.2 and 3.5.4).
>
> Here's the proposed text (wordsmithing suggestions in the PR please):
>
> +Decorators
> +--
> +
> +Decorators can modify the types of the functions or classes they
> +decorate. Use the ``decorated_type`` decorator to declare the type of
> +the resulting item after all other decorators have been applied::
> +
> + from typing import ContextManager, Iterator, decorated_type
> + from contextlib import contextmanager
> +
> + class DatabaseSession: ...
> +
> + @decorated_type(Callable[[str], ContextManager[DatabaseSession]])
> + @contextmanager
> + def session(url: str) -> Iterator[DatabaseSession]:
> + s = DatabaseSession(url)
> + try:
> + yield s
> + finally:
> + s.close()
> +
> +The argument of ``decorated_type`` is a type annotation on the name
> +being declared (``session``, in the example above). If you have
> +multiple decorators, ``decorated_type`` must be topmost. The
> +``decorated_type`` decorator is invalid on a function declaration that
> +is also decorated with ``overload``, but you can annotate the
> +implementation of the overload series with ``decorated_type``.
> +
>
> --
> --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 484 proposal: don't default to Optional if argument default is None

[Brett Cannon]

On Tue, 9 May 2017 at 11:11 Carl Meyer  wrote:

> On 05/09/2017 10:28 AM, Guido van Rossum wrote:
> > There's a proposal to change one detail of PEP 484. It currently says:
> >
> > An optional type is also automatically assumed when the default
> value is
> > |None|, for example::
> >
> > |def handle_employee(e: Employee = None): ... |
> >
> > This is equivalent to::
> >
> > |def handle_employee(e: Optional[Employee] = None) -> None: ... |
> >
> >
> > Now that we've got some experience actually using Optional with mypy
> > (originally mypy ignored Optional), we're beginning to think that this
> > was a bad idea. There's more discussion at
> > https://github.com/python/typing/issues/275 and an implementation of the
> > change (using a command-line flag) in
> > https://github.com/python/mypy/pull/3248.
> >
> > Thoughts? Some function declarations will become a bit more verbose, but
> > we gain clarity (many users of annotations don't seem to be familiar
> > with this feature) and consistency (since this rule doesn't apply to
> > variable declarations and class attribute declarations).
>
> I've been code-reviewing a lot of diffs adding type coverage over the
> last few months, and implicit-Optional has been among the most common
> points of confusion. So I favor this change.
>

I personally like the shorthand, but the type hints I have written are in
my own projects so my experience with others is zilch and shouldn't count
for much.


>
> It might be nice to have a less verbose syntax for Optional, but that
> can be a separate discussion.
>

You should be able to do that today with `from typing import Optional as
Eh` or whatever your preferred optional/maybe name is. :)
___
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 484 update proposal: annotating decorated declarations

[Abdur-Rahmaan Janhangeer]

I'm really new to the mailing list. Can someone just summarise the
preceding message in 5 to 10 lines like what it is, what type is it or when
does it happen

Thanks for all,

Abdur-Rahmaan Janhangeer
Vacoas,
Mauritius
https://abdurrahmaanjanhangeer.wordpress.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 484 proposal: don't default to Optional if argument default is None

[Carl Meyer]

On 05/09/2017 10:28 AM, Guido van Rossum wrote:
> There's a proposal to change one detail of PEP 484. It currently says:
> 
> An optional type is also automatically assumed when the default value is
> |None|, for example::
> 
> |def handle_employee(e: Employee = None): ... |
> 
> This is equivalent to::
> 
> |def handle_employee(e: Optional[Employee] = None) -> None: ... |
> 
> 
> Now that we've got some experience actually using Optional with mypy
> (originally mypy ignored Optional), we're beginning to think that this
> was a bad idea. There's more discussion at
> https://github.com/python/typing/issues/275 and an implementation of the
> change (using a command-line flag) in
> https://github.com/python/mypy/pull/3248.
> 
> Thoughts? Some function declarations will become a bit more verbose, but
> we gain clarity (many users of annotations don't seem to be familiar
> with this feature) and consistency (since this rule doesn't apply to
> variable declarations and class attribute declarations).

I've been code-reviewing a lot of diffs adding type coverage over the
last few months, and implicit-Optional has been among the most common
points of confusion. So I favor this change.

It might be nice to have a less verbose syntax for Optional, but that
can be a separate discussion.

Carl



signature.asc
Description: OpenPGP digital signature
___
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 484 update: allow @overload in regular module files

[Guido van Rossum]

This seemed pretty uncontroversial. I've updated the PEP.

On Sat, Mar 19, 2016 at 6:52 PM, Guido van Rossum  wrote:
> Here's another proposal for a change to PEP 484.
>
> In https://github.com/python/typing/issues/72 there's a long
> discussion ending with a reasonable argument to allow @overload in
> (non-stub) modules after all.
>
> This proposal does *not* sneak in a syntax for multi-dispatch -- the
> @overload versions are only for the benefit of type checkers while a
> single non-@overload implementation must follow that handles all
> cases. In fact, I expect that if we ever end up adding multi-dispatch
> to the language or library, it will neither replace not compete with
> @overload, but the two will most likely be orthogonal to each other,
> with @overload aiming at a type checker and some other multi-dispatch
> aiming at the interpreter. (The needs of the two cases are just too
> different -- e.g. it's hard to imagine multi-dispatch in Python use
> type variables.) More details in the issue (that's also where I'd like
> to get feedback if possible).
>
> I want to settle this before 3.5.2 goes out, because it requires a
> change to typing.py in the stdlib. Fortunately the change will be
> backward compatible (even though this isn't strictly required for a
> provisional module). In the original typing module, any use of
> @overload outside a stub is an error (it raises as soon as it's used).
> In the new proposal, you can decorate a function with @overload, but
> any attempt to call such a decorated function raises an error. This
> should catch cases early where you forget to provide an
> implementation.
>
> (Reference for provisional modules: https://www.python.org/dev/peps/pep-0411/)
>
> --
> --Guido van Rossum (python.org/~guido)



-- 
--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 484: updates to Python 2.7 signature syntax

[Guido van Rossum]

This seemed pretty uncontroversial -- I've updated the PEP (including
a long(ish) example :-).

On Sat, Mar 19, 2016 at 6:54 PM, Guido van Rossum  wrote:
> Heh. I could add an example with a long list of parameters with long
> names, but apart from showing by example what the motivation is it
> wouldn't really add anything, and it's more to type. :-)
>
> On Sat, Mar 19, 2016 at 6:43 PM, Andrew Barnert  wrote:
>> On Mar 19, 2016, at 18:18, Guido van Rossum  wrote:
>>>
>>> Second, https://github.com/python/typing/issues/186. This builds on
>>> the previous syntax but deals with the other annoyance of long
>>> argument lists, this time in case you *do* care about the types. The
>>> proposal is to allow writing the arguments one per line with a type
>>> comment on each line. This has been implemented in PyCharm but not yet
>>> in mypy. Example:
>>>
>>>def gcd(
>>>a,  # type: int
>>>b,  # type: int
>>>):
>>># type: (...) -> int
>>>
>>
>> This is a lot nicer than what you were originally discussing (at #1101? I 
>> forget...). Even more so given how trivial it will be to mechanically 
>> convert these to annotations if/when you switch an app to pure Python 3.
>>
>> But one thing: in the PEP and the docs, I think it would be better to pick 
>> an example with longer parameter names. This example shows that even in the 
>> worst case it isn't that bad, but a better example would show that in the 
>> typical case it's actually pretty nice. (Also, I don't see why you wouldn't 
>> just use the "old" comment form for this example, since it all fits on one 
>> line and isn't at all confusing.)
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)



-- 
--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 484: a "NewType" constructor

[Guido van Rossum]

Sorry, for PEP feedback it's best to use this issue in the typing
tracker: https://github.com/python/typing/issues/189 (the issue I
linked to was in the mypy tracker).

On Mon, Mar 21, 2016 at 9:15 AM, Guido van Rossum  wrote:
> Here's one more thing we'd like to add to PEP 484. The description is
> best gleaned from the issue, in particular
> https://github.com/python/mypy/issues/1284#issuecomment-199021176 and
> following (we're going with option (A)).
>
> Really brief example:
>
>   from typing import NewType
>   UserId = NewType('UserId', int)
>
> Now to the type checker UserId is a new type that's compatible with
> int, but converting an int to a UserId requires a special cast form,
> UserId(x). At runtime UserId instances are just ints (not a subclass!)
> and UserId() is a dummy function that just returns its argument.
>
> For use cases see the issue. Also send feedback there please.
>
> --
> --Guido van Rossum (python.org/~guido)



-- 
--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 484: updates to Python 2.7 signature syntax

[Guido van Rossum]

Heh. I could add an example with a long list of parameters with long
names, but apart from showing by example what the motivation is it
wouldn't really add anything, and it's more to type. :-)

On Sat, Mar 19, 2016 at 6:43 PM, Andrew Barnert  wrote:
> On Mar 19, 2016, at 18:18, Guido van Rossum  wrote:
>>
>> Second, https://github.com/python/typing/issues/186. This builds on
>> the previous syntax but deals with the other annoyance of long
>> argument lists, this time in case you *do* care about the types. The
>> proposal is to allow writing the arguments one per line with a type
>> comment on each line. This has been implemented in PyCharm but not yet
>> in mypy. Example:
>>
>>def gcd(
>>a,  # type: int
>>b,  # type: int
>>):
>># type: (...) -> int
>>
>
> This is a lot nicer than what you were originally discussing (at #1101? I 
> forget...). Even more so given how trivial it will be to mechanically convert 
> these to annotations if/when you switch an app to pure Python 3.
>
> But one thing: in the PEP and the docs, I think it would be better to pick an 
> example with longer parameter names. This example shows that even in the 
> worst case it isn't that bad, but a better example would show that in the 
> typical case it's actually pretty nice. (Also, I don't see why you wouldn't 
> just use the "old" comment form for this example, since it all fits on one 
> line and isn't at all confusing.)
>



-- 
--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 484: updates to Python 2.7 signature syntax

[Andrew Barnert via Python-Dev]

On Mar 19, 2016, at 18:18, Guido van Rossum  wrote:
> 
> Second, https://github.com/python/typing/issues/186. This builds on
> the previous syntax but deals with the other annoyance of long
> argument lists, this time in case you *do* care about the types. The
> proposal is to allow writing the arguments one per line with a type
> comment on each line. This has been implemented in PyCharm but not yet
> in mypy. Example:
> 
>def gcd(
>a,  # type: int
>b,  # type: int
>):
># type: (...) -> int
>

This is a lot nicer than what you were originally discussing (at #1101? I 
forget...). Even more so given how trivial it will be to mechanically convert 
these to annotations if/when you switch an app to pure Python 3.

But one thing: in the PEP and the docs, I think it would be better to pick an 
example with longer parameter names. This example shows that even in the worst 
case it isn't that bad, but a better example would show that in the typical 
case it's actually pretty nice. (Also, I don't see why you wouldn't just use 
the "old" comment form for this example, since it all fits on one line and 
isn't at all confusing.)

___
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 484 -- proposal to allow @overload in non-stub files

[Guido van Rossum]

I've thought this over and I don't think it's worth it. We need to wait for
a working proposal for multi-dispatch first. Otherwise we'll just end up
having to support this interim syntax *and* whatever the new multi-dispatch
is. Keeping @overload restricted to stub files makes it much more tractable.

On Thu, Oct 22, 2015 at 10:51 AM, Guido van Rossum  wrote:

> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith  wrote:
>
>>
>>
>> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum 
>> wrote:
>>
>>> Well the whole point is not to have to figure out how to implement that
>>> right now.
>>>
>>> On Wed, Oct 21, 2015 at 6:45 PM, Random832 
>>> wrote:
>>>
 Guido van Rossum  writes:
 > The proposal is to allow this to be written as follows in
 > implementation (non-stub) modules:
 >
 > class Foo(Generic[T]):
 > @overload
 > def __getitem__(self, i: int) -> T: ...
 > @overload
 > def __getitem__(self, s: slice) -> Foo[T]: ...
 > def __getitem__(self, x):
 > 
 >
 > The actual implementation must be last, so at run time it will
 > override the definition.

>>>
>> I think this *could* be fine. It is certainly readable. And, as is
>> already possible in .pyi files, more accurately expressive than the Union
>> which doesn't imply a parameter type to return value type relationship.
>>
>
> Right, which is how this got started.
>
>
>> What would it Foo.__getitem__.__annotations__ contain in this situation?
>> It'd unfortunately be an empty dict if implemented in the most trivial
>> fashion rather than a dict containing your Unions... Do we care?
>>
>
> Initially it would indeed be {}. Once we have a true multi-dispatch PEP we
> can iterate, both on how to spell it (perhaps the final __getitem__ needs
> an @overload as well) and on what happens in the annotations (or at least,
> what typing.get_type_hints() returns).
>
> We could also wait for a multidispatch PEP to land -- but I'm worried that
> we'll be waiting past 3.6.
>
> Then again I don't see how true multidispatch would be able to deal with
> the syntax proposed here -- you need some kind of decorator on the fallback
> implementation.
>
>
>> Note that it would also slow down module import time as the code for each
>> of the earlier ... definitions with annotation structures and @overload
>> decorator calls is executed, needlessly creating objects and structures
>> that are immediately discarded upon each subsequent definition.
>>
>
> Yes, but I don't think this is going to make a noticeable difference.
>
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
--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 484 -- proposal to allow @overload in non-stub files

[Guido van Rossum]

On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan  wrote:

> On 22 October 2015 at 19:51, Guido van Rossum  wrote:
> > On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith 
> wrote:
> >> What would it Foo.__getitem__.__annotations__ contain in this situation?
> >> It'd unfortunately be an empty dict if implemented in the most trivial
> >> fashion rather than a dict containing your Unions... Do we care?
> >
> > Initially it would indeed be {}. Once we have a true multi-dispatch PEP
> we
> > can iterate, both on how to spell it (perhaps the final __getitem__
> needs an
> > @overload as well) and on what happens in the annotations (or at least,
> what
> > typing.get_type_hints() returns).
>
> Just ensuring I understand the problem with using a third @overload in
> the spelling from the start:
>
> class Foo(Generic[T]):
> @overload
> def __getitem__(self, i: int) -> T: ...
>
> @overload
> def __getitem__(self, s: slice) -> Foo[T]: ...
>
> @overload
> def __getitem__(self, x):
> 
>
> If we did this, the implied annotation on the last method would be:
>
> @overload
> def __getitem__(self, x: Any) -> Any:
> 
>
> which gets the signature wrong - this isn't an Any:Any mapping, it's a
> sequence.
>

Well, a type checker could handle the special case of the last overload.
There should be a rule that overloads are handled in the order in which
they are processed; it's not explicit in the PEP but it's meant to be that
way, in case there's overlap between signatures. (This differs from
singledispatch: when overloading on multiple types it's not always possible
to disambiguate by using the most derived type.)

But allowing this in code without having a full-fledged multi-dispatch
implementation in @overload would cause confusion in readers, which is why
we decided to disallow it outside stubs.


> Leaving the "@overload" out thus indicates that the definition is an
> implementation of the preceding type based dispatch declaration,
> rather than a new overload.
>

Yeah, that was the proposal. But I no longer think it's worth it.


> Assuming a future multidispatch implementation used
> "functools.multidispatch" as the decorator (to complement the existing
> functools.singledispatch) rather than "typing.overload", this seems
> like a reasonable short term solution to me.
>

But once we have a functools.multidispatch, why would we also need
typing.overload? (Outside stubs, that is.) Given that a short-term solution
is already possible using a stub, I'm not sure that adding another
short-term solution is worth it, if we don't intend to keep it around.

-- 
--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 484 -- proposal to allow @overload in non-stub files

[Laura Creighton]

All these overloads makes the code hard to read.
The whole idea of 'i have to know which decorator
got called  before the other one' is a smell that
you have too many decorators.

This whole idea reeks 'i can be very, very clever here'.

Laura
___
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 484 -- proposal to allow @overload in non-stub files

[Nick Coghlan]

On 22 October 2015 at 19:51, Guido van Rossum  wrote:
> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith  wrote:
>> What would it Foo.__getitem__.__annotations__ contain in this situation?
>> It'd unfortunately be an empty dict if implemented in the most trivial
>> fashion rather than a dict containing your Unions... Do we care?
>
> Initially it would indeed be {}. Once we have a true multi-dispatch PEP we
> can iterate, both on how to spell it (perhaps the final __getitem__ needs an
> @overload as well) and on what happens in the annotations (or at least, what
> typing.get_type_hints() returns).

Just ensuring I understand the problem with using a third @overload in
the spelling from the start:

class Foo(Generic[T]):
@overload
def __getitem__(self, i: int) -> T: ...

@overload
def __getitem__(self, s: slice) -> Foo[T]: ...

@overload
def __getitem__(self, x):


If we did this, the implied annotation on the last method would be:

@overload
def __getitem__(self, x: Any) -> Any:


which gets the signature wrong - this isn't an Any:Any mapping, it's a sequence.

Leaving the "@overload" out thus indicates that the definition is an
implementation of the preceding type based dispatch declaration,
rather than a new overload.

Assuming a future multidispatch implementation used
"functools.multidispatch" as the decorator (to complement the existing
functools.singledispatch) rather than "typing.overload", this seems
like a reasonable short term solution to me.

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 484 -- proposal to allow @overload in non-stub files

[Guido van Rossum]

On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith  wrote:

>
>
> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum  wrote:
>
>> Well the whole point is not to have to figure out how to implement that
>> right now.
>>
>> On Wed, Oct 21, 2015 at 6:45 PM, Random832 
>> wrote:
>>
>>> Guido van Rossum  writes:
>>> > The proposal is to allow this to be written as follows in
>>> > implementation (non-stub) modules:
>>> >
>>> > class Foo(Generic[T]):
>>> > @overload
>>> > def __getitem__(self, i: int) -> T: ...
>>> > @overload
>>> > def __getitem__(self, s: slice) -> Foo[T]: ...
>>> > def __getitem__(self, x):
>>> > 
>>> >
>>> > The actual implementation must be last, so at run time it will
>>> > override the definition.
>>>
>>
> I think this *could* be fine. It is certainly readable. And, as is
> already possible in .pyi files, more accurately expressive than the Union
> which doesn't imply a parameter type to return value type relationship.
>

Right, which is how this got started.


> What would it Foo.__getitem__.__annotations__ contain in this situation?
> It'd unfortunately be an empty dict if implemented in the most trivial
> fashion rather than a dict containing your Unions... Do we care?
>

Initially it would indeed be {}. Once we have a true multi-dispatch PEP we
can iterate, both on how to spell it (perhaps the final __getitem__ needs
an @overload as well) and on what happens in the annotations (or at least,
what typing.get_type_hints() returns).

We could also wait for a multidispatch PEP to land -- but I'm worried that
we'll be waiting past 3.6.

Then again I don't see how true multidispatch would be able to deal with
the syntax proposed here -- you need some kind of decorator on the fallback
implementation.


> Note that it would also slow down module import time as the code for each
> of the earlier ... definitions with annotation structures and @overload
> decorator calls is executed, needlessly creating objects and structures
> that are immediately discarded upon each subsequent definition.
>

Yes, but I don't think this is going to make a noticeable difference.


-- 
--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 484 -- proposal to allow @overload in non-stub files

[Paul Moore]

On 22 October 2015 at 10:21, Gregory P. Smith  wrote:
> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum  wrote:
>>
>> Well the whole point is not to have to figure out how to implement that
>> right now.
>>
>> On Wed, Oct 21, 2015 at 6:45 PM, Random832  wrote:
>>>
>>> Guido van Rossum  writes:
>>> > The proposal is to allow this to be written as follows in
>>> > implementation (non-stub) modules:
>>> >
>>> > class Foo(Generic[T]):
>>> > @overload
>>> > def __getitem__(self, i: int) -> T: ...
>>> > @overload
>>> > def __getitem__(self, s: slice) -> Foo[T]: ...
>>> > def __getitem__(self, x):
>>> > 
>>> >
>>> > The actual implementation must be last, so at run time it will
>>> > override the definition.
>
>
> I think this could be fine. It is certainly readable. And, as is already
> possible in .pyi files, more accurately expressive than the Union which
> doesn't imply a parameter type to return value type relationship.
>
> What would it Foo.__getitem__.__annotations__ contain in this situation?
> It'd unfortunately be an empty dict if implemented in the most trivial
> fashion rather than a dict containing your Unions... Do we care?
>
> Note that it would also slow down module import time as the code for each of
> the earlier ... definitions with annotation structures and @overload
> decorator calls is executed, needlessly creating objects and structures that
> are immediately discarded upon each subsequent definition.

Is the idea that in future the "..." dummy declarations could be
replaced by specialised implementations for the particular type
combinations? If not, is there a risk that by grabbing the @overload
decorator just for typing we lose the option of using the natural
spelling for an actual multi-dspatch implementation?

Paul
___
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 484 -- proposal to allow @overload in non-stub files

[Gregory P. Smith]

On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum  wrote:

> Well the whole point is not to have to figure out how to implement that
> right now.
>
> On Wed, Oct 21, 2015 at 6:45 PM, Random832  wrote:
>
>> Guido van Rossum  writes:
>> > The proposal is to allow this to be written as follows in
>> > implementation (non-stub) modules:
>> >
>> > class Foo(Generic[T]):
>> > @overload
>> > def __getitem__(self, i: int) -> T: ...
>> > @overload
>> > def __getitem__(self, s: slice) -> Foo[T]: ...
>> > def __getitem__(self, x):
>> > 
>> >
>> > The actual implementation must be last, so at run time it will
>> > override the definition.
>>
>
I think this *could* be fine. It is certainly readable. And, as is already
possible in .pyi files, more accurately expressive than the Union which
doesn't imply a parameter type to return value type relationship.

What would it Foo.__getitem__.__annotations__ contain in this situation?
It'd unfortunately be an empty dict if implemented in the most trivial
fashion rather than a dict containing your Unions... Do we care?

Note that it would also slow down module import time as the code for each
of the earlier ... definitions with annotation structures and @overload
decorator calls is executed, needlessly creating objects and structures
that are immediately discarded upon each subsequent definition.

-gps


>
>> How about this to allow overloads to have actual implementations?
>>
>> @overloaded
>> def __getitem__(self, x):
>> 
>>
>> @overloaded returns a function which will check the types against the
>> overloads (or anyway any overloads that have actual implementations),
>> call them returning the result if applicable, otherwise call the
>> original function.
>>
>> Some magic with help() would improve usability, too - it could print all
>> the overloads and their docstrings.  Maybe even @overload('__getitem__')
>> def __get_int(self, i: int), to make it so order doesn't matter.
>>
>> That just leaves the question of how's this all gonna work with
>> subclasses.
>>
>> ___
>> 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/guido%40python.org
>>
>
>
>
> --
> --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/greg%40krypto.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 484 -- proposal to allow @overload in non-stub files

[Random832]

Guido van Rossum  writes:
> The proposal is to allow this to be written as follows in
> implementation (non-stub) modules:
>
> class Foo(Generic[T]):
> @overload
> def __getitem__(self, i: int) -> T: ...
> @overload
> def __getitem__(self, s: slice) -> Foo[T]: ...
> def __getitem__(self, x):
> 
>
> The actual implementation must be last, so at run time it will
> override the definition.

How about this to allow overloads to have actual implementations?

@overloaded
def __getitem__(self, x):


@overloaded returns a function which will check the types against the
overloads (or anyway any overloads that have actual implementations),
call them returning the result if applicable, otherwise call the
original function.

Some magic with help() would improve usability, too - it could print all
the overloads and their docstrings.  Maybe even @overload('__getitem__')
def __get_int(self, i: int), to make it so order doesn't matter.

That just leaves the question of how's this all gonna work with
subclasses.

___
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 484 -- proposal to allow @overload in non-stub files

[Guido van Rossum]

Well the whole point is not to have to figure out how to implement that
right now.

On Wed, Oct 21, 2015 at 6:45 PM, Random832  wrote:

> Guido van Rossum  writes:
> > The proposal is to allow this to be written as follows in
> > implementation (non-stub) modules:
> >
> > class Foo(Generic[T]):
> > @overload
> > def __getitem__(self, i: int) -> T: ...
> > @overload
> > def __getitem__(self, s: slice) -> Foo[T]: ...
> > def __getitem__(self, x):
> > 
> >
> > The actual implementation must be last, so at run time it will
> > override the definition.
>
> How about this to allow overloads to have actual implementations?
>
> @overloaded
> def __getitem__(self, x):
> 
>
> @overloaded returns a function which will check the types against the
> overloads (or anyway any overloads that have actual implementations),
> call them returning the result if applicable, otherwise call the
> original function.
>
> Some magic with help() would improve usability, too - it could print all
> the overloads and their docstrings.  Maybe even @overload('__getitem__')
> def __get_int(self, i: int), to make it so order doesn't matter.
>
> That just leaves the question of how's this all gonna work with
> subclasses.
>
> ___
> 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/guido%40python.org
>



-- 
--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 484

[Benjamin Peterson]

On Mon, May 25, 2015, at 04:02, Mike Kozulya wrote:
 May I suggest to eliminate - in function definition?
 
  def function1 (variable1: variable1_type, variable2: 
 variable2_type): function1_type
  return str2function1_type(str(variable1)+str('
  ')+str(variable2))
 
 OR
 
  def function1: function1_type (variable1: variable1_type, 
 variable2: variable2_type):
  return str2function1_type(str(variable1)+str('
  ')+str(variable2))
 
 both look a bit simpler than
 
  def function1 (variable1: variable1_type, variable2: 
 variable2_type) - function1_type:
  return str2function1_type(str(variable1)+str('
  ')+str(variable2))
 
 Are there any convincing reasons to introduce syntactic sugar?

That's simply preexisting function annotation syntax.
https://www.python.org/dev/peps/pep-3107/

It's not invented by the type hinting pep.
___
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 484 (Type Hints) announcement

[Alex Grönholm]

Would you mind updating the typing package on PyPI now to contain 
something useful? Thanks.


22.05.2015, 23:51, Mark Shannon kirjoitti:

Hello all,

I am pleased to announce that I am accepting PEP 484 (Type Hints).

Given the proximity of the beta release I thought I would get this 
announcement out now, even though there are some (very) minor details 
to iron out.
(If you want to know the details, it's all at 
https://github.com/ambv/typehinting)



I hope that PEP 484 will be a benefit to all users of Python.
I think the proposed annotation semantics and accompanying module are 
technically sound and I hope that they are socially acceptable to the 
Python community.


I have long been aware that as well as a powerful, sophisticated and 
production quality language, Python is also used by many casual 
programmers, and as a language to introduce children to programming.
I also realise that this PEP does not look like it will be any help to 
the part-time programmer or beginner. However, I am convinced that it 
will enable significant improvements to IDEs (hopefully including 
IDLE), static checkers and other tools.

These tools will then help us all, beginners included.

This PEP has been a huge amount of work, involving a lot of people.
So thank you to everyone involved. If I were to list names I would 
inevitably miss someone out. You know who you are.


Finally, if you are worried that this will make Python ugly and turn 
it into some sort of inferior Java, then I share you concerns, but I 
would like to remind you of another potential ugliness; operator 
overloading.


C++, Perl and Haskell have operator overloading and it gets abused 
something rotten to produce concise (a.k.a. line noise) code.
Python also has operator overloading and it is used sensibly, as it 
should be. Why?

It's a cultural issue; readability matters.

Python is your language, please use type-hints responsibly :)

Cheers,
Mark.
___
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/alex.gronholm%40nextday.fi


___
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 484 (Type Hints) announcement

[Guido van Rossum]

Thanks Mark!
On May 22, 2015 1:52 PM, Mark Shannon m...@hotpy.org wrote:

 Hello all,

 I am pleased to announce that I am accepting PEP 484 (Type Hints).

 Given the proximity of the beta release I thought I would get this
 announcement out now, even though there are some (very) minor details to
 iron out.
 (If you want to know the details, it's all at
 https://github.com/ambv/typehinting)


 I hope that PEP 484 will be a benefit to all users of Python.
 I think the proposed annotation semantics and accompanying module are
 technically sound and I hope that they are socially acceptable to the
 Python community.

 I have long been aware that as well as a powerful, sophisticated and
 production quality language, Python is also used by many casual
 programmers, and as a language to introduce children to programming.
 I also realise that this PEP does not look like it will be any help to the
 part-time programmer or beginner. However, I am convinced that it will
 enable significant improvements to IDEs (hopefully including IDLE), static
 checkers and other tools.
 These tools will then help us all, beginners included.

 This PEP has been a huge amount of work, involving a lot of people.
 So thank you to everyone involved. If I were to list names I would
 inevitably miss someone out. You know who you are.

 Finally, if you are worried that this will make Python ugly and turn it
 into some sort of inferior Java, then I share you concerns, but I would
 like to remind you of another potential ugliness; operator overloading.

 C++, Perl and Haskell have operator overloading and it gets abused
 something rotten to produce concise (a.k.a. line noise) code.
 Python also has operator overloading and it is used sensibly, as it should
 be. Why?
 It's a cultural issue; readability matters.

 Python is your language, please use type-hints responsibly :)

 Cheers,
 Mark.
 ___
 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/guido%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 484 (Type Hints) -- penultimate(?) draft

[Guido van Rossum]

Another draft. This is mostly a bunch of clarifications and minor edits,
but it also removes the four version/platform constants (PY2, PY3, WINDOWS,
POSIX) in favor of asking type checkers to recognize common version checks
e.g. using sys.version_info or sys.platform. This time I think the new
version *will* appear on python.org. For more frequent updates, watch
https://github.com/ambv/typehinting .

Also note: I'm probably going to commit the typing.py module to the CPython
repo optimistically, while Mark is still pondering his decision. Off-list
he's told me he's happy with the PEP. I have to make some changes to
typing.py to satisfy him; I won't have time to work on those this
afternoon, and I don't want to miss (or hold up) Larry's tagging of the
tree for beta 1. So a few things may end up as bugs in the issue tracker (
https://github.com/ambv/typehinting/issues) and I'll rectify those before
beta 2.

--Guido

PEP: 484
Title: Type Hints
Version: $Revision$
Last-Modified: $Date$
Author: Guido van Rossum gu...@python.org, Jukka Lehtosalo 
jukka.lehtos...@iki.fi, Łukasz Langa luk...@langa.pl
BDFL-Delegate: Mark Shannon
Discussions-To: Python-Dev python-dev@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29-Sep-2014
Post-History: 16-Jan-2015,20-Mar-2015,17-Apr-2015,20-May-2015,22-May-2015
Resolution:


Abstract


PEP 3107 introduced syntax for function annotations, but the semantics
were deliberately left undefined.  There has now been enough 3rd party
usage for static type analysis that the community would benefit from
a standard vocabulary and baseline tools within the standard library.

This PEP introduces a provisional module to provide these standard
definitions and tools, along with some conventions for situations
where annotations are not available.

Note that this PEP still explicitly does NOT prevent other uses of
annotations, nor does it require (or forbid) any particular processing
of annotations, even when they conform to this specification.  It
simply enables better coordination, as PEP 333 did for web frameworks.

For example, here is a simple function whose argument and return type
are declared in the annotations::

  def greeting(name: str) - str:
  return 'Hello ' + name

While these annotations are available at runtime through the usual
``__annotations__`` attribute, *no type checking happens at runtime*.
Instead, the proposal assumes the existence of a separate off-line
type checker which users can run over their source code voluntarily.
Essentially, such a type checker acts as a very powerful linter.
(While it would of course be possible for individual users to employ
a similar checker at run time for Design By Contract enforcement or
JIT optimization, those tools are not yet as mature.)

The proposal is strongly inspired by mypy [mypy]_.  For example, the
type sequence of integers can be written as ``Sequence[int]``.  The
square brackets mean that no new syntax needs to be added to the
language.  The example here uses a custom type ``Sequence``, imported
from a pure-Python module ``typing``.  The ``Sequence[int]`` notation
works at runtime by implementing ``__getitem__()`` in the metaclass
(but its significance is primarily to an offline type checker).

The type system supports unions, generic types, and a special type
named ``Any`` which is consistent with (i.e. assignable to and from) all
types.  This latter feature is taken from the idea of gradual typing.
Gradual typing and the full type system are explained in PEP 483.

Other approaches from which we have borrowed or to which ours can be
compared and contrasted are described in PEP 482.


Rationale and Goals
===

PEP 3107 added support for arbitrary annotations on parts of a
function definition.  Although no meaning was assigned to annotations
then, there has always been an implicit goal to use them for type
hinting [gvr-artima]_, which is listed as the first possible use case
in said PEP.

This PEP aims to provide a standard syntax for type annotations,
opening up Python code to easier static analysis and refactoring,
potential runtime type checking, and (perhaps, in some contexts)
code generation utilizing type information.

Of these goals, static analysis is the most important.  This includes
support for off-line type checkers such as mypy, as well as providing
a standard notation that can be used by IDEs for code completion and
refactoring.

Non-goals
-

While the proposed typing module will contain some building blocks for
runtime type checking -- in particular a useful ``isinstance()``
implementation -- third party packages would have to be developed to
implement specific runtime type checking functionality, for example
using decorators or metaclasses.  Using type hints for performance
optimizations is left as an exercise for the reader.

It should also be emphasized that **Python will remain a dynamically
typed language, and the authors have no desire to 

Re: [Python-Dev] PEP 484 wishes

[Guido van Rossum]

On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm alex.gronh...@nextday.fi
wrote:



 18.05.2015, 02:50, Guido van Rossum kirjoitti:

  On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm alex.gronh...@nextday.fi
 wrote:

  Looking at PEP 484, I came up with two use cases that I felt were not
 catered for:

1. Specifying that a parameter should be a subclass of another
(example: Type[dict] would match dict or OrderedDict; plain Type would
equal type from builtins)


  I don't understand. What is Type? Can you work this out in a full
 example? This code is already okay:

  def foo(a: dict):
 ...

  foo(OrderedDict())

 This code is passing an *instance* of OrderedDict. But how can I specify
 that foo() accepts a *subclass* of dict, and not an instance thereof?

 A full example:

 def foo(a: Type[dict]):
 ...

 foo(dict)  # ok
 foo(OrderedDict)  # ok
 foo({'x': 1})  # error


You want the argument to be a *class*. We currently don't support that
beyond using 'type' as the annotation. We may get to this in a future
version; it is relatively uncommon. As to what notation to use, perhaps it
would make more sense to use Class and Class[dict], since in the world of
PEP 484, a class is a concrete thing that you can instantiate, while a type
is an abstraction used to describe the possible values of a
variable/argument/etc.

Also, what you gave is still not a full example, since you don't show what
you are going to do with that type. Not every class can be easily
instantiated (without knowing the specific signature). So if you were
planning to instantiate it, perhaps you should use Callable[..., dict] as
the type instead. (The ellipsis is not yet supported by mypy --
https://github.com/JukkaL/mypy/issues/393 -- but it is allowed by the PEP.)





1. Specifying that a callable should take at least the specified
arguments but would not be limited to them: Callable[[str, int, ...], Any]

 Case #2 works already (Callable[[str, int], Any] if the unspecified
 arguments are optional, but not if they're mandatory. Any thoughts?

 For #2 we explicitly debated this and found that there aren't use cases
 known that are strong enough to need additional flexibility in the args of
 a callable. (How is the code calling the callable going to know what
 arguments are safe to pass?) If there really is a need we can address in a
 future revision.

 Consider a framework where a request handler always takes a Request object
 as its first argument, but the rest of the arguments could be anything. If
 you want to only allow registration of such callables, you could do this:

 def calculate_sum(request: Request, *values):
return sum(values)

 def register_request_handler(handler: Callable[[Request, ...], Any]):
...


Hm... Yeah, you'd be stuck with using Callable[..., Any] for now. Maybe in
a future version of the PEP. (We can't boil the ocean of typing in one 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 484 wishes

[Alex Grönholm]

18.05.2015, 02:50, Guido van Rossum kirjoitti:
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm 
alex.gronh...@nextday.fi mailto:alex.gronh...@nextday.fi wrote:


Looking at PEP 484, I came up with two use cases that I felt were
not catered for:

 1. Specifying that a parameter should be a subclass of another
(example: Type[dict] would match dict or OrderedDict; plain
Type would equal type from builtins)


I don't understand. What is Type? Can you work this out in a full 
example? This code is already okay:


def foo(a: dict):
...

foo(OrderedDict())
This code is passing an /instance/ of OrderedDict. But how can I specify 
that foo() accepts a /subclass/ of dict, and not an instance thereof?


A full example:

def foo(a: Type[dict]):
...

foo(dict)  # ok
foo(OrderedDict)  # ok
foo({'x': 1})  # error


 1. Specifying that a callable should take at least the specified
arguments but would not be limited to them: Callable[[str,
int, ...], Any]

Case #2 works already (Callable[[str, int], Any] if the
unspecified arguments are optional, but not if they're mandatory.
Any thoughts?

For #2 we explicitly debated this and found that there aren't use 
cases known that are strong enough to need additional flexibility in 
the args of a callable. (How is the code calling the callable going to 
know what arguments are safe to pass?) If there really is a need we 
can address in a future revision.
Consider a framework where a request handler always takes a Request 
object as its first argument, but the rest of the arguments could be 
anything. If you want to only allow registration of such callables, you 
could do this:


def calculate_sum(request: Request, *values):
   return sum(values)

def register_request_handler(handler: Callable[[Request, ...], Any]):
   ...

--
--Guido van Rossum (python.org/~guido http://python.org/%7Eguido)


___
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 484 wishes

[Alex Grönholm]

18.05.2015, 18:05, Guido van Rossum kirjoitti:
On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm 
alex.gronh...@nextday.fi mailto:alex.gronh...@nextday.fi wrote:




18.05.2015, 02:50, Guido van Rossum kirjoitti:

On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
alex.gronh...@nextday.fi mailto:alex.gronh...@nextday.fi wrote:

Looking at PEP 484, I came up with two use cases that I felt
were not catered for:

 1. Specifying that a parameter should be a subclass of
another (example: Type[dict] would match dict or
OrderedDict; plain Type would equal type from builtins)


I don't understand. What is Type? Can you work this out in a
full example? This code is already okay:

def foo(a: dict):
...

foo(OrderedDict())

This code is passing an /instance/ of OrderedDict. But how can I
specify that foo() accepts a /subclass/ of dict, and not an
instance thereof?

A full example:

def foo(a: Type[dict]):
...

foo(dict)  # ok
foo(OrderedDict)  # ok
foo({'x': 1})  # error


You want the argument to be a *class*. We currently don't support that 
beyond using 'type' as the annotation. We may get to this in a future 
version; it is relatively uncommon. As to what notation to use, 
perhaps it would make more sense to use Class and Class[dict], since 
in the world of PEP 484, a class is a concrete thing that you can 
instantiate, while a type is an abstraction used to describe the 
possible values of a variable/argument/etc.


Also, what you gave is still not a full example, since you don't show 
what you are going to do with that type. Not every class can be easily 
instantiated (without knowing the specific signature). So if you were 
planning to instantiate it, perhaps you should use Callable[..., dict] 
as the type instead. (The ellipsis is not yet supported by mypy -- 
https://github.com/JukkaL/mypy/issues/393 -- but it is allowed by the 
PEP.)

Here's one example, straight from the code of my new framework:

@typechecked
def register_extension_type(ext_type: str, extension_class: type, 
replace: bool=False):


Adds a new extension type that can be used with a dictionary based 
configuration.


:param ext_type: the extension type identifier
:param extension_class: a class that implements IExtension
:param replace: ``True`` to replace an existing type


assert_subclass('extension_class', extension_class, IExtension)
if ext_type in extension_types and not replace:
raise ValueError('Extension type {} already 
exists'.format(ext_type))


extension_types[ext_type] = extension_class

I would like to declare the second argument as extension_class: 
Type[IExtension] (or Class[IExtension], doesn't matter to me). 
Likewise, the type hint for extension_types should be Dict[str, 
Type[IExtension]].



 1. Specifying that a callable should take at least the
specified arguments but would not be limited to them:
Callable[[str, int, ...], Any]

Case #2 works already (Callable[[str, int], Any] if the
unspecified arguments are optional, but not if they're
mandatory. Any thoughts?

For #2 we explicitly debated this and found that there aren't use
cases known that are strong enough to need additional flexibility
in the args of a callable. (How is the code calling the callable
going to know what arguments are safe to pass?) If there really
is a need we can address in a future revision.

Consider a framework where a request handler always takes a
Request object as its first argument, but the rest of the
arguments could be anything. If you want to only allow
registration of such callables, you could do this:

def calculate_sum(request: Request, *values):
   return sum(values)

def register_request_handler(handler: Callable[[Request, ...], Any]):
   ...


Hm... Yeah, you'd be stuck with using Callable[..., Any] for now. 
Maybe in a future version of the PEP. (We can't boil the ocean of 
typing in one PEP. :-)


--
--Guido van Rossum (python.org/~guido http://python.org/%7Eguido)


___
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 484 wishes

[Guido van Rossum]

Can you add your example to the issue?
https://github.com/ambv/typehinting/issues/107

We're trying to finish up PEP 484 in the next few days (wait for an
announcement :-) and we just don't have time for every use case; but over
the course of 3.5 we will be adding features that are considered useful,
and we'll keep the issue open to remind us of it. Until then you'll have to
use plain type as the annotation (still better than Any. :-)

On Mon, May 18, 2015 at 11:01 AM, Alex Grönholm alex.gronh...@nextday.fi
wrote:



 18.05.2015, 18:05, Guido van Rossum kirjoitti:

  On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm alex.gronh...@nextday.fi
  wrote:



 18.05.2015, 02:50, Guido van Rossum kirjoitti:

  On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm alex.gronh...@nextday.fi
  wrote:

  Looking at PEP 484, I came up with two use cases that I felt were not
 catered for:

1. Specifying that a parameter should be a subclass of another
(example: Type[dict] would match dict or OrderedDict; plain Type would
equal type from builtins)


  I don't understand. What is Type? Can you work this out in a full
 example? This code is already okay:

  def foo(a: dict):
 ...

  foo(OrderedDict())

  This code is passing an *instance* of OrderedDict. But how can I
 specify that foo() accepts a *subclass* of dict, and not an instance
 thereof?

 A full example:

 def foo(a: Type[dict]):
 ...

   foo(dict)  # ok
 foo(OrderedDict)  # ok
 foo({'x': 1})  # error


  You want the argument to be a *class*. We currently don't support that
 beyond using 'type' as the annotation. We may get to this in a future
 version; it is relatively uncommon. As to what notation to use, perhaps it
 would make more sense to use Class and Class[dict], since in the world of
 PEP 484, a class is a concrete thing that you can instantiate, while a type
 is an abstraction used to describe the possible values of a
 variable/argument/etc.

 Also, what you gave is still not a full example, since you don't show what
 you are going to do with that type. Not every class can be easily
 instantiated (without knowing the specific signature). So if you were
 planning to instantiate it, perhaps you should use Callable[..., dict] as
 the type instead. (The ellipsis is not yet supported by mypy --
 https://github.com/JukkaL/mypy/issues/393 -- but it is allowed by the
 PEP.)

 Here's one example, straight from the code of my new framework:

  @typechecked
 def register_extension_type(ext_type: str, extension_class: type, replace:
 bool=False):
  
 Adds a new extension type that can be used with a dictionary based
 configuration.

 :param ext_type: the extension type identifier
 :param extension_class: a class that implements IExtension
 :param replace: ``True`` to replace an existing type
 

 assert_subclass('extension_class', extension_class, IExtension)
 if ext_type in extension_types and not replace:
 raise ValueError('Extension type {} already
 exists'.format(ext_type))

 extension_types[ext_type] = extension_class

 I would like to declare the second argument as extension_class:
 Type[IExtension] (or Class[IExtension], doesn't matter to me). Likewise,
 the type hint for extension_types should be Dict[str, Type[IExtension]].






1. Specifying that a callable should take at least the specified
arguments but would not be limited to them: Callable[[str, int, ...], 
 Any]

 Case #2 works already (Callable[[str, int], Any] if the unspecified
 arguments are optional, but not if they're mandatory. Any thoughts?

 For #2 we explicitly debated this and found that there aren't use cases
 known that are strong enough to need additional flexibility in the args of
 a callable. (How is the code calling the callable going to know what
 arguments are safe to pass?) If there really is a need we can address in a
 future revision.

  Consider a framework where a request handler always takes a Request
 object as its first argument, but the rest of the arguments could be
 anything. If you want to only allow registration of such callables, you
 could do this:

 def calculate_sum(request: Request, *values):
return sum(values)

 def register_request_handler(handler: Callable[[Request, ...], Any]):
...


  Hm... Yeah, you'd be stuck with using Callable[..., Any] for now. Maybe
 in a future version of the PEP. (We can't boil the ocean of typing in one
 PEP. :-)

 --
 --Guido van Rossum (python.org/~guido http://python.org/%7Eguido)



 ___
 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/guido%40python.org




-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 

Re: [Python-Dev] PEP 484 wishes

[Guido van Rossum]

On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm alex.gronh...@nextday.fi
wrote:

  Looking at PEP 484, I came up with two use cases that I felt were not
 catered for:

1. Specifying that a parameter should be a subclass of another
(example: Type[dict] would match dict or OrderedDict; plain Type would
equal type from builtins)


I don't understand. What is Type? Can you work this out in a full
example? This code is already okay:

def foo(a: dict):
...

foo(OrderedDict())



1. Specifying that a callable should take at least the specified
arguments but would not be limited to them: Callable[[str, int, ...], Any]

 Case #2 works already (Callable[[str, int], Any] if the unspecified
 arguments are optional, but not if they're mandatory. Any thoughts?

For #2 we explicitly debated this and found that there aren't use cases
known that are strong enough to need additional flexibility in the args of
a callable. (How is the code calling the callable going to know what
arguments are safe to pass?) If there really is a need we can address in a
future revision.

-- 
--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 484 (Type Hints) -- the next draft is here

[Guido van Rossum]

That's a good question. We *could* make it so that you can subclass
Generator and instantiate the instances; or we could even make it do some
structural type checking. (Please file a pull request or issue for this at
github.com/ambv/typehinting .) But perhaps we should also change asyncio?
What check are you talking about?

On Fri, Apr 17, 2015 at 10:35 PM, Stefan Behnel stefan...@behnel.de wrote:

 Guido van Rossum schrieb am 17.04.2015 um 23:58:
  The ``typing`` module defines the ``Generator`` type for return values
  of generator functions. It is a subtype of ``Iterable`` and it has
  additional type variables for the type accepted by the ``send()``
  method and the return type of the generator:
 
  * Generator, used as ``Generator[yield_type, send_type, return_type]``

 Is this meant to accept only Python generators, or any kind of object that
 implements the coroutine protocol? I'm asking because asyncio currently
 suffers from an annoying type check here, so I'd like to avoid that this
 problem keeps popping up again in other places.

 Stefan


 ___
 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/guido%40python.org




-- 
--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 484 (Type Hints) -- the next draft is here

[Stefan Behnel]

Guido van Rossum schrieb am 18.04.2015 um 18:38:
 That's a good question. We *could* make it so that you can subclass
 Generator and instantiate the instances; or we could even make it do some
 structural type checking. (Please file a pull request or issue for this at
 github.com/ambv/typehinting .)

Done:

https://github.com/ambv/typehinting/issues/89


 But perhaps we should also change asyncio?
 What check are you talking about?

https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169

The current (3.5alpha) check in iscoroutine() is an instance check against
_COROUTINE_TYPES, which contains types.GeneratorType and another wrapper
type. It excludes objects that implement the coroutine protocol without
being Python generators, e.g. Cython compiled generators, which mimic the
Python generator interface without having byte code in them (meaning, they
are not C-level compatible with Python generators). I'm sure the same
applies to other compilers like Numba or Nuitka. Supporting asyncio in
recent Python releases thus means monkey patching _COROUTINE_TYPES and
adding another type to it. Given that it's not a public interface, this
seems a bit fragile.

It also seems that this code only appeared somewhere in the 3.4.x release
series. Older versions were even worse and did a straight call to
inspect.isgenerator() in their iscoroutine() function, which means that the
whole function needed to be replaced and wrapped (and even that didn't fix
all places where inspect was used).

I guess I should open a (CPython) ticket for this topic, too...

Stefan


___
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 484 (Type Hints) -- the next draft is here

[Guido van Rossum]

(Also, there might be some interaction with PEP 492 here, which also tweaks
the definition of generators.)

On Sat, Apr 18, 2015 at 9:38 AM, Guido van Rossum gu...@python.org wrote:

 That's a good question. We *could* make it so that you can subclass
 Generator and instantiate the instances; or we could even make it do some
 structural type checking. (Please file a pull request or issue for this at
 github.com/ambv/typehinting .) But perhaps we should also change asyncio?
 What check are you talking about?

 On Fri, Apr 17, 2015 at 10:35 PM, Stefan Behnel stefan...@behnel.de
 wrote:

 Guido van Rossum schrieb am 17.04.2015 um 23:58:
  The ``typing`` module defines the ``Generator`` type for return values
  of generator functions. It is a subtype of ``Iterable`` and it has
  additional type variables for the type accepted by the ``send()``
  method and the return type of the generator:
 
  * Generator, used as ``Generator[yield_type, send_type, return_type]``

 Is this meant to accept only Python generators, or any kind of object that
 implements the coroutine protocol? I'm asking because asyncio currently
 suffers from an annoying type check here, so I'd like to avoid that this
 problem keeps popping up again in other places.

 Stefan


 ___
 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/guido%40python.org




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




-- 
--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 484 (Type Hints) -- the next draft is here

[Stefan Behnel]

Stefan Behnel schrieb am 18.04.2015 um 19:39:
 Guido van Rossum schrieb am 18.04.2015 um 18:38:
 That's a good question. We *could* make it so that you can subclass
 Generator and instantiate the instances; or we could even make it do some
 structural type checking. (Please file a pull request or issue for this at
 github.com/ambv/typehinting .)
 
 But perhaps we should also change asyncio?
 What check are you talking about?
 
 https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169
 
 The current (3.5alpha) check in iscoroutine() is an instance check against
 _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper
 type. It excludes objects that implement the coroutine protocol without
 being Python generators, e.g. Cython compiled generators, which mimic the
 Python generator interface without having byte code in them (meaning, they
 are not C-level compatible with Python generators). I'm sure the same
 applies to other compilers like Numba or Nuitka. Supporting asyncio in
 recent Python releases thus means monkey patching _COROUTINE_TYPES and
 adding another type to it. Given that it's not a public interface, this
 seems a bit fragile.
 
 It also seems that this code only appeared somewhere in the 3.4.x release
 series. Older versions were even worse and did a straight call to
 inspect.isgenerator() in their iscoroutine() function, which means that the
 whole function needed to be replaced and wrapped (and even that didn't fix
 all places where inspect was used).

Hmm, looks like I remembered it incorrectly. Monkey patching the inspect
module is required in both versions as it's being used in more places,
especially the coroutine wrappers. I'll see how I can get it working with
Cython and then open tickets for it.

Stefan


___
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 484 (Type Hints) -- the next draft is here

[Guido van Rossum]

Maybe the thing to fix then is the inspect module, not asyncio? Anyway, let
is know via tickets.

On Sat, Apr 18, 2015 at 12:29 PM, Stefan Behnel stefan...@behnel.de wrote:

 Stefan Behnel schrieb am 18.04.2015 um 19:39:
  Guido van Rossum schrieb am 18.04.2015 um 18:38:
  That's a good question. We *could* make it so that you can subclass
  Generator and instantiate the instances; or we could even make it do
 some
  structural type checking. (Please file a pull request or issue for this
 at
  github.com/ambv/typehinting .)
 
  But perhaps we should also change asyncio?
  What check are you talking about?
 
 
 https://hg.python.org/cpython/file/439517000aa2/Lib/asyncio/coroutines.py#l169
 
  The current (3.5alpha) check in iscoroutine() is an instance check
 against
  _COROUTINE_TYPES, which contains types.GeneratorType and another wrapper
  type. It excludes objects that implement the coroutine protocol without
  being Python generators, e.g. Cython compiled generators, which mimic the
  Python generator interface without having byte code in them (meaning,
 they
  are not C-level compatible with Python generators). I'm sure the same
  applies to other compilers like Numba or Nuitka. Supporting asyncio in
  recent Python releases thus means monkey patching _COROUTINE_TYPES and
  adding another type to it. Given that it's not a public interface, this
  seems a bit fragile.
 
  It also seems that this code only appeared somewhere in the 3.4.x release
  series. Older versions were even worse and did a straight call to
  inspect.isgenerator() in their iscoroutine() function, which means that
 the
  whole function needed to be replaced and wrapped (and even that didn't
 fix
  all places where inspect was used).

 Hmm, looks like I remembered it incorrectly. Monkey patching the inspect
 module is required in both versions as it's being used in more places,
 especially the coroutine wrappers. I'll see how I can get it working with
 Cython and then open tickets for it.

 Stefan


 ___
 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/guido%40python.org




-- 
--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 484 (Type Hints) -- the next draft is here

[Stefan Behnel]

Guido van Rossum schrieb am 17.04.2015 um 23:58:
 The ``typing`` module defines the ``Generator`` type for return values
 of generator functions. It is a subtype of ``Iterable`` and it has
 additional type variables for the type accepted by the ``send()``
 method and the return type of the generator:
 
 * Generator, used as ``Generator[yield_type, send_type, return_type]``

Is this meant to accept only Python generators, or any kind of object that
implements the coroutine protocol? I'm asking because asyncio currently
suffers from an annoying type check here, so I'd like to avoid that this
problem keeps popping up again in other places.

Stefan


___
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 484 syntax: NONONONONONONO!

[Mark Lawrence]

On 01/02/2015 10:13, Benjamin wrote:

The proposed syntax is abominable. It's the opposite of readable.



I have no views on the subject as I won't be using it, but there is no 
need to shout to get your point across.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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 484 syntax: NONONONONONONO!

[Chris Angelico]

On Sun, Feb 1, 2015 at 9:13 PM, Benjamin dei...@gmail.com wrote:
 I much prefer the idea of a 'where' keyword to denote typing, as discussed
 http://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html,
 but I think a refinement of their idea would prove even better:

 def retry(callback, timeout, retries=None) where
 callback is Callable[AnyArgs, Any[int, None]],
 timeout is Any[int, None],
 retries is in [int, None], # 'is in' construct is more readable,
 dunno about complexity
 return is None:
 pass

Massively verbose, and requires duplication of your argument names. If
you're going to have the args all listed down below, the first line is
redundant; all you need to do is incorporate the =None default into
the lower part, and you can drop the first line altogether.

def retry(
callback: Callable[AnyArgs, Optional[int]],
timeout: Optional[int],
retries:Optional[int]=None
) - None:
pass

Indent that any way you like. Apart from taking advantage of
Optional[] rather than explicitly Anying with None, that's a direct
translation from your code to actual annotations. Advantage: It works
in current code, as long as you backport those names (which typing.py
will do). I'm stating the parameter names exactly once each, I'm
laying it out pretty much the same way you had it, and there's no need
to add any more syntax beyond PEP 3107.

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