[issue31184] Fix data descriptor detection in inspect.getattr_static

David Halter added the comment: This is not a duplicate. It is related to https://bugs.python.org/issue26103, because __get__ is not required anymore for an object to be a data descriptor. The current code on master (of inspect.getattr_static) still thinks a descriptor has both __get__ and

[issue41506] Inclusion or documentation of extended with syntax in 3.9

David Halter added the comment: I second this. I just see people complaining about this not working in a lot of tools. This is really not necessary for a feature that should not be used anyway and puts work onto the greater Python ecosystem for no good reason

[issue41506] Inclusion or documentation of extended with syntax in 3.9

Change by David Halter : -- nosy: +davidhalter ___ Python tracker <https://bugs.python.org/issue41506> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

David Halter added the comment: @gvanrossum > Does parso have to be pure Python? If not, we could generate C code like we > do for CPython's parser. I would rather write the parser either in C or Rust. So no, parso does not need to be pure Python. > Now, that doesn't w

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

David Halter added the comment: Parso's incremental parser is a terrible idea. It also works and is pretty fast, but the design is pretty terrible (it took me a lot of fuzzing to make sure that it works decently well). The basic problem is that it's reusing nodes in a mutable way.

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

David Halter added the comment: I'm the maintainer of parso. Feel free to addd me to the Nosy List if we have these discussions in the future. Parso is indeed a lib2to3 fork with error recovery, round tripping and incremental parsing as its features. Most pgen2 code has been rewritten

[issue33754] f-strings should be part of the Grammar

David Halter added the comment: As I wrote before, I'm not trying to change anything about the f-string behavior. It is a refactoring. If anyone wants to change the behavior, I feel like they should probably write a PEP anyway. I personally don't like that f-strings get parse

[issue33754] f-strings should be part of the Grammar

New submission from David Halter : Currently f-strings are a bit of a hack. They certainly work very well for users, but they are implemented in ast.c and therefore not part of the Python grammar and the tokenizer. I want to change this. I wrote an alternative implementation of f-strings in

[issue31184] Fix data descriptor detection in inspect.getattr_static

New submission from David Halter: inspect.getattr_static is currently not identifying data descriptors the right way. Data descriptors are defined by having a __get__ attribute and at least one of the __set__ and __delete__ attributes. Implementation detail: Both __delete__ and __get__ set

[issue22221] ast.literal_eval confused by coding declarations

Changes by David Halter : -- nosy: +davidhalter ___ Python tracker <http://bugs.python.org/issue1> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12855] linebreak sequences should be better documented

David Halter added the comment: I would vote for the inclusion of that patch. I just stumbled over this. -- nosy: +davidhalter ___ Python tracker <http://bugs.python.org/issue12

[issue19002] ``dir`` function does not work correctly with classes.

New submission from David Halter: I recently stumbled over the ``dir`` function not working correctly with classes. This means that ``dir(object)`` won't list ``object.__bases__`` or ``object.__subclasses`` (and many other useful methods). I think that we should change that. The C fun

[issue16791] itertools.chain.from_iterable doesn't stop

New submission from David Halter: The following lines run infinitely: b = [1] import itertools b += itertools.chain.from_iterable([c] for c in b) In my opinion this is a bug. Clearly you could say that this is an implementation detail. But afaik this is not documented and very misleading

[issue15846] literal_eval raises SystemError instead of SyntaxError, because of illegal escape sequence

New submission from David Halter: Hi! I'm the developer of Jedi: https://github.com/davidhalter/jedi, which is an auto-completion library. I try to support Python 2.5-3.2. The bug just appears in Python 3.2. Parsing string literals with literal_eval works normally without a problem, bu