Re: [Python-Dev] PEP 484

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

Re: [Python-Dev] PEP 484

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

Re: [Python-Dev] PEP 484

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

[Python-Dev] PEP 484

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

Re: [Python-Dev] PEP 484: difference between tuple and ()

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

[Python-Dev] PEP 484: difference between tuple and ()

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/

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

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): ... | > >

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

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

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

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),

Re: [Python-Dev] PEP 484 update: allow @overload in regular module files

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

Re: [Python-Dev] PEP 484: updates to Python 2.7 signature syntax

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

Re: [Python-Dev] PEP 484: a "NewType" constructor

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.

[Python-Dev] PEP 484: a "NewType" constructor

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 =

[Python-Dev] PEP 484 update: add Type[T]

There's a more fundamental PEP 484 update that I'd like to add. The discussion is in https://github.com/python/typing/issues/107. Currently we don't have a way to talk about arguments and variables whose type is itself a type or class. The only annotation you can use for this is 'type' which says

Re: [Python-Dev] PEP 484: updates to Python 2.7 signature syntax

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,

[Python-Dev] PEP 484 update: allow @overload in regular module files

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

Re: [Python-Dev] PEP 484: updates to Python 2.7 signature syntax

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

[Python-Dev] PEP 484: updates to Python 2.7 signature syntax

PEP 484 was already updated to support signatures as type comments in Python 2.7. I'd like to add two more variations to this spec, both of which have already come up through users. First, https://github.com/python/typing/issues/188. This augments the format of signature type comments to allow

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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 ___

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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

[Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

PEP 484 (Type Hinting) currently disallows @overload outside stub files. The hope was that a PEP for multi-dispatch would emerge, but that's been slow coming. Meanwhile, over in https://github.com/ambv/typehinting/issues/72 a proposal has emerged to allow @overload in regular modules, as long as

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

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)

[Python-Dev] PEP 484

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:

Re: [Python-Dev] PEP 484

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

Re: [Python-Dev] PEP 484 (Type Hints) announcement

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

[Python-Dev] PEP 484 (Type Hints) announcement

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

Re: [Python-Dev] PEP 484 (Type Hints) announcement

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

[Python-Dev] PEP 484 (Type Hints) announcement

Mark Shannon writes: Hello all, I am pleased to announce that I am accepting PEP 484 (Type Hints). Congratulations to all concerned! Python is your language, please use type-hints responsibly :) +1 QOTW (not to mention ROTFLMAO) ___

Re: [Python-Dev] PEP 484 (Type Hints) -- penultimate(?) draft

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

[Python-Dev] PEP 484 (Type Hints) -- penultimate(?) draft

I'm happy to present a much updated PEP 484 for your review. It will (hopefully) appear on python.org within the next hour. I'm also working on an implementation ( https://github.com/ambv/typehinting/tree/master/prototyping) which I hope will be good enough to include in beta 1, assuming the

Re: [Python-Dev] PEP 484 wishes

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

[Python-Dev] PEP 484 wishes

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

Re: [Python-Dev] PEP 484 wishes

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

Re: [Python-Dev] PEP 484 wishes

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

Re: [Python-Dev] PEP 484 wishes

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

Re: [Python-Dev] PEP 484 wishes

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

[Python-Dev] PEP 484 wishes

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) 2. Specifying that a callable should take at

Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here

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

Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here

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

Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here

(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

Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here

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

Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here

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.

[Python-Dev] PEP 484 (Type Hints) -- the next draft is here

The PEP 484 authors (Jukka, Łukasz and I) have a new draft ready. This time we're posting to python-dev. While we don't have all details totally sorted out, it's a lot closer. We have a BDFL-Delegate (Mark Shannon), and we've worked out a variety of issues at PyCon. Our hope remains that we'll

Re: [Python-Dev] PEP 484 (Type Hints) -- the next draft is here

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

[Python-Dev] PEP 484 syntax: NONONONONONONO!

The proposed syntax is abominable. It's the opposite of readable. The function annotation syntax is ugly, but potentially useful for things like documentation. While it may very well have been created with the idea of type-checking, actually using it for such quickly turns into an unreadable

Re: [Python-Dev] PEP 484 syntax: NONONONONONONO!

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

Re: [Python-Dev] PEP 484 syntax: NONONONONONONO!

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

[Python-Dev] PEP 484

Please don't clutter executable code. We need to read it without growing an headache. Much better is: def myfunction(arg1, arg2): Normal docstring... @hint: (str, int) - bool return True While I agree type hinting, for the purposes of static analysis,