[python-committers] 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-committers mailing list -- python-committers@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-committers@python.org/message/6VOKLYSEHGPX3IIXGR2NBXN45LSBOFAM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[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-committers mailing list -- python-committers@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-committers@python.org/message/EMYJ6KVCRNM3ZGPY6BWBVXHYBXIDPNU7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[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-committers mailing list -- python-committers@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-committers@python.org/message/BSG76KC7RK4U6JE5C6PTILKNR44HUOJ7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: 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-committers@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-committers@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-committers mailing list -- python-committers@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-committers@python.org/message/UHS2MSJR4LOITOJEFS3BCLEOONKHX36C/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] 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-committers mailing list -- python-committers@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-committers@python.org/message/DR6YTABJ2UHC2HB2EY7R6NJO3OKXNPJN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] 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-committers mailing list -- python-committers@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-committers@python.org/message/YIZGJBMDQAOZHD6MXQCLEXIAKGUQFMQM/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] 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-committers mailing list -- python-committers@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-committers@python.org/message/6TAQ2BEVSJNV4JM2RJYSSYFJUT3INGZD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] 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-committers mailing list -- python-committers@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