[Python-Dev] Requesting PR review on locale module
Hi, Few months ago, I submitted a PR [1] for the bpo [2] about locale.format casting Decimal into float. Has someone some times to finish the review? This change is blocking a bugfix on Tryton [3]. [1] https://github.com/python/cpython/pull/15275 [2] https://bugs.python.org/issue34311 [3] https://bugs.tryton.org/issue8574 Thanks, -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/ ___ 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/UOGIZADIK3EOLGPDDA2C525R63DULSDG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Requesting PR review on locale module
Hi Cédric, Thanks for writing and sorry that you've experienced such a delay. Such occurrences are unfortunately rather common right now, though we're working on improving the situation. Stéphane Wirtel self-assigned that PR to himself a couple of months ago, but indeed hasn't followed it up after his requested changes were apparently addressed, despite a couple of "pings". The experts index[1] lists Marc-Andre Lemburg as the expert for the locale module, so perhaps he'd be interested in taking a look. I've CC-ed both Stéphane and Marc-Andre. [1] https://devguide.python.org/experts/ On Sun, Nov 17, 2019 at 2:06 PM Cédric Krier via Python-Dev < python-dev@python.org> wrote: > Hi, > > Few months ago, I submitted a PR [1] for the bpo [2] about locale.format > casting Decimal into float. Has someone some times to finish the review? > This change is blocking a bugfix on Tryton [3]. > > > [1] https://github.com/python/cpython/pull/15275 > [2] https://bugs.python.org/issue34311 > [3] https://bugs.tryton.org/issue8574 > > > Thanks, > -- > Cédric Krier - B2CK SPRL > Email/Jabber: cedric.kr...@b2ck.com > Tel: +32 472 54 46 59 > Website: http://www.b2ck.com/ > ___ > 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/UOGIZADIK3EOLGPDDA2C525R63DULSDG/ > 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/YY7SA2DASW5IUWIFF5RZ73IVU4UKOZHY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Implementation of PEP-0604
To add some more input about forward references, here are couple of
thoughts:
1. I think ideally we should support forward references to the same extent
they are currently supported:
i.e. Union[None, "ForwardRef"], Union["OtherForwardRef", None], and
Union["ForwardRef", "OtherForwardRef"]
should all be supported. The last one looks the hardest, in the sense that
it looks like we will need
to add `str.__or__()` to support these forms.
2. Forward references to type variables were never supported and we
shouldn't start supporting this
(even if it accidentally worked in some situations). Type variables should
always be defined before use.
So I think we should not worry about point 3 in Richard's e-mail.
Philippe, I think it makes sense to reflect these points to the PEP draft.
--
Ivan
On Thu, 14 Nov 2019 at 02:23, Richard Eames wrote:
> Thanks for the encouragement!
>
> I've been working some more on it since I had some more free cycles in the
> last few days and I think I've got to the limit of my capabilities. I think
> I've got it to a point where it needs more eyes because my experience level
> writing code in the python interpreter is pretty low, so I know that I have
> holes in there, especially around using INCREF/DECREF.
> I'm currently stuck on 3 things:
>
> 1. repr( pickle.loads( pickle.dumps(int | str) ) ) causes an infinite
> recursion that I can't figure out. I might end up re-specializing `repr()`
> again since it isn't defined in the PEP.
>
> 2.
> - `None | "forwardref"` and `None | None`
> - `"forwardref" | None` and `"forwardRefA" | "forwardRefB"`
> I've had a go at adding a `type.__ror__` as suggested by GvR, but I think
> I'm missing something.
>
> 3. type parameters
> - I'm not sure how to handle this:
> ```
> MaybeT = None | "T" # creates shadow union
> T = TypeVar('T')
> maybe_int = MaybeT[int] # should this stay in shadow land, or go back to
> typing.py
> isinstance(1, maybe_int)
> isinstance(1, MaybeT[int])
> ```
> I have a couple options for this:
> - implement the type substitution in c; which can be done, but feels like
> overkill?
> - store the type parameters on the shadow object and vivify when needed
> (which will end up being in the isinstance call)
> - implement the __getitem__ as a call into the typing.py library and
> promote as it's requested. This is how I've currently implemented it.
>
> I'm happy to keep going on this if/when needed,
>
> Richard
> ___
> 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/RYH3TYK5RXII5ESUYMTJAROBUAE3SY7H/
> 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/7P5VPD4AODJXDCBU6Y7H66TWVZEPXLI2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Implementation of PEP-0604
On 2019-11-17 20:09, Ivan Levkivskyi wrote:
To add some more input about forward references, here are couple of
thoughts:
1. I think ideally we should support forward references to the same
extent they are currently supported:
i.e. Union[None, "ForwardRef"], Union["OtherForwardRef", None], and
Union["ForwardRef", "OtherForwardRef"]
should all be supported. The last one looks the hardest, in the sense
that it looks like we will need
to add `str.__or__()` to support these forms.
I'm not sure I like the thought of adding `str.__or__()` because it
would mean that "Foo" | "Bar" becomes valid and returns a type, which is
unexpected.
Perhaps an alternative would be to add 'Forward' to make it explicit:
Forward("ForwardRef") | Forward("OtherForwardRef")
or just:
Forward("ForwardRef") | "OtherForwardRef"
2. Forward references to type variables were never supported and we
shouldn't start supporting this
(even if it accidentally worked in some situations). Type variables
should always be defined before use.
So I think we should not worry about point 3 in Richard's e-mail.
Philippe, I think it makes sense to reflect these points to the PEP draft.
[snip]
On Thu, 14 Nov 2019 at 02:23, Richard Eames > wrote:
Thanks for the encouragement!
I've been working some more on it since I had some more free cycles
in the last few days and I think I've got to the limit of my
capabilities. I think I've got it to a point where it needs more
eyes because my experience level writing code in the python
interpreter is pretty low, so I know that I have holes in there,
especially around using INCREF/DECREF.
I'm currently stuck on 3 things:
1. repr( pickle.loads( pickle.dumps(int | str) ) ) causes an
infinite recursion that I can't figure out. I might end up
re-specializing `repr()` again since it isn't defined in the PEP.
2.
- `None | "forwardref"` and `None | None`
- `"forwardref" | None` and `"forwardRefA" | "forwardRefB"`
I've had a go at adding a `type.__ror__` as suggested by GvR, but I
think I'm missing something.
3. type parameters
- I'm not sure how to handle this:
```
MaybeT = None | "T" # creates shadow union
T = TypeVar('T')
maybe_int = MaybeT[int] # should this stay in shadow land, or go
back to typing.py
isinstance(1, maybe_int)
isinstance(1, MaybeT[int])
```
I have a couple options for this:
- implement the type substitution in c; which can be done, but feels
like overkill?
- store the type parameters on the shadow object and vivify when
needed (which will end up being in the isinstance call)
- implement the __getitem__ as a call into the typing.py library and
promote as it's requested. This is how I've currently implemented it.
I'm happy to keep going on this if/when needed,
___
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/KILH2EA4NTKGYDIROEOQ6GGJ2KLV55X4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pass the Python thread state to internal C functions
On Sat., 16 Nov. 2019, 8:26 am Nathaniel Smith, wrote: > As you know, I'm skeptical that PEP 554 will produce benefits that are > worth the effort, but let's assume for the moment that it is, and > we're all 100% committed to moving all globals into the threadstate. > Even given that, the motivation for this change seems a bit unclear to > me. > > I guess the possible goals are: > > - Get rid of the "ambient" threadstate entirely > - Make accessing the threadstate faster > - Eventually make it easier for CPython maintainers to know which functions require access to a live thread state, and which are stateless helper functions - Eventually make it easier for embedding applications to control which Python code runs in which thread state by moving the thread state activation dance out of the application and into the CPython shared library (We actually broke the thread state activation in hexchat not that long ago - there was a subtle latent defect in how they were handling it, and the changes to interpreter cleanup escalated it to a full blown crash) The need for the implicit thread state is never going to go away, but there are definitely opportunities to make the way we manage it less bug prone. (e.g. In the HPy work, I would expect each handle to be at least bound to an interpreter, and there could even be a higher level construct to associate callbacks with a specific thread state) Cheers, Nick. > ___ 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/YIAVY4QFRNLO6FBVFHZNSFCBNLJ4WIGV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Implementation of PEP-0604
On Mon., 18 Nov. 2019, 6:52 am MRAB, wrote:
> On 2019-11-17 20:09, Ivan Levkivskyi wrote:
> > To add some more input about forward references, here are couple of
> > thoughts:
> >
> > 1. I think ideally we should support forward references to the same
> > extent they are currently supported:
> > i.e. Union[None, "ForwardRef"], Union["OtherForwardRef", None], and
> > Union["ForwardRef", "OtherForwardRef"]
> > should all be supported. The last one looks the hardest, in the sense
> > that it looks like we will need
> > to add `str.__or__()` to support these forms.
> >
> I'm not sure I like the thought of adding `str.__or__()` because it
> would mean that "Foo" | "Bar" becomes valid and returns a type, which is
> unexpected.
>
> Perhaps an alternative would be to add 'Forward' to make it explicit:
>
> Forward("ForwardRef") | Forward("OtherForwardRef")
>
> or just:
>
> Forward("ForwardRef") | "OtherForwardRef"
>
Or require that the entire expression be quoted in that case: "ForwardRef |
OtherForwardRef"
I wouldn't personally object to an explicit "typing.Forward" construct,
though.
Cheers,
Nick.
>
___
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/3HLUDMPMSJYSQ4M3TEG545MZWPDENMRG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pass the Python thread state to internal C functions
On Sun, Nov 17, 2019 at 1:58 PM Nick Coghlan wrote: > On Sat., 16 Nov. 2019, 8:26 am Nathaniel Smith, wrote: >> >> As you know, I'm skeptical that PEP 554 will produce benefits that are >> worth the effort, but let's assume for the moment that it is, and >> we're all 100% committed to moving all globals into the threadstate. >> Even given that, the motivation for this change seems a bit unclear to >> me. >> >> I guess the possible goals are: >> >> - Get rid of the "ambient" threadstate entirely >> - Make accessing the threadstate faster > > - Eventually make it easier for CPython maintainers to know which functions > require access to a live thread state, and which are stateless helper > functions So the idea would be that eventually we'd remove all uses of implicit state lookup inside CPython, and add some kind of CI check to make sure that they're never used? > - Eventually make it easier for embedding applications to control which > Python code runs in which thread state by moving the thread state activation > dance out of the application and into the CPython shared library That seems like a good goal, but I don't understand how it's related to passing threadstate explicitly as a function argument. If the plan is to move towards passing threadstates both implicitly AND explicitly everywhere, that seems like it would make things more error-prone, not less, because the two states could get out of sync. Could you elaborate? -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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/5JKNEYXI6ZILC3P6JBXW7NKAUVMXBRQN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] thes mapping data type and thescfg cfg file module - review and suggestion request
If you are not aware: - Thesaurus is a mapping data type with recursive keypath map and attribute aliasing. It is a subclass of dict() and is mostly compatible as a general use dictionary replacement. - ThesaurusExtended is a subclass of Thesaurus providing additional usability methods such as recursive key and value searching. - ThesaurusCfg is a subclass of ThesaurusExtended providing a nested key configuration file parser and per key data coercion methods. The README.rsl will give a better idea: https://git.cinege.com/thesaurus/ After 7 years I might have reached the point of 'interesting' with my Thesaurus and ThesaurusCfg modules. To anyone that is overly bored, I'd appreciate your terse review and comments on how mundane and worthless they still actually are. :-) I'm primarily interested in suggestions to what I've done conceptually here. While I'm not completely ashamed of the state of the Thesaurus code, ThesaurusCfg is not far beyond the original few hours I slapped it together one day in frustration. After considering suggestions I intend to make changes towards a formal release. Thanks in advance, Dave ___ 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/CTXKJUTTJKOS47T6XI2O6WU7EYVEQQ3N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Requesting PR review on locale module
Hi Cedric, It’s my fault, I am going to check your PR for this week. I am really sorry because I am busy with the preparation of my black belt in Karate and I have a training every day. Have a nice day, Stéphane > Le 17 nov. 2019 à 14:06, Tal Einat a écrit : > > > Hi Cédric, > > Thanks for writing and sorry that you've experienced such a delay. Such > occurrences are unfortunately rather common right now, though we're working > on improving the situation. > > Stéphane Wirtel self-assigned that PR to himself a couple of months ago, but > indeed hasn't followed it up after his requested changes were apparently > addressed, despite a couple of "pings". > > The experts index[1] lists Marc-Andre Lemburg as the expert for the locale > module, so perhaps he'd be interested in taking a look. > > I've CC-ed both Stéphane and Marc-Andre. > > [1] https://devguide.python.org/experts/ > >> On Sun, Nov 17, 2019 at 2:06 PM Cédric Krier via Python-Dev >> wrote: >> Hi, >> >> Few months ago, I submitted a PR [1] for the bpo [2] about locale.format >> casting Decimal into float. Has someone some times to finish the review? >> This change is blocking a bugfix on Tryton [3]. >> >> >> [1] https://github.com/python/cpython/pull/15275 >> [2] https://bugs.python.org/issue34311 >> [3] https://bugs.tryton.org/issue8574 >> >> >> Thanks, >> -- >> Cédric Krier - B2CK SPRL >> Email/Jabber: cedric.kr...@b2ck.com >> Tel: +32 472 54 46 59 >> Website: http://www.b2ck.com/ >> ___ >> 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/UOGIZADIK3EOLGPDDA2C525R63DULSDG/ >> 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/P7DMG56Q7CAJZ2WDD7IL2F3N4MI5WTEB/ Code of Conduct: http://python.org/psf/codeofconduct/
