[Python-Dev] Re: Python Language Summit 2021 Signups Are Now Open

[Mariatta]

The sign up for Python Language Summit is still open but only for 7 more
days!

We received a few more attendee sign ups since last time I posted here, but
we haven't received very many topic proposals yet.

If you've been thinking of proposing a discussion topic to the language
summit, now is the time.

Details: https://us.pycon.org/2021/summits/language/
Sign up stats: https://mariatta.ca/language_summit_data/


On Wed, Mar 3, 2021 at 12:31 PM Mariatta  wrote:

> Sign up to Python Language Summit is still open for about 3 more weeks.
>
> So far we received 32 sign ups, from 18 different regions, and 12 time
> zones to work with.
>
> We've only received 3 topics of discussions, and we definitely need more
> of those.
> If you have a topic to be discussed with Python core developers, please
> fill in the forms linked in Łukasz's post.
>
> I've made some infographics with these data, I will try to update it once
> a day: https://mariatta.ca/language_summit_data/
>
> We also have a page on PyCon US's website now:
> https://us.pycon.org/2021/summits/language/
>
> Thanks.
>
> On Wed, Feb 24, 2021 at 9:54 AM Łukasz Langa  wrote:
>
>> I’m happy to announce that we’ve opened the sign-up forms for the 2021
>> Python Language Summit!
>> TL;DR
>>
>>- When: Tuesday, May 11, 2021 (4 hours) and Wednesday, May 12, 2021
>>(4 hours). Exact times TBD depending on attendee timezones.
>>- Where: Online via Zoom (link will be sent via email to attendees)
>>- Co-chairs: Mariatta Wijaya & Łukasz Langa
>>- Blogger: Joanna Jablonski
>>- Sign up to attend *and actively participate*:
>>https://forms.gle/cgmGnmQMDhD2mhHY8 (closes after March 22nd, 2021
>>AoE)
>>- Propose a topic: https://forms.gle/Jui9mxsHrB4fVvAB8 (closes after
>>March 22nd, 2021 AoE)
>>
>> To get an idea of past Python Language Summits, you can read these blog
>> posts:
>>
>>- 2020: Python Software Foundation News: The 2020 Python Language
>>Summit
>>
>> 
>>- 2019:
>>http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html
>>- 2018: The 2018 Python Language Summit [LWN.net]
>>
>>- 2017: The 2017 Python Language Summit [LWN.net]
>>
>>
>> Do I need to sign up if I’m a Python core developer?
>>
>> Yes please! While in the past we have limited attendance to 50 people,
>> this time, due to virtual format, we will be a bit more flexible, but will
>> still keep it small and manageable. We aren’t planning to go beyond 80
>> participants. Please register to reserve your space.
>> Can I sign up if I’m not a Python core developer?
>>
>> Yes you can. In the past, we had quite a number of participants who were
>> not Python core devs. Among them were maintainers and representatives from
>> BeeWare, CircuitPython, PSF board member, PyCharm, PyPA, etc. Register if
>> you want to participate. Note that until you hear back from us, your
>> attendance is not confirmed. As explained in the question above, our
>> “space” is more flexible than usual, but in the interest of maintaining a
>> vigorous discussion space, we might still be unable to invite everyone who
>> signs up.
>> What kind of topics are covered?
>>
>> Python Language Summit is a special event with very specific audience:
>> Python core developers. Ideally your topic is not an “announcement” or
>> “project status” but rather something that will encourage further
>> discussion and questions. The more controversial, the better. An open
>> issue, group of issues, or a PEP that is awaiting decision are all good
>> topics to propose. You can also further explain why this is better
>> discussed in person instead of online.
>>
>> According to last year’s feedback, our audience prefer more discussions
>> and shorter talks.
>> Who can present a talk?
>>
>> Anyone, even if you’re not a Python core developer. However, please
>> understand that we will have to be selective as space and time are limited.
>> In particular, we are prioritizing active core contributors, as well as
>> those who we believe will be able to improve the quality of the discussions
>> at the event and bring a more diverse perspective to core Python
>> developers. Note that your topic is not confirmed until you hear back from
>> us.
>> Code of Conduct
>>
>> PyCon’s Code of Conduct
>>  applies and will be
>> enforced.
>>
>> Thanks!
>>
>> @mariatta  & @ambv
>> 
>>
>
___
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/UI23ZJAH3U5G7HO4IFTS3CRKROTOYVFS/
Code of 

[Python-Dev] Rejecting PEP 637 (Support for indexing with keyword arguments)

[Thomas Wouters]

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!
___
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/6TAQ2BEVSJNV4JM2RJYSSYFJUT3INGZD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Accepting PEP 597 (Add optional EncodingWarning)

[Thomas Wouters]

Hi Inada,

Thank you for submitting PEP 597 (Add optional EncodingWarning). The
Steering Council is happy with the PEP, and hereby accepts it. The SC is of
the opinion that we should move towards making UTF-8 the default encoding,
and this PEP will make it easier to do so, and mitigate some of the
confusion around the default encoding in the meantime.

That being said, the SC would like to invite you and others with interest
to work on a PEP for a long term plan to, in fact, change the default
encoding to UTF-8. We don't want to make irrevocable decisions until we
have a clear, viable plan with a good upgrade path and with community
support, but we do believe we need to make that decision sooner rather than
later.

With thanks from the whole Python Steering Council,
Thomas.
-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/YIZGJBMDQAOZHD6MXQCLEXIAKGUQFMQM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Accepting PEP 624 (Remove Py_UNICODE encoder APIs)

[Thomas Wouters]

Hi Inada,

Thank you for submitting PEP 624 (Remove Py_UNICODE encoder APIs). The
Steering Council is happy to accept it, but we do have two conditions. We
want to make sure that the documentation is clear on what is deprecated,
and when they are scheduled to be removed. For example,
PyUnicode_TransformDecimalToASCII is itself not currently marked as
deprecated (although the section header does mention the deprecation, that
is easy to miss), PyUnicode_TranslateCharmap is scheduled for removal in
4.0, and PyUnicode_AsUnicode has two deprecation notices, one mentioning
removal in 3.10 and one in 3.12.

We would also like to make sure users who need to migrate off of these APIs
have the information necessary to do so. The PEP currently lists
alternatives with caveats, and it's not immediately obvious from the PEP or
the API documentation what the right alternative is for those caveats. As a
condition of this PEP’s acceptance, we request that you fully document the
recommended workarounds for these caveats. We do recognise that
PyUnicode_EncodeDecimal is currently entirely undocumented. Documenting at
this stage is probably not worth the effort, but perhaps it could be
mentioned in a brief ‘porting’ section in the PEP instead.

With the Python Steering Council's gratitude,
Thomas.
-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/DR6YTABJ2UHC2HB2EY7R6NJO3OKXNPJN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Rejecting PEP 637 (Support for indexing with keyword arguments)

[Guido van Rossum]

Let me clarify what the typing-sig folks wanted out of this PEP. We only
care about adding support for `x[*y]` (including things like `x[a, *b,
c]`). We'll just update PEP 646 to add that explicitly there and hope that
PEP 646 fares better than PEP 637.

To fans of PEP 637 I would call out that the main reason for rejection
seems to be this paragraph:

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.
>

This seems to imply that in order for a proposal like this to fare better
in the future, the authors would need to line up support from specific,
important communities like the scientific, data science or machine learning
communities. Currently such support seems absent except for one specific
package (xarray).

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/MOXRTWGVRDRUMV2FAJ3W4OCWT4CMI5EO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Rejecting PEP 637 (Support for indexing with keyword arguments)

[Jelle Zijlstra]

El lun, 15 mar 2021 a las 13:13, Guido van Rossum ()
escribió:

> Let me clarify what the typing-sig folks wanted out of this PEP. We only
> care about adding support for `x[*y]` (including things like `x[a, *b,
> c]`). We'll just update PEP 646 to add that explicitly there and hope that
> PEP 646 fares better than PEP 637.
>
> To fans of PEP 637 I would call out that the main reason for rejection
> seems to be this paragraph:
>
> 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.
>>
>
> This seems to imply that in order for a proposal like this to fare better
> in the future, the authors would need to line up support from specific,
> important communities like the scientific, data science or machine learning
> communities. Currently such support seems absent except for one specific
> package (xarray).
>
> Yes, I was surprised to read the focus on typing in the rejection notice
because my recollection from the discussions around PEP 637 was that typing
was not in fact the major motivation, named column indexing was.

Looking at the PEP's motivation section now (
https://www.python.org/dev/peps/pep-0637/#use-cases), two (#2 and #7) are
about typing. #2 ("MyType[T=int]") is rather weak, since "T=int" doesn't
provide any increase in clarity over just "int". #7 (PEP 646) is stronger,
but was tacked on later and doesn't provide much detail.

Among the other use cases, #1 and #3 are quite general. The compelling ones
to me are #4 (pandas), #5 (xarray) and #7 (trio.run and similar functions).
Focusing more on these use cases would have made the PEP's motivation more
similar to matrix multiplication (PEP 465): helping the scientific Python
stack make a construct that's currently awkward more simple.



> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/MOXRTWGVRDRUMV2FAJ3W4OCWT4CMI5EO/
> 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/F5KGJC4IABWZSRLHUDPJZPMJRW2ONDJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Rejecting PEP 637 (Support for indexing with keyword arguments)

[Barry Warsaw]

I think this is really the crux of the rejection: is the new syntax being 
proposed primarily to support typing, or Python in general?  Does it help both, 
or is one use case the motivating factor, and the other is just piggybacking on 
the syntactic proposal?  Quoting from the rejection email:

> 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 didn’t find general Python functionality compelling enough, or 
outweighing the costs.

It’s possible that the proposed syntax is really useful for typing, and less 
compelling for Python users in general.  And that’s totally fine, but then 
we’ll need to discuss whether the typing language and the general Python syntax 
needs to continue to track.

Cheers,
-Barry

> On Mar 15, 2021, at 13:07, Guido van Rossum  wrote:
> 
> Let me clarify what the typing-sig folks wanted out of this PEP. We only care 
> about adding support for `x[*y]` (including things like `x[a, *b, c]`). We'll 
> just update PEP 646 to add that explicitly there and hope that PEP 646 fares 
> better than PEP 637.
> 
> To fans of PEP 637 I would call out that the main reason for rejection seems 
> to be this paragraph:
> 
> 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.
> 
> This seems to imply that in order for a proposal like this to fare better in 
> the future, the authors would need to line up support from specific, 
> important communities like the scientific, data science or machine learning 
> communities. Currently such support seems absent except for one specific 
> package (xarray).
> 
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> ___
> 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/MOXRTWGVRDRUMV2FAJ3W4OCWT4CMI5EO/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/5ZXCK4HTXJ62KNHYYMYBDYYGF4JSFLEN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Rejecting PEP 637 (Support for indexing with keyword arguments)

[Guido van Rossum]

Actually, the key part of the new syntax, x[a=b], is not useful for typing,
at least it's not something that's been discussed in the typing-sig at all.
The only part we want is x[*y].

On Mon, Mar 15, 2021 at 3:27 PM Barry Warsaw  wrote:

> I think this is really the crux of the rejection: is the new syntax being
> proposed primarily to support typing, or Python in general?  Does it help
> both, or is one use case the motivating factor, and the other is just
> piggybacking on the syntactic proposal?  Quoting from the rejection email:
>
> > 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 didn’t find general Python functionality compelling enough, or
> outweighing the costs.
>
> It’s possible that the proposed syntax is really useful for typing, and
> less compelling for Python users in general.  And that’s totally fine, but
> then we’ll need to discuss whether the typing language and the general
> Python syntax needs to continue to track.
>
> Cheers,
> -Barry
>
> > On Mar 15, 2021, at 13:07, Guido van Rossum  wrote:
> >
> > Let me clarify what the typing-sig folks wanted out of this PEP. We only
> care about adding support for `x[*y]` (including things like `x[a, *b,
> c]`). We'll just update PEP 646 to add that explicitly there and hope that
> PEP 646 fares better than PEP 637.
> >
> > To fans of PEP 637 I would call out that the main reason for rejection
> seems to be this paragraph:
> >
> > 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.
> >
> > This seems to imply that in order for a proposal like this to fare
> better in the future, the authors would need to line up support from
> specific, important communities like the scientific, data science or
> machine learning communities. Currently such support seems absent except
> for one specific package (xarray).
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> > Pronouns: he/him (why is my pronoun here?)
> > ___
> > 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/MOXRTWGVRDRUMV2FAJ3W4OCWT4CMI5EO/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/3YVQ4I7LTVO2NCCPAGXZRAG3BJWVGSTD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Accepting PEP 597 (Add optional EncodingWarning)

[Victor Stinner]

Congratulation INADA-san! I'm impressed by your tenacity :-)

Last months, I followed your different propositions on
discuss.python.org to use UTF-8 by default in Python. It's good to see
the first non-controversial part being accepted! I hope that this PEP
will help to move towards a world where we don't guess encodings
anymore, but make them very explicit!

Once the whole stdlib and most of top PyPI projects will be fixed to
no longer emit EncodingWarning, I will become safer to opt-in for
UTF-8 by default by enabling the Python UTF-8 Mode!
https://docs.python.org/dev/library/os.html#python-utf-8-mode

One day, we will silently switch Python to UTF-8 by default, and
nobody will notice! ;-)

Victor

On Mon, Mar 15, 2021 at 7:46 PM Thomas Wouters  wrote:
>
> Hi Inada,
>
> Thank you for submitting PEP 597 (Add optional EncodingWarning). The Steering 
> Council is happy with the PEP, and hereby accepts it. The SC is of the 
> opinion that we should move towards making UTF-8 the default encoding, and 
> this PEP will make it easier to do so, and mitigate some of the confusion 
> around the default encoding in the meantime.
>
> That being said, the SC would like to invite you and others with interest to 
> work on a PEP for a long term plan to, in fact, change the default encoding 
> to UTF-8. We don't want to make irrevocable decisions until we have a clear, 
> viable plan with a good upgrade path and with community support, but we do 
> believe we need to make that decision sooner rather than later.
>
> With thanks from the whole Python Steering Council,
> Thomas.
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me 
> spread!
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committ...@python.org/message/YIZGJBMDQAOZHD6MXQCLEXIAKGUQFMQM/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/UHS2MSJR4LOITOJEFS3BCLEOONKHX36C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Reviving PEP 473

[Brett Cannon]

Since tweaking the built-in exceptions is so far-reaching, probably at
least discussing each proposed change (one at a time, not 5 at once) would
be the minimum. Otherwise you could do a PEP, but once again you're looking
at a PEP per exception. I think it's really going to come down to how big
of an addition it is per exception, how easy it would be to have a memory
leak, what the API to setting the attribute(s) would look like, etc.

On Sat, Mar 13, 2021 at 1:22 PM Victor Stinner  wrote:

> Context: PEP 473 "Adding structured data to built-in exceptions"
> proposed in 2014.
> https://www.python.org/dev/peps/pep-0473/
>
> Abstract: "Exceptions like AttributeError, IndexError, KeyError,
> LookupError, NameError, TypeError, and ValueError do not provide all
> information required by programmers to debug and better understand
> what caused them. Furthermore, in some cases the messages even have
> slightly different formats, which makes it really difficult for tools
> to automatically provide additional information to diagnose the
> problem. To tackle the former and to lay ground for the latter, it is
> proposed to expand these exceptions so to hold both the offending and
> affected entities."
>
> For example the PEP proposes to add "target" and "attribute"
> attributes to AttributeError.
>
> PS: Please give at least the PEP title for me when you mention a PEP
> only by its number, I'm unable to remember what are the 500+ PEP :-(
>
> 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 -- 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/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 -- 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/PLPUG6MFVHHHVONJK6ZHPORCQYJS5QTH/
> 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/C7UZ7MH3TRT4M3NNYDEDNWX5WIXVOVBX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Re: Accepting PEP 597 (Add optional EncodingWarning)

[Guido van Rossum]

On Mon, Mar 15, 2021 at 3:58 PM Victor Stinner  wrote:

> Congratulation INADA-san! I'm impressed by your tenacity :-)
>

+1. Great work!


> Last months, I followed your different propositions on
> discuss.python.org to use UTF-8 by default in Python. It's good to see
> the first non-controversial part being accepted! I hope that this PEP
> will help to move towards a world where we don't guess encodings
> anymore, but make them very explicit!
>

Actually, the "north star" here is a world where nobody has to think about
encodings any more. That, and world peace.


> Once the whole stdlib and most of top PyPI projects will be fixed to
> no longer emit EncodingWarning, I will become safer to opt-in for
> UTF-8 by default by enabling the Python UTF-8 Mode!
> https://docs.python.org/dev/library/os.html#python-utf-8-mode
>
> One day, we will silently switch Python to UTF-8 by default, and
> nobody will notice! ;-)
>

In particular it's important that nobody living in Japan or China should
notice. This is also still the biggest challenge. :-(

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/BSG76KC7RK4U6JE5C6PTILKNR44HUOJ7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Reviving PEP 473

[André Roberge]

I am not a Python developer, but I am very interested in this topic.  While I 
would definitely make use of any additional fields for exceptions as discussed, 
it is already possible to find most, if not all of the information discussed in 
PEP 473. To give just a concrete example taken from the PEP:
```
Friendly Console version 0.3.1. [Python version: 3.8.4]

>>> a = {'foo': 1}
>>> a['fo']

Traceback (most recent call last):
  File "", line 1, in 
a['fo']
KeyError: 'fo'

Did you mean foo?
>>>
>>> foo = 1
>>> fo

Traceback (most recent call last):
  File "", line 1, in 
fo
NameError: name 'fo' is not defined

Did you mean foo?
>>>
```
The above two examples are the actual output done by a program I work on called 
friendly (formerly known as friendly-traceback) and are essentially identical 
to what is given in PEP 473 as a desired outcome. 

Much information about IndexError, AttributeError, etc, mentioned as desirable 
in PEP 473 can already be obtained by such automated tools.  Using friendly as 
an example, a sample of what's possible can be found  at 
https://aroberge.github.io/friendly-traceback-docs/docs/html/tracebacks_en_3.8.html

Of course, having information more easily available about specific exceptions 
would be welcome and make it easier and likely more error-proof to write 
automated tools.  But since much of the information is already available (if 
one looks hard enough...), the cost of adding fields to existing exceptions 
should be carefully evaluated.

André Roberge
___
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/LQATQLUVAZ4COI5HPS4A6DKVQ6UZ5XU7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Re: Accepting PEP 597 (Add optional EncodingWarning)

[Inada Naoki]

Thank you, Council members and all members joined in the long discussion.


On Tue, Mar 16, 2021 at 8:29 AM Guido van Rossum  wrote:
>
>>
>> Once the whole stdlib and most of top PyPI projects will be fixed to
>> no longer emit EncodingWarning, I will become safer to opt-in for
>> UTF-8 by default by enabling the Python UTF-8 Mode!
>> https://docs.python.org/dev/library/os.html#python-utf-8-mode
>>
>> One day, we will silently switch Python to UTF-8 by default, and
>> nobody will notice! ;-)
>
>
> In particular it's important that nobody living in Japan or China should 
> notice. This is also still the biggest challenge. :-(
>

Java has a very similar problem and proposal. See JEP 400 (*) that was
updated recently.
If JEP 400 is accepted, users can use `-Dfile.encoding=COMPAT` for
legacy behavior.
If UTF-8 mode is enabled by default, users can use `PYTHONUTF8=0` or
`-Xutf8=0` for legacy behavior.

(*) https://openjdk.java.net/jeps/400

Anyway, PEP 597 adds `encoding="locale"` option. Let's implement it in
Python 3.10 and wait 4 years.
Many libraries will use only UTF-8, or can drop Python 3.9 support and
use `encoding="locale"` where locale encoding is needed.

Regards,

-- 
Inada Naoki  
___
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/EMYJ6KVCRNM3ZGPY6BWBVXHYBXIDPNU7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 624 (Remove Py_UNICODE encoder APIs)

[Inada Naoki]

Thank you, SC members, Victor, and Marc.

On Tue, Mar 16, 2021 at 3:49 AM Thomas Wouters  wrote:
>
>
> Hi Inada,
>
> Thank you for submitting PEP 624 (Remove Py_UNICODE encoder APIs). The 
> Steering Council is happy to accept it, but we do have two conditions. We 
> want to make sure that the documentation is clear on what is deprecated, and 
> when they are scheduled to be removed. For example, 
> PyUnicode_TransformDecimalToASCII is itself not currently marked as 
> deprecated (although the section header does mention the deprecation, that is 
> easy to miss), PyUnicode_TranslateCharmap is scheduled for removal in 4.0, 
> and PyUnicode_AsUnicode has two deprecation notices, one mentioning removal 
> in 3.10 and one in 3.12.
>
> We would also like to make sure users who need to migrate off of these APIs 
> have the information necessary to do so. The PEP currently lists alternatives 
> with caveats, and it's not immediately obvious from the PEP or the API 
> documentation what the right alternative is for those caveats. As a condition 
> of this PEP’s acceptance, we request that you fully document the recommended 
> workarounds for these caveats. We do recognise that PyUnicode_EncodeDecimal 
> is currently entirely undocumented. Documenting at this stage is probably not 
> worth the effort, but perhaps it could be mentioned in a brief ‘porting’ 
> section in the PEP instead.
>
> With the Python Steering Council's gratitude,
> Thomas.
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me 
> spread!



-- 
Inada Naoki  
___
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/6VOKLYSEHGPX3IIXGR2NBXN45LSBOFAM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] pth file encoding

[Inada Naoki]

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.

Regards,

-- 
Inada Naoki  
___
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/RKXH7QGIBC3UNCLGUSCLWLZX2WM6IGWW/
Code of Conduct: http://python.org/psf/codeofconduct/