# PEP 722/723 decision

**URL:** <https://discuss.python.org/t/pep-722-723-decision/36763>\
**Category:** Standards\
**Tags:** pep\
**Created:** [October 21, 2023, 12:23am UTC](https://discuss.python.org/t/pep-722-723-decision/36763 "2023-10-21T00:23:20Z")\
**Posts on this page:** 1\
**Showing post:** 90

<div class="post-metadata">

**Author:** ![ofek](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ofek/32/1033_2.png) [@ofek](https://discuss.python.org/u/ofek)\
**Post date:** [October 29, 2023, 4:27pm UTC](https://discuss.python.org/t/pep-722-723-decision/36763/90 "2023-10-29T16:27:19Z")

</div>

I will be updating the PEP in a few minutes but I wanted to address two things:

> [@h-vetinari](#):
>
> but even before that change, popping the current reference regex into [https://regex101.com/](https://regex101.com/) shows that it doesn’t work on many other engines either

That’s not exactly correct. Forward slashes have no significance in regular expressions but rather may be used as a delimiter in determining the start/end of patterns in for example the sed command and JavaScript. The regular expression is compatible with everything right now.

> [@ntessore](#):
>
> I’m not sure it’s a contrived example, since the `[tool]` table might contain arbitrary strings containing `///`. ~~This breaks the current ducktools parser:~~ This seemingly reasonable config cannot currently be parsed with the implementation offered above: [[1]](#footnote-123397-1)
> 
> ```auto
> # /// pyproject
> # [run]
> # requires-python = ">=3.11"
> # [tool.pep723lint]
> # markers = """
> # ///
> # """
> # ///
> 
> ```

The reference implementation does parse this properly because the regular expression is greedy and will keep going until the final end delimiter without the next line being a comment. I will update the text to describe this semantic.

---

_[View the full topic](https://discuss.python.org/t/pep-722-723-decision/36763)._