[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Big +1 from me. I've been looking forward to having None-aware operators in Python as I find them a very neat language addition. For me personally the main advantage of having maybe-dot (?.) operator is the ability to express certain logic in a much clearer way, for example: > class User(DBModel): >phone: str | None > > class Publisher(DBModel): > owner: ForeignKey[User] | None > > class Book(DBModel) > publisher: ForeignKey[Publisher] | None Imagine wanting to get the phone number of the person that published a certain book from the database. In this situation, with maybe-dot operator I can write: > phone_number = book.publisher?.owner?.phone Getting None value could mean that the book has not been published yet (no publisher relation), owner does not exist or does not have a phone number associated with it. Either way it doesn't matter because the only thing that we wanted to retrieve is the phone number and not the whole context of why it has a certain value and not the other. Personally I find this syntax much more readable than other, "more explicit" expressions like: > phone_number = book.publisher.owner.phone if (book.publisher is not None and book.publisher.owner is not None) else None Best regards, On Thu, Oct 14, 2021 at 7:37 PM Doug Swarin wrote: > Hello, > > I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/) > since it was first proposed for Python 3.8. It's been deferred for some > time and I'm interested in seeing it in Python 3.11, but I know there were > also a number of objections which resulted in it being deferred (including > by one of the original authors, Mr. Dower). I did email both Mr. Dower and > Mr. Haase and they graciously gave me their permission to bring it up on > this list for discussion and hopefully final pronouncement one way or the > other. > > I personally believe that the PEP will result in a significant reduction > in boilerplate code, and it is substantially similar to the same operators > now found in a number of other languages, especially C# and JavaScript ( > https://wikipedia.org/wiki/Null_coalescing_operator and > https://wikipedia.org/wiki/Safe_navigation_operator). > > I believe strong and valid arguments can be made about the use of None > being a fundamental flaw in some types of coding (and that adding > additional support for it to the language will increase the use of None in > this way), but I also believe there are many use cases in programming where > it is by far the simplest way to express various semantics, and the fact > exists that None is already used extensively in large quantities of code, > and further that there is already a great deal of code written to > constantly test against None and break out of a statement without throwing > an error. > > I also understand the argument that especially the maybe-dot (?.) and > maybe-subscript (?[) operators can decrease readability of code and also > believe these are valid arguments against it. While I believe the existence > and use of these operators in other languages definitely helps the case > that these can be used and understood successfully, I think it is entirely > valid to either consider other syntax (though I prefer the chosen syntax of > PEP 505), or even to reduce PEP 505 to having only the coalesce operator > (??) and the maybe-assign operator (??=). > > Separately, I have implemented a pure-Python solution for PEP505 (which is > definitely rather beta) which might help test the waters for a final > implementation in CPython (though the CPython implementation would of > course be much more efficient). It can be found at > https://pypi.org/project/pep505/ > > Thanks, > Doug > ___ > 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/XZZIV42XGG3EIHRBBCCTTCFPWWSOT7MX/ > 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/XP6V7TKZJYHYUIGH7QWMD6TX3XUBKWEW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Thank you very much for this exhaustive explanation and example. I really like it and agree with you that the implementation provided by your example is much more well designed. The problem I have with it is that I feel like it assumes that I have a way to introduce such changes when writing the API, whereas I was talking more about using existing solutions. The provided example was based on common situations encountered when writing the code in Django. It may be that I'm using this tool not to its full potential, but it seems like many of your points were about bad API design, not the actual maybe-dot operator. Such operator would make it much easier to work with those frameworks that do not allow for more readable/well thought-out solutions. I'm thinking about it as a syntactic sugar that can speed things up (and even make it more readable) in a situation where there is no time and/or budget to come up with a better architecture (like e.g. the one you have provided). The reality is that usually from the business perspective nobody wants a well designed system, only the functioning one. It may be that I misunderstood your response and didn't provide a valid answer - please let me know in that case. Best regards On Tue, Oct 19, 2021 at 1:29 AM Steve Dower wrote: > Okay, I'll let myself get sucked into responding ONE TIME, but only > because you gave me such a nice API to work with :) > > On 10/18/2021 9:11 PM, Piotr Waszkiewicz wrote: > > > class User(DBModel): > > >phone: str | None > > > > > > class Publisher(DBModel): > > > owner: ForeignKey[User] | None > > > > > > class Book(DBModel) > > > publisher: ForeignKey[Publisher] | None > > > > > > Imagine wanting to get the phone number of the person that published a > > certain book from the database. > > In this situation, with maybe-dot operator I can write: > > > > > phone_number = book.publisher?.owner?.phone > > Consider today, you wrote this as "book.publisher.owner.phone". You > would potentially get AttributeError, from any one of the elements - no > way to tell which, and no way to react. > > Generally, AttributeError indicates that you've provided a value to an > API which doesn't fit its pattern. In other words, it's an error about > the *type* rather than the value. > > But in this case, the (semantic, not implementation) *type* is known and > correct - it's a publisher! It just happens that the API designed it > such that when the *value* is unknown, the *type* no longer matches. > > This is PRECISELY the kind of (IMHO, bad) API design that None-aware > operators will encourage. > > > Consider an alternative: > > class ForeignKey: > ... > def __bool__(self): > return not self.is_dbnull > > def value(self): > if self.is_dbnull: > return self.Type.empty() # that is, DBModel.empty() > return self._value > > > class DBModel: > @classmethod > def empty(cls): > return cls(__secret_is_empty_flag=True) > > def __bool__(self): > return not self._is_empty > > def __getattr__(self, key): > if not self: > t = self._get_model_type(key) > return t.empty() if isinstance(t, DBModel) else None > ... > > class User(DBModel): > phone: str | None > > class Publisher(DBModel): > owner: ForeignKey[User] > > class Book(DBModel) > publisher: ForeignKey[Publisher] > > > Okay, so as the API implementer, I've had to do a tonne more work. > That's fine - *that's my job*. The user hasn't had to stick "| None" > everywhere (and when we eventually get around to allowing named > arguments in indexing then they could use "ForeignKey[User, > non_nullable=True]", but I guess for now that would be some subclass of > ForeignKey). > > But now here's the example again: > > > book.publisher.owner.phone > > If there is no publisher, it'll return None. If there is no owner, it'll > return None. If the owner has no phone number, it'll return None. > > BUT, if you misspell "owner", it will raise AttributeError, because you > referenced something that is not part of the *type*. And that error will > be raised EVERY time, not just in the cases where 'publisher' is > non-null. It takes away the random value-based errors we've come to love > from poorly coded web sites and makes them reliably based on the value's > type (and doesn't even require a type checker ;) ). > > Additionally, if you want to explicitly check wh
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Hi, On Wed, Oct 20, 2021 at 2:33 AM Michael Selik wrote: > In case it saves anyone a couple clicks: > https://www.python.org/dev/peps/pep-0463/ > > I also prefer more syntactic help with exceptions, rather than more syntax > emphasizing None's uniqueness. > Me too, but could you provide me an example where try-except approach is more readable when trying to chain attribute lookups (like in the database book-publisher-owner example I have provided before). > > None and its ilk often conflate too many qualities. For example, is it > missing because it doesn't exist, it never existed, or because we never > received a value, despite knowing it must exist? > I think that a code where those three qualities happen all at once is in fact a bad code design. But the truth is that None has been and will be used to denote each of those qualities when writing a code because of its ease of use in a normal workflow, where time constraints are tight. > The languages SAS and R support at least 27 varieties of NA, allowing > un-tagged, and tagged with the letters A-Z to help someone create > distinctions between different kinds of nothingness. IEEE-754 allows about > 16 million possible NaNs, which I believe was intended to allow floating > point instructions to pass error messages along. > > If the motivation for this operator is chained lookups, how about adding a > feature to the operator module, first? It seems natural to add a > keyword-only argument to `attrgetter`, and it's a lighter touch than > implementing a new operator. If use becomes widespread, that gives more > weight to PEP 505. > > def attrgetter(*attrs, none_aware=False) > > https://docs.python.org/3/library/operator.html#operator.attrgetter > > Apologies if attrgetter has already been discussed. I didn't see mention > of it in PEP 505. > I remember using inhouse solution like this at a certain workplace - a method accepting list of string arguments and an object, returning the value being the result of chained attribute access. And it worked all right. The problem I have with such approaches is that the name of the attrs are passed as strings. This makes it less practical in day-to-day situations when writing code. Automated class refactors, available in most of the IDEs also seem to not be able to support such field renames, whereas attribute lookup via `.` is properly detected. The same goes with context help available in most IDEs - you'll get no useful information when writing a string (IDE does not know if you are trying to write a name of the class' field), whereas when using the dot this works. And it'll probably be implemented for maybe-dot operator in no time looking at other languages' support. > ___ > 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/R5NO5H5BCEIGEUCLPRE7WW5AEG5MRX3Q/ > 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/7YUEB6KNXARSN6ULNULF7S7NTWJ73PW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Hi, On Wed, Oct 20, 2021 at 5:44 PM Michael Selik wrote: > On Wed, Oct 20, 2021 at 1:16 AM Piotr Waszkiewicz > wrote: > >> On Wed, Oct 20, 2021 at 2:33 AM Michael Selik wrote: >> >>> In case it saves anyone a couple clicks: >>> https://www.python.org/dev/peps/pep-0463/ >>> I also prefer more syntactic help with exceptions, rather than more >>> syntax emphasizing None's uniqueness. >>> >> >> Me too, but could you provide me an example where try-except approach is >> more readable when trying to chain attribute lookups (like in the database >> book-publisher-owner example I have provided before). >> > > I'd echo the others' examples, taking inspiration from PEP 463. > Do you think about something along those lines? ``` phone = book.publisher.owner.phone except AttributeError: None ``` I don't mind this syntax but it would have to be supported by static type checkers and IDEs. And currently something like this is not: ``` try: phone = book.publisher.owner.phone except AttributeError: phone = None ``` mypy complains: ``` error: Item "None" of "Optional[Publisher]" has no attribute "owner" ``` > > >> If the motivation for this operator is chained lookups, how about adding >>> a feature to the operator module, first? It seems natural to add a >>> keyword-only argument to `attrgetter`, and it's a lighter touch than >>> implementing a new operator. If use becomes widespread, that gives more >>> weight to PEP 505. >>> >>> def attrgetter(*attrs, none_aware=False) >>> >>> https://docs.python.org/3/library/operator.html#operator.attrgetter >>> >> >> I remember using inhouse solution like this at a certain workplace - a >> method accepting list of string arguments and an object, returning the >> value being the result of chained attribute access. And it worked all >> right. The problem I have with such approaches is that the name of the >> attrs are passed as strings. >> > > I understand the preference for attributes over strings, but many of the > none-aware examples use keys and indices. If JSON is the main culprit for > deeply nested structures, then you're already using strings and not > attributes. Adding features to `operator` wouldn't preclude accepting PEP > 505, so why not get started with a less controversial change that provides > much of the value? > I have nothing against introducing such a new feature to the `operator` apart from this one problem mentioned before (using strings which are not properly detected by IDE), and I agree that could be a good start. I've seen chained-attributes-lookups solutions in quite a few places already and I think that there would actually be people benefiting from such addition. Although I must admit that personally I don't see many benefits of using strings for attribute lookups due to typing and IDE issues mentioned before. Even for JSON data, in my own projects I tend to write dataclasses wrapping parsed dict in order to benefit from IDE tooltips. > > If PEP 505 is accepted, it would need support in the `operator` module. > Might as well design that aspect of the implementation now. > I'm sorry but I don't know if I understand that sentence correctly. You mean we would have to add an "explicit" function that behaves like a maybe-dot operator? Is it actually a requirement when adding new operators? ___ 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/5K36MMO43TWKAXGGNM257MY356WLZ45M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
On Wed, Oct 20, 2021 at 9:39 PM Michael Selik wrote: > > > On Wed, Oct 20, 2021 at 9:18 AM Piotr Waszkiewicz > wrote: > >> Do you think about something along those lines? >> ``` >> phone = book.publisher.owner.phone except AttributeError: None >> ``` >> > > Yes, that seems reasonable. > Nice, I think I would also be able to get used to that notation. It's good to know that there are others supporting the PEP 463, maybe it'd be possible to propose it once again. > > >> I don't mind this syntax but it would have to be supported by static type >> checkers and IDEs. And currently something like this is not: >> ``` >> try: >> phone = book.publisher.owner.phone >> except AttributeError: >> phone = None >> ``` >> >> mypy complains: >> ``` >> error: Item "None" of "Optional[Publisher]" has no attribute "owner" >> ``` >> > > That sounds like a feature request for mypy. Would creating a new operator > make it easier to implement analysis of that situation would mypy? My guess > is not. Checking the AST to see if there's a try/except AttributeError > sounds comparable to checking for the use of a none-aware operator. I'm > completely ignorant of how mypy does its analysis, so that's just a wild > guess. > I'm not sure, just wanting to point out that the `AttributeError` syntax is not completely equivalent to the maybe-dot operator here. This example would actually hide a real AttributeError problem, e.g. if the `publisher` didn't have an owner field. So I guess there may be a need to introduce a new exception type, e.g. `NoneAttributeAccess` before mypy can safely allow any attribute access in such situation. > > If PEP 505 is accepted, it would need support in the `operator` module. >>> Might as well design that aspect of the implementation now. >>> >> >> I'm sorry but I don't know if I understand that sentence correctly. You >> mean we would have to add an "explicit" function that behaves like a >> maybe-dot operator? Is it actually a requirement when adding new operators? >> > > The documentation of the `operator` module says, "The operator module > exports a set of efficient functions corresponding to the intrinsic > operators of Python." It feels like there's an implicit "all" in there. The > table of correspondences looks exhaustive. I haven't noticed any exceptions. > > > https://docs.python.org/3/library/operator.html#mapping-operators-to-functions > Thank you very much, I wasn't aware of that module before. Will look into that. I don't want to prolong this conversation too much, as I feel like I get your point and agree with it to some (rather great) extent. That doesn't change my attitude towards this PEP 505 proposal though, as I feel that if the general consensus would be towards accepting this change it will bring some quality of life improvements in a usual day-to-day work, when dealing with not-so-ideal code. I'd be also interested in seeing PEP 463 being resurrected as it looks like there are some folks here interested in restarting the discussion about it. Thank you very much for the fruitful discussion and broadening my knowledge. ___ 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/IO5SREDWU3TJFEEXZ4ULD6D7PTGL4MNE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Hi Maarten, I like the suggestion but I'm not sure if the real problem with the PEP505 is the symbol/operator used. Reading through the whole discussion I'm under the impression that the idea of the None value being treated as an indicator of the missing attribute is what prevents this PEP from happening. Apart from that I'm all for it, (probably) regardless of the syntax (as long as it remains short). Best regards, Piotr On Thu, Sep 15, 2022 at 5:07 PM Maarten Nieber wrote: > Hi, I wanted to propose replacing ? with -> in the none aware syntax. This > makes the expression look like a chain, and I think that most people > intuitively can understand how the chain might get broken (and what would > happen in that case). For example: > > zipcode = person->.address->['zipcode'] > > I've proposed this alternative syntax on Doug's github project, and I > think he didn't like it so much (or at least, his co-contributor didn't > like it), but I still wanted to propose it here as well, because I do think > it's a good solution to the complaints that the ? operator looks cryptic. > > Best regards, > Maarten > ___ > 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/UNK66ZORXDNX22IDDFWJHDHVZGPBQETT/ > 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/5E732BVBR3CSZEDKXREVQULDBH2GUZHN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Hi Maarten, I'm sorry for the confusion - it was bad wording on my part. What I really meant was that the problem with the None-aware operator, and the reason why PEP505 has not been accepted for such a long time, is that there's no consensus regarding the need for it (and not necessarily the problem with the operator used to represent it - although this topic has also been raised). Take a look at the response by Steve Dower: https://mail.python.org/archives/list/python-dev@python.org/message/BRTRKGY6RLTHZJQ2US4LO7DYLSGXQ5GM/ Best regards, Piotr On Thu, Sep 15, 2022 at 6:54 PM Maarten Nieber wrote: > Hi Piotr, > > doesn't Doug's reply of 8:03 address this point? As he says, the > none-aware operator never gives you None when you ask for a missing > attribute (these cases always raise an exception). If we look at these two > alternatives > > phone1 = book.publisher?.owner.phone > phone2 = book.publisher.owner.phone if book.publisher else None > > then they behave exactly the same. If we would misspell "owner" then in > both versions we'd get the same AttributeError under the same conditions. > > Best, > Maarten > ___ > 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/KSKTJRNSQSBRYZRY6QQY7B3TZ5J4P2PD/ > 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/CNXITRMQL2ABVLTLH2RUB53IL3F37ZH6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Hi Philipp, That's a really good idea, and I'd really want to see it being implemented. Having said that, I wonder how many people would actually use this concept of "none-representing" objects. In my 10+ years of programming experience I've never seen anybody eager to use more complex structures or object representations of such concepts outside of an academic environment (and even there usually when dealing with personal or proof-of-concept projects). Nowadays I write mostly more business-oriented code, and I haven't been successful in finding a workplace where "business" wants to pay for preparing "good looking" code - they want a functioning one. That's where this whole concept of using none values is used the most (at least from my experience). So to reiterate: I think that the idea presented by Steve is very appealing, and I'd really like to work with such projects, but the reality is that it's really hard to stumble upon such. And I would really much *prefer to have none-aware operators that would make my life easier working with "real world" projects that rely too heavily on none values*, even if it's academically not correct. On Mon, Sep 19, 2022, 17:06 Philipp Burch wrote: > Hi all, > > I've only here found out that there is a discussion going on about those > none-aware operators and my first thought was "great, finally!". FWIW, > I'd be happy with the syntax suggestion in the PEP, since '?' looks > rather intuitive to me to mean something like "maybe". > > However, I then read the mentioned post of Steve Dower, with the final > summary: > > > So to summarise my core concern - allowing an API designer to "just > use None" is a cop out, and it lets people write lazy/bad APIs rather > than coming up with good ones. > > This is a very good point. In fact, I've never really thought about it > that way and of course he's totally right that "SomeType | None" (or > Optional[SomeType], which also somehow made me feel that this usage is > fairly intended) is not optimal, at least for user defined > types/classes. The problem is, that I never actually thought about his > suggested way. And I wouldn't be surprised if this holds for many other > people as well. > > Maybe it would be great to boldly mention these thoughts in the > documentation at an appropriate place. In my opinion, there are at least > the following good places where this would fit nicely: > > - The documentation of the dataclasses > (https://docs.python.org/3/library/dataclasses.html), since this is > probably the most common use case for the "| None" pattern. Going > further, the dataclasses functionality might even be extended to make it > simpler to generate such null-types (or however they are called), so > that it is no longer "a tonne more work". > > - Linters like pylint could emit a note when seeing the "| None" > pattern, linking to the explanation about why it is possibly not the > best way to do it. > > - The documentation of the discussed None-aware operators. Since these > new operators are closely coupled to the arguably suboptimal "| None" > pattern, it is probably good to tell folks right there why they should > consider better alternatives. > > As mentioned, I absolutely see Steve's point. However, there are many > Python scripts/programs working without a complex API, where this "| > None" pattern may still have its legitimate uses and the none-aware > operators can make code easier to read (and write). > > Best regards, > Philipp > ___ > 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/Q2MOF5CJ7LSSZMEMB43YVEXD6PFATYTA/ > 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/YFY2LKA4YE7U7FRSTSWDUXYSN6XGOWQZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Possible bug in `re` module in Python 3.11?
Hi,
I would like to ask your guidance as I'm entirely sure whether the problem I'm
experiencing should be posted in CPython's repo as a bug issue.
I've tried using newly released Python 3.11 interpreter in some of my projects
and one of them failed to start with "RuntimeError: invalid SRE code" error.
Looking into implementation of one of the dependencies I've found out that the
issue has been found out by a maintainer and fixed
(https://github.com/pydicom/pydicom/issues/1658).
It looks like this particular regexp caused the `re.compile()` method to raise:
```
re.compile(
r"(?P^([01][0-9]|2[0-3]))"
r"((?P([0-5][0-9]))?"
r"(?(5)(?P([0-5][0-9]|60))?)"
r"(?(7)(\.(?P([0-9]{1,6})?))?))$"
)
```
I've checked and this hasn't been an issue in all previous Python interpreter
versions, starting from 3.6 (the oldest I've checked).
What's more the regex i correctly recognized and does not cause any issues in
other regexp implementations, e.g. the online tool https://regex101.com/
Could somebody help me decide whether this is indeed a bug?
Best regards,
Piotr Waszkiewicz
___
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/NWXOPK5C4KTIHNVXVHSNHVFADTJCIE6N/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Possible bug in `re` module in Python 3.11?
Thank you very much for your input, I've filled in the bug report:
https://github.com/python/cpython/issues/98740
Best regards,
Piotr
On Wed, Oct 26, 2022 at 6:55 PM Serhiy Storchaka
wrote:
> 26.10.22 11:17, Piotr Waszkiewicz пише:
> > Hi,
> > I would like to ask your guidance as I'm entirely sure whether the
> problem I'm experiencing should be posted in CPython's repo as a bug issue.
> > I've tried using newly released Python 3.11 interpreter in some of my
> projects and one of them failed to start with "RuntimeError: invalid SRE
> code" error.
> >
> > Looking into implementation of one of the dependencies I've found out
> that the issue has been found out by a maintainer and fixed (
> https://github.com/pydicom/pydicom/issues/1658).
> > It looks like this particular regexp caused the `re.compile()` method to
> raise:
> >
> > ```
> > re.compile(
> > r"(?P^([01][0-9]|2[0-3]))"
> > r"((?P([0-5][0-9]))?"
> > r"(?(5)(?P([0-5][0-9]|60))?)"
> > r"(?(7)(\.(?P([0-9]{1,6})?))?))$"
> > )
> > ```
> >
> > I've checked and this hasn't been an issue in all previous Python
> interpreter versions, starting from 3.6 (the oldest I've checked).
> > What's more the regex i correctly recognized and does not cause any
> issues in other regexp implementations, e.g. the online tool
> https://regex101.com/
> >
> > Could somebody help me decide whether this is indeed a bug?
>
> Yes, it is a bug, and I have found its cause. Please open an issue on
> the CPython bug tracker.
>
>
>
> ___
> 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/GQP6P2CLVX4EOND73JYOXWNCIA3HIERW/
> 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/IR2RQENMX2LAG4X3TQCY7L6XFAFXIVYF/
Code of Conduct: http://python.org/psf/codeofconduct/
