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
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 codifie
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 a
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/que
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
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__ attr
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 anythin
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 happ
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 Le
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
>
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
> 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 re
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
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
>
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
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.
Readabi
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 de
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 alrea
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 tha
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 you
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 w
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
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::
> >
> >
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/
__
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): ... |
>
> Th
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
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
> wou
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
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 wr
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 arg
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-
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 tractabl
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 im
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 conta
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 w
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:
>>>
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
>> >
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]):
> >
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):
>
>
>
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))
>
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
announceme
Thanks Mark!
On May 22, 2015 1:52 PM, "Mark Shannon" 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
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
vers
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 usefu
18.05.2015, 18:05, Guido van Rossum kirjoitti:
On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm
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
mailto:alex.gronh...@nextday.fi>> wrote:
On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm
wrote:
>
>
> 18.05.2015, 02:50, Guido van Rossum kirjoitti:
>
> On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
> wrote:
>
>> Looking at PEP 484, I came up with two use cases that I felt were not
>> catered for:
>>
>>1. Specifying that a param
18.05.2015, 02:50, Guido van Rossum kirjoitti:
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
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 anothe
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
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
>eq
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 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* mak
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 reque
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/typehinti
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 che
(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 wrote:
> That's a good question. We *could* make it so that you can subclass
> Generator and instantiate the instances; or we could even ma
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 gene
On Sun, Feb 1, 2015 at 9:13 PM, Benjamin 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, timeou
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
56 matches
Mail list logo
