[Python-Dev] Re: Rejecting PEP 637 (Support for indexing with keyword arguments)
All right. Thanks for the feedback. Brandt should we terminate the branch, or restructure it for the *args mechanics? On Mon, 15 Mar 2021 at 18:43, Thomas Wouters wrote: > > > Hi Stefano, > > Thank you for submitting PEP 637 (Support for indexing with keyword > arguments). The Steering Council has reviewed the PEP and after careful > consideration, we have decided to reject the PEP. There are a number of > reasons for this, but fundamentally we do not believe the benefit is great > enough to outweigh the cost of the new syntax. > > The benefits of the new syntax as outlined in the PEP are not particularly > strong, and community support for the new syntax seems low. The new syntax > doesn’t provide an obvious way to do something that is currently error-prone, > and doesn’t open up new possibilities that were not possible before. While > there are certainly cases that could use the new syntax, for many of them > it’s not clear that it would be a win, or that third-party libraries would > indeed use the syntax. The Steering Council isn’t really convinced by any of > the suggested uses in the PEP. > > The strongest argument for the new syntax comes from the typing side of > Python. The Steering Council is not particularly convinced it is of > significant benefit to the static type checking language, but even if it > were, at this point we’re reluctant to add general Python syntax that only > (or mostly) benefits the static typing language. If the syntax would be of > great benefit to static typing, it might be time to discuss letting go of the > requirement that the typing language be a subset of Python -- but whether > this feature is important enough to consider that is up to the typing > community. > > The SC considers the cost of the new syntax significant. It’s not a natural > fit, as shown by the corner cases discussed in the PEP. It’s difficult to > teach, as indexing and function calls are not as interchangeable or > equivalent as they may appear. Looking at more complex expressions with the > new syntax, mentally parsing them is significantly harder than the equivalent > without the new syntax, even if it requires more lines of code to do the same > thing. > > In addition to all that, the SC is worried about the performance of indexing > in CPython and in other Python implementations, considering it’s a very > common operation, and about the suggested new __getitem__ protocol, > particularly the confusing corner cases of indexing with keywords and zero or > one positional items. These are not, however, the main reason we decided to > reject the PEP. > > With our appreciation, > For the whole Python Steering Council, > Thomas. > -- > Thomas Wouters > > Hi! I'm an email virus! Think twice before sending your email to help me > spread! -- Kind regards, Stefano Borini ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/66I2QLDYYHZ6MMVSTLGIQ74NY6XV2YVZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Reviving PEP 473
For best performance (reduce time to build an exception object), I
would be interested to only format the error message on demand. For
example, when str(exception) is called.
The problem is the Exception.args attribute. Example:
$ ./python
Python 3.10.0a6+
>>> exc=AttributeError("%s object has no attribute %s" % ("MyObject", "name"))
>>> str(exc)
'MyObject object has no attribute name'
>>> exc.args
('MyObject object has no attribute name',)
Currently, args is the raw positional arguments passed to the
Exception constructor, and they are very likely many applications
relying on Exception.args.
For backward compatibility, we could store "%s object has no attribute
%s" and ("MyObject", "name"), and build the args tuple on demand and
format the string at the first str() call.
At the C level, args is exposed directly as PyBaseExceptionObject.args
and the PyBaseExceptionObject structure is part of the public C API.
Changing it would be a C API incompatible change.
By the way, the PEP 473 doesn't say anything about it and has no
"Backward compatibility" section :-(
Victor
On Sat, Mar 13, 2021 at 7:49 PM Sebastian Kreft wrote:
>
> Hi dev-team, I'm reopening the discussion of PEP 473, which was closed due to:
>
> The steering council felt the PEP was too broad and not focused enough.
> Discussions about adding more attributes to built-in exceptions can continue
> on the issue tracker on a per-exception basis (and obviously here for any
> broader points, e.g. performance implications as I know that has come up
> before when the idea of storing relevant objects on exceptions).
>
> Before the PEP was rejected by the SC, I had submitted
> https://github.com/python/cpython/pull/6271 and the last response said:
>
> You may propose a newly revised PEP which overcomes the last SC feedback.
> But without the accepted PEP, this PR can not be merged.
>
> Please clarify how can I proceed with adding some of the specified fields to
> the mentioned exceptions. Should I create a new PEP as suggested in the PR or
> should we create individual BPO issues for each exception modification.
>
> --
> Sebastian Kreft
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/4XVFFNBHXN5KBTHJGMX6ZTN6KOW4Z7UG/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/LVI7S6O5QVVTZN5A6DLYHEKGHW6EIZUH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pth file encoding
On Mon, Mar 15, 2021 at 7:53 PM Inada Naoki wrote: > Hi, all. > > I found .pth file is decoded by the default (i.e. locale-specific) > encoding. > > https://github.com/python/cpython/blob/0269ce87c9347542c54a653dd78b9f60bb9fa822/Lib/site.py#L173 > > pth files contain: > > * import statements > * paths > > For import statement, UTF-8 is the default Python code encoding. > For paths, fsencoding is the right encoding. It is UTF-8 on Windows > (excpet PYTHONLEGACYWINDOWSFSENCODING is set), and locale-specific > encoding in Linux. > > What encoding should we use? > > * UTF-8 > * sys.getfilesystemencoding() > * Keep status-quo. > What are packaging tools like pip and setuptools writing .pth files out as? ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/GMVXCNGP2J5JFE4ISANASZ5D67UWWVM7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pth file encoding
OK. setuptools doesn't specify encoding at all. So locale-specific encoding is used. We can not fix it in short term. On Wed, Mar 17, 2021 at 4:56 AM Brett Cannon wrote: > > > > On Mon, Mar 15, 2021 at 7:53 PM Inada Naoki wrote: >> >> Hi, all. >> >> I found .pth file is decoded by the default (i.e. locale-specific) encoding. >> https://github.com/python/cpython/blob/0269ce87c9347542c54a653dd78b9f60bb9fa822/Lib/site.py#L173 >> >> pth files contain: >> >> * import statements >> * paths >> >> For import statement, UTF-8 is the default Python code encoding. >> For paths, fsencoding is the right encoding. It is UTF-8 on Windows >> (excpet PYTHONLEGACYWINDOWSFSENCODING is set), and locale-specific >> encoding in Linux. >> >> What encoding should we use? >> >> * UTF-8 >> * sys.getfilesystemencoding() >> * Keep status-quo. > > > What are packaging tools like pip and setuptools writing .pth files out as? -- Inada Naoki ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/B5EWSS6GT5O4HBUJTMCKWKZMTC6U6VTV/ Code of Conduct: http://python.org/psf/codeofconduct/
