[issue42128] Structural Pattern Matching (PEP 634)
Change by Daniel Moisset : -- pull_requests: +23450 pull_request: https://github.com/python/cpython/pull/24664 ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42128] Structural Pattern Matching (PEP 634)
Daniel Moisset added the comment: Thanks @xtreak, I'll make some changes in these sections too. The docs are coming along well, there's still some refinement to do in the compound statements section (it's there, but looks to big), I'll submit a draft PR during the weekend so interested people can review -- ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42128] Structural Pattern Matching (PEP 634)
Daniel Moisset added the comment: Note: I will NOT write something for "What's New in 3.10" seeing that's in progress -- ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42128] Structural Pattern Matching (PEP 634)
Daniel Moisset added the comment: Fyi, I'm looking into the documentation. I think I can have something basic for the middle of this week, so it should be ok for March 1st. -- ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42128] Structural Pattern Matching (PEP 634)
Daniel Moisset added the comment: @Ken: I've invited you to the repo. For tracking the WIP, https://github.com/dmoisset/cpython/tree/patma-docs Do you want to see if you can base the reference/compound_stmts.rst changes in PEP 634? I'll try to fit a variant of the Appendix A of PEP 636 into the tutorial and make something up for the reference/lexical_analysis.rst (which needs a section of soft keywords which are not in the PEP trilogy. Perhaps I can rescue something from PEP 622) -- ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42128] Structural Pattern Matching (PEP 634)
Daniel Moisset added the comment: Hey Ken, I was about to take on this myself, but I wouldn't mind a bit of help. Your list seems ok, I would add to it a section about PM in the python tutorial (which was explicitly mentioned in the SC acceptance notice). Regarding the grammar, I believe that one is autogenerated from the parser, so it's likely that no changes are required there. Correct me if I'm wrong here. I'll set up a branch in github and add you as a collaborator so we can prepare a PR. I'll base the branch of Brandt's implementation PR. If you give me your github id I can add you as collaborator so we can work there. -- nosy: +Daniel Moisset ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33270] tags for anonymous code objects should be interned
New submission from Daniel Moisset <dmois...@machinalis.com>: In compile.c, some strings are created to be used as name of anonymous code objects: "", "", "", "", "" and "". Only the first two of those are interned (created with PyUnicode_InternFromString ), the rest are created with "PyUnicode_FromString". Even if they use a static variable to avoid creating multiple instances, not interning results in multiple copies when code objects are marshaled into pyc files and reloaded (one copy per module). Always using PyUnicode_InternFromString should be more consistent, and slightly more efficient -- components: Interpreter Core messages: 315232 nosy: Daniel Moisset priority: normal severity: normal status: open title: tags for anonymous code objects should be interned ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28386] Improve documentation about tzinfo.dst(None)
New submission from Daniel Moisset: The datetime module documentation[1] describes the tzinfo.dst method with a single "dt" argument without being too explicit about possible values for it. The implication is that dt should be a datetime object, but the implementation of time.dst() [2] actually calls tz.dst(None) (where tz is an instance of some tzinfo subclass), so this should clarify that None is an allowed value. Also, some of the examples given below in the same document (like LocalTimezone, GMT1, GMT2) actually have a related bug (it doesn't handle a None value correctly). So running >>> ... # copy the example from the documentation >>> t = time(tzinfo=LocalTimeZone()) >>> t.dst() crashes with an AttributeError: 'NoneType' object has no attribute 'year'. This kind of bugs have propagated to some other projects already [2]. Some of the other examples (like USTimeZone) seem to be OK What I think would be desirable here is: * A clarification on https://docs.python.org/3.5/library/datetime.html#datetime.tzinfo.dst indicating that dt is either a datetime or a None, in which situations it can be None, and what is the method supposed to return in this case. * Fixes in the code examples that reflect this I would offer a patch, but I'm not quite sure of what the desired behaviour is so I wouldn't know what to document :) [1] https://docs.python.org/3.5/library/datetime.html [2] https://github.com/python/cpython/blob/master/Modules/_datetimemodule.c#L3623 [3] https://github.com/django/django/blob/1.10.2/django/utils/timezone.py#L111 -- assignee: docs@python components: Documentation messages: 278256 nosy: Daniel Moisset, docs@python priority: normal severity: normal status: open title: Improve documentation about tzinfo.dst(None) ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28386> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27501] Add typing.py class describing a PEP 3118 buffer object
Daniel Moisset added the comment: As a description of the idea I'm attaching a rough patch with an implementation. Some tests fail because of the following: 1) I didn't find a good place to register the Buffer ABC for mmap.mmap, and array.mmap; the modeules themselves are C extensions (and it's possible but weird to register the ABC from the C API); I could import those in typing.py but then I'd make typing depend from mmap and array which also feels wrong; so I didn't do that and the related tests that I added fail. 2) I had a similar situation with io.BytesIO. In that case there's a python module and I'm doing the abc.register there, but now io imports typing, and the test_site fails because many new modules (typing and its dependencies) are imported on startup. The alternative is to make typing depend on io (in this case it could be a reasonable idea) After these, I'm feeling that typing.py may not be the best place for this (but given that collections.abc isn't either, I'm not sure where's the right place) -- keywords: +patch Added file: http://bugs.python.org/file43719/buffer.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27501] Add typing.py class describing a PEP 3118 buffer object
Daniel Moisset added the comment: OK. Just to give an obvious example of a place where this would be useful for annotations is in the argument for the memoryview() builtin (currently declared with "# TODO arg can be any obj supporting the buffer protocol" in the standard library typesheds) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27501] Create a collections.abc class that describes PEP 3118 buffer
Daniel Moisset added the comment: Thanks for the feedback. Just for the context, I opened this issue also based on this email: http://permalink.gmane.org/gmane.comp.python.devel/156411 Probably there are two different discussions to have here: 1) Is the "Buffer" a useful ABC to have even if there's no python API involved? My thoughts (that come from working with typing and PEP 484 and numpy) are "yes" 2) Where is the right place to put it? I suggested collections.abc after seeing the thread I linked, although I wouldn't mind if this was in typing.py or somewhere else. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27501] Create a collections.abc class that describes PEP 3118 buffer
Changes by Daniel Moisset <dmois...@machinalis.com>: -- components: +Library (Lib) type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27501] Create a collections.abc class that describes PEP 3118 buffer
New submission from Daniel Moisset: The buffer protocol is a low level C protocol, but even if it doesn't expose a specific python API, it's currently not possible to say "this object implements the buffer protocol" in Python This might be useful for some applications, including PEP-484 typing hints. It would be useful to have a collections.abc.Buffer which already registers the types that already support the protocol (bytes, strings, array.array, struct, mmap, ctype arrays/pointers, etc) -- messages: 270261 nosy: Daniel Moisset priority: normal severity: normal status: open title: Create a collections.abc class that describes PEP 3118 buffer ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
