Jukka and Ivan will be visiting the Bay Area in September and we'd like to organize another meetup. Here are the proposed (tentative) logistics:
Date: Friday, Sept. 20
Time: 1pm - 5pm
Location: Facebook in Menlo Park (building and room TBD)
So far Ivan, Jukka, Guido, Rebecca, Martin (?), and myself have committed to attending. I'm also volunteering the rest of the Pyre team.
Please let us know in advance if you plan on attending so that we can book an adequately sized room.
Also now's the time to think about topics to discuss or presentations you want to give.
When PCs or laptops based on the Intel microprocessor run a Microsoft Windows operating system, we generically refer to such architectures as Wintel. People who work in such environments by supporting users and resolving their issues are Wintel Engineers.
These engineers configure and install all server hardware, including the Windows OS and products procured from third-parties, onto the systems. They build, configure, assess, and recommend hardware and software.
They should possess above average analytical and fixing skills. Engineers own and run an issue with minimal intervention from others ensuring all relevant parties are informed on time.
More info : https://www.fieldengineer.com/skills/wintel-engineer
I'm a core developer of Hypothesis, and largely responsible for our `from_type()` strategy. As the name suggests, it takes a type and returns an object that can generate instances of it, including for things in the `typing` module that aren't really types at runtime. So far, so good!
For obvious reasons, I'm looking to support TypedDict too, but I've run into a snag: I can't see any way to distinguish between optional and required keys at runtime! It's not actually *incorrect* to treat all keys as required, but we'll miss test cases that could have exposed real bugs.
Consider the following cases:
a: int # a is required
class B(A, total=False):
b: bool # a is required, b is optional
c: str # a is required, b is optional, c is required again
The PEP is clear about the semantics, and this is obvious enough when reading the code. At runtime the __annotations__ attribute of each class gives us the set of allowed keys and the type of each corresponding value, but we have a problem:
- C has __total__==True, but b is not actually required.
- B has __total__==False, but a *is* required.
- I can't see any way to get the parent classes of a TypedDict class!
The _TypedDictMeta metaclass updates the attributes, but leaves no record of the parent type - at runtime A, B, and C all appear to inherit directly from dict.
Is there a way to directly determine which keys are required and which are optional at runtime? If not, is there a way to determine the parent class(es) of a TypedDict? If not, can we please add one - preferably the former - for 3.8.1?
If there's an agreed design I'd be happy to implement it - as a concrete suggestion, I'd add two frozensets, __required_keys__ and __optional_keys__. Obvious, useful, orthogonal to current attributes, and easy to fall back to treating all keys as required.
I'm a student at Harvard studying CS right now. For my thesis, I'm really
interested in adding types to numpy as well as general capabilities for
extending the Python system with "dependent" types. I want to add the
feature of statically determining the alignment of array dimensions.
Let me know how I can get started on this project!
after being told in issue 38756 of the python bug tracker that PEP 585 will
add generic typing to many standard collections/containers I looked at
which types will get generic versions.
I noticed that collections from weakref were not included (WeakDictionary,
WeakKeyDictionary and WeakValueDictionary should probably automatically be
generic as they extend _collections_abc.MutableMapping but WeakSet does not.
Would it be possible to clarify that WeakDictionaries or subclasses in
general will become generic but more importantly I think it should be worth
considering add WeakSet to the PEP
I would like to hear your thoughts on this topic...
Whelp, this one bit me again today, so I finally decided to come forward with a concrete proposal: how to handle the fact that strings are themselves sequences of length-one strings.
I know that this has been discussed at some length, but most of the other proposals I've found are a bit too complicated for the relative simplicity of the problem.
My proposal is to add a public `Chr` type to the `typing` module, defined as `Chr = NewType("Chr", str)`. That's it. typeshed will be modified to type `str` as a `Sequence[Chr]`, rather than a `Sequence[str]`. Other parts of typeshed (`builtins.ord`, `builtins.chr`, `os.sep`, and `os.pathsep` are a couple that come to mind) can be updated as well with either the new `Chr`, or something like `TypeVar("Str", Chr, str)`.
The beauty of this is proposal is that type checkers will be able to properly check the `str`/`Chr` relationship without any additional special handling (beyond that already required for `str` types). While they have the option of being stricter (for example, issuing warnings when a `Chr` is used as a `str`), the type system does not require it, because it mirrors the reality that at runtime, a `Chr` is just a special-case of `str`.
I know it's not perfect, but it certainly seems better than the status quo. I just thought that I would start here to gather feedback, and see if anybody is interested in co-sponsoring a more formal proposal.
Can the typing-sig list owners lock the list down to not allow
non-subscribers to post?
and if those spambots were subscribed, require moderation for the first
couple posts from new members?
(I don't know what options mailman3 provides or who owns the list - it
won't tell me :)
There's a PR for PEP 484 in the peps repo that has quite a bit of
discussion in it:
The basic idea is to have a way to declare the type of a decorated function
*after it's been decorated*, to serve as either documentation or a type
hint in the case the decorator is untyped.
This is the full text of the paragraph that's being proposed as an addition
to PEP 484:
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: ...
def session(url: str) -> Iterator[DatabaseSession]:
s = DatabaseSession(url)
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``.
This has been a "Work in Progress" PR since 2017. There are 40 comments but
the last one is over two years old. I'm not sure that anybody really cares
that much about this problem any more. Maybe we should just close it?
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
Working at Microsoft means I get asked semi-regularly about why the Python community has not set up a [DefinitelyTyped](https://definitelytyped.org/) equivalent, and I have historically said 🤷♂️. I have now been asked this enough times that I'm asking all of you if there's a specific reason beyond lack of time and resources so I can give a more informed answer next time this question comes up? I found https://github.com/python/typeshed/issues/2491 which didn't suggest any particular issue with the idea other than time and resources.
Or I guess another way to phrase the question is if someone created a site like DefinitelyTyped where things were highly automated and anyone could provide type stubs for any project on PyPI -- and maybe even automated initial type stubs -- would people be interested in such a thing or see any reasons why people would balk at it or not use it?