[Python-Dev] Review for bpo-30140: fix binop dispatch for subclasses
Hi python-dev, It's been over a month without any activity and over a week since my ping, and I'm still waiting for a review on my pull request: https://bugs.python.org/issue30140 https://github.com/python/cpython/pull/1325 I would greatly appreciate if someone has time to take a look. This is my first pull request to CPython. Thanks, Stephan ___ 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] Accepting PEP 560 -- Core support for typing module and generic types
On Thu, Dec 14, 2017 at 4:29 PM Yury Selivanov wrote: > On Thu, Dec 14, 2017 at 7:03 PM, Guido van Rossum > wrote: > My motivation to add the slot wasn't the performance: it's just not > possible to have a class-level __getitem__ on types defined in C. The > only way is to define a base class in C and then extend it in > pure-Python. This isn't too hard usually, though. This could potentially make it much more complicated to adding typing support to NumPy. numpy.ndarray is defined in 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] Is static typing still optional?
On Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi wrote: > For me, the three options for "don't care" have a bit different meaning: > > * typing.Any: this class is supposed to be used with static type checkers, > but this field is too dynamic > * ... (ellipsis): this class may or may not be used with static type > checkers, use the inferred type in the latter case > * "field docstring": this class should not be used with static type > checkers > > Assuming this, the second option would be the "real" "don't care". If this > makes sense, > then we can go the way proposed in > https://github.com/python/typing/issues/276 and make ellipsis semantics > "official" in PEP 484. > (pending Guido's approval) > I am a little nervous about using "..." for inferred types, because it could potentially cause confusion with other uses of ellipsis in typing. Ellipsis already has a special meaning for Tuple, so an annotation like MyClass[int, ...] could mean either a tuple subclass with integer elements or a two argument generic type where the second type is inferred. Actually, it's ambiguous even for Tuple. Ellipsis could also make a lot of sense for typing multi-dimensional arrays similar to how it's used in indexing to denote "any number of dimensions." Again, the semantics for "..." might defer from "an inferred size." > ___ 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
[Python-Dev] Request for review: binary op dispatch rules for subclasses
Over a year ago, I made a pull request ( https://github.com/python/cpython/pull/1325) to fix a long-standing issue with how Python handles dispatch for arithmetic binary operations involving subclasses (https://bugs.python.org/issue30140). I pinged the bug several times, but I'm still waiting for a review, which would be greatly appreciated! Best, Stephan ___ 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
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
I just wanted to thank Matthew & Pradeep for writing this PEP and for clarifications to the broader context of PEP 646 for array typing in https://github.com/python/peps/pull/1904. As someone who is heavily involved in the Python numerical computing community (e.g., NumPy, JAX, Xarray), but who is not so familiar with the details of Python's type system, it is reassuring to see that a broad range of use-cases related to type checking of named axes & shapes have been considered, and could build upon the infrastructure in this PEP. Type checking for shapes is something the NumPy community is very interested in -- there are more thumbs up on the relevant issue on NumPy's GitHub than any others (https://github.com/numpy/numpy/issues/7370) and we recently added a "typing" module that is under active development. It will certainly require experimentation to figure out the best ways to use type checking for ndarrays, but this PEP looks like an excellent foundation for such work. On Sat, Mar 20, 2021 at 9:52 AM Matthew Rahtz via Python-Dev < python-dev@python.org> wrote: > Hi everyone, > > We've got to the stage now with PEP 646 that we're feeling pretty happy > with it. So far though we've mainly been workshopping it in typing-sig, so > as PEP 1 requires we're asking for some feedback here too before submitting > it to the steering council. > > If you have time over the next couple of weeks, please take a look at the > current draft and let us know your thoughts: > https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of > sections are out of date; https://github.com/python/peps/pull/1880 > clarifies which grammar changes would be required, now that PEP 637 has > been rejected. We also have a second PR in progress at > https://github.com/python/peps/pull/1881 clarifying some of the > motivation.) > > Thanks! > Matthew and Pradeep > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/5GWS2GGVJ4PAMOWM6YVVKZVMR5BRFRGV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UDM7Y6HLHQBKXQEBIBD5ZLB5XNPDZDXV/ Code of Conduct: http://python.org/psf/codeofconduct/
