[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 = 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)
___
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
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
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 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 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] Counting references to Py_None
Hi, On 20 March 2016 at 18:10, Brett Cannon wrote: > And if we didn't keep its count accurately it would eventually hit > zero and constantly have its dealloc function checked for. I think the idea is really consistency. If we wanted to avoid all "Py_INCREF(Py_None);", it would be possible: we could let the refcount of None decrement to zero, at which point its deallocator is called; but this deallocator can simply bumps the refcount to a large value again. The deallocator would end up being called very rarely. A bientôt, Armin. ___ 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] Counting references to Py_None
Brett Cannon ]
>> And if we didn't keep its count accurately it would eventually hit
>> zero and constantly have its dealloc function checked for.
[Armin Rigo]
[> I think the idea is really consistency. If we wanted to avoid all
> "Py_INCREF(Py_None);", it would be possible: we could let the refcount
> of None decrement to zero, at which point its deallocator is called;
> but this deallocator can simply bumps the refcount to a large value
> again. The deallocator would end up being called very rarely.
It could, but it does something else now ;-) I've seen this trigger,
from C code that had no idea it was playing with None, but just had
general refcounting errors. So this does serve a debugging purpose,
although rarely:
static void
none_dealloc(PyObject* ignore)
{
/* This should never get called, but we also don't want to SEGV if
* we accidentally decref None out of existence.
*/
Py_FatalError("deallocating None");
}
(that's in object.c)
___
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] Counting references to Py_None
On Mon, Mar 21, 2016 at 5:56 PM, Tim Peters wrote: > I've seen this trigger, > from C code that had no idea it was playing with None, but just had > general refcounting errors. So this does serve a debugging purpose, > although rarely > You probably have a better refcounting sense that I do, but I see this quite often when I hack C code and I find this behavior quite useful when debugging. ___ 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
