date:20220407

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

2022-04-07 Thread Petr Viktorin


So here's my proposal:

- This API stays with the regular public API (Include/cpython/), but to 
use it you'll need to #define Py_USING_UNSTABLE_API (name up for 
bikeshedding).


- Since we're nearing Beta and there's no rush to break things, in 3.11 
you only get a warning if you try to use it without the opt-in #define. 
In 3.12 it'll fail.


- The functions will be renamed to drop the leading underscore. The old 
names will be available as aliases (using #define) and may be removed 
whenever the API changes. (Ideally, the underscore should always mark 
API that's fully private with no guarantees at all.)


- The API will be stable during a minor release. (As usual, for extreme 
cases, exceptions are possible with SC approval.)


- Docs will be updated:
  - https://devguide.python.org/c-api/
  - Individual reference entries for the API and the new opt-in macro


This applies to:

- Functions added in PEP 523
- PyCode_New, PyCode_NewWithPosOnlyArgs
- Ideally anything documented as subject to change between minor 
releases. (To be kind to users, if something is added later we should 
again have one release of compiler warnings before requiring the opt-in. 
Unless that API just changed and users would get errors anyway.)



(Technically, this proposal needs SC approval -- PEP 387 exception for 
PyCode_New*. I'll play by the rules, of course.)




On 06. 04. 22 17:21, Nick Coghlan wrote:



On Wed, 6 Apr 2022, 7:05 am Victor Stinner, > wrote:


On Sun, Apr 3, 2022 at 3:29 PM Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
 > The changes you've made have been excellent, and the existing 3
categories (stable public ABI, stable public API, unstable internal
API) cover the vast majority of cases.
 >
 > The final case that isn't quite covered yet is to offer a
"semi-stable" API category for use cases that are intrinsically
coupled to implementation details that may change between feature
releases, but should remain stable within a release series.
 >
 > The concrete motivating example for the new category is the extra
APIs you need in order to provide an alternative eval loop
implementation.
 >
 > The internal API category doesn't properly cover that case, as
the APIs there are free to change even in maintenance releases, and
setting Py_BUILD_CORE exposes a lot more than what an alternative
eval loop would need.
 >
 > Regular public functions may work in some cases, but aren't
necessarily practical in others (such as exposing the internal frame
details for use in alternative eval loops).
 >
 > From an implementation PoV, my own suggestion would be to define
a new API tier with an opt-in macro rather than relying solely on
documentation or naming conventions.
 >
 > For example, define "Py_SEMI_STABLE_API" to opt in, with the
headers under "Include/cpython/semi_stable/" (I don't like
"unstable" as potential terminology here, since the internal API is
already unstable - we're splitting the difference between that and
the long term stability of the full public API)

For me an API is either stable (remains the same forever) or unstable
(change time to time).

Public API means: stable, documented, tested.

Internal API means: unstable, not documented, not tested.

I'm not convinced that it's worth it to create something in the
middle. If you want to add doc and tests, it should become a public
stable API.


The middle semi-stable tier formalises a concept that we already have: 
no guarantees across feature releases, but both API and ABI stable 
within a release series.


It's useful for tightly coupled projects like Cython, as it means they 
can get core level performance without the risk of API compatibility 
breaks in maintenance releases.


Without defining this tier, effectively the *entire* internal API 
becomes semi-stable, as any changes made will risk breaking the third 
party projects that we've told to define Py_BUILD_CORE when compiling.


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

[Python-Dev] Re: [python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

2022-04-07 Thread Victor Stinner

IMO adding locale.getencoding() to Python 3.11 is not controversial
and is useful even if PEP 686 is rejected. This function was discussed
for 1 year (bpo-43510, bpo-43552, bpo-43557, bpo-47000) and there is
an agreement that there is a need for this function.

> Making `open(path, encoding="locale")` use locale encoding in UTF-8 mode 
> (Python 3.10 used UTF-8)

If someone explicitly opts in for the "locale encoding", it sounds
surprising that the locale (encoding) is ignored and that UTF-8 is
used if the Python UTF-8 Mode is enabled. I'm fine with this change.
If you want to always UTF-8... Pass explicitly UTF-8:

# no surprise, always decode file content from UTF-8
json_file = open(filename, encoding="utf-8")

--

I will not comment PEP 686 here. It's being discussed on Discourse:

* https://discuss.python.org/t/14435
* https://discuss.python.org/t/14737

Victor

On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki  wrote:
>
> Hi, Pablo.
>
> I just submitted the PEP 686 to the SC.
> https://github.com/python/steering-council/issues/118
>
> In this PEP, I am proposing:
>
> a. Small improvement for UTF-8 mode in Python 3.11
> b. Make UTF-8 mode default in Python 3.13.
>
> (a) is an important change for (b) so I included it in the PEP.
> More precisely, (a) contains two changes:
>
> * Making `open(path, encoding="locale")` use locale encoding in UTF-8
> mode (Python 3.10 used UTF-8)
> * Add `locale.getencoding()` that is same to
> `locale.getpreferredencoding(False)` but returns locale encoding even
> in UTF-8 mode.
>
> These changes are important for (b).
> But they are not a big change needing PEP.
>
> What should I do?
>
> * Do not merge anything until PEP accepted.
> * Merge (a) without waiting PEP accepted.
> * Merge (a) and remove it from the PEP.
>
> FWI, I and Victor are implementing `locale.getencoding()` for now.
>
> https://bugs.python.org/issue47000
> https://github.com/python/cpython/pull/32068
>
> Regards,
> --
> Inada Naoki  
> ___
> 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/7E4QEKZ6HNDDPDL76LP3TBBKLAUQ7AHB/
> 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/KEW2G2O57CNO66QFZ2I3E3D6ILQ67RII/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

2022-04-07 Thread Victor Stinner

On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki  wrote:
> I just submitted the PEP 686 to the SC.
> https://github.com/python/steering-council/issues/118
>
> In this PEP, I am proposing:
>
> a. Small improvement for UTF-8 mode in Python 3.11
> b. Make UTF-8 mode default in Python 3.13.

It's easier to approve or reject a PEP if all changes target the same
Python version. I'm not sure that (a) changes require a PEP, they are
mostly bugfixes and uncontroversial enhancements.

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

[Python-Dev] About PEPs being discussed on Discourse

2022-04-07 Thread Victor Stinner

Hi,

Would it be possible to announce new PEPs on python-dev please?

I don't go often to Discourse, like once a month. I don't get any
notification by email. I expected new PEPs to be announced on
python-dev, but they are not announced here anymore. Is it possible to
get Discourse notifications by email, but only for new PEPs? Using
mailing lists, it's easy: just select the mailing list that you would
like to subscribe to.

So I went to Discourse, I click on "New Topics" and I don't see any new PEP...

... But if I go manually to the PEP category, there are 2 new PEPs
proposed (PEP 678, PEP 687). In this category, if I click on the bell:
it says "You will be notified if someone mentions your @name or
replies to you". I can change this parameter to "You will be notified
of new topics in this category but not replies to the topics." I don't
recall if I changed this parameter manually, but it seems like the
choice to only be notified of new topics is a new (i don't think that
it existed 1 year ago). I don't recall that I opted in to not be
notified of new PEPs.

Now I see that Inada-san submitted the PEP 686 to the SC:
https://github.com/python/steering-council/issues/118

I didn't read the discussion about this PEP which interest me. I knew
that it exists because I saw related issues and pull requests about
this PEP, but I didn't go to the discussion because I don't have the
habit of visiting Discourse. I guess that it's my fault of not going
to Discourse often enough.

It's sometimes hard to keep track of everything happening around
Python development. The discussions are scattered between multiple
communication channels:

* Issues
* Pull requests
* python-dev
* python-committers
* (private) Discord
* Discourse
* (public) IRC #python-dev

Sometimes, I already confused by the same topic being discussed in two
different Discord rooms :-) It's also common that some people discuss
on the issue, and other people have a parallel discussion (about the
same topic) on the related pull request.

There are also Language Summit (sadly, I cannot attend it this year,
for the first time) and CPython core dev sprints. Sometimes, a
discussion happens on Twitter, but if it becomes serious, it moves to
the above communication channels, so it's fine.

I'm not going to https://python.zulipchat.com/ anymore, I guess that
it has been replaced with Discord.

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

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread Petr Viktorin

On 07. 04. 22 15:59, Victor Stinner wrote:

Hi,

Would it be possible to announce new PEPs on python-dev please?

Currently, all PEPs should be announced on python-dev, but not
necessarily right after they're published. They should be announced
before submitting them to SC, though.

Hm, but is not possible to subcsribe only to PEP announcements here,
either. Is it? :)

So I went to Discourse, I click on "New Topics" and I don't see any new PEP...

Now I see that Inada-san submitted the PEP 686 to the SC:
https://github.com/python/steering-council/issues/118

It's sometimes hard to keep track of everything happening around
Python development. The discussions are scattered between multiple
communication channels:

* Issues
* Pull requests
* python-dev
* python-committers
* (private) Discord
* Discourse
* (public) IRC #python-dev

And for new PEPs as they're published, you can use the RSS feed at
https://www.python.org/dev/peps/peps.rss :)

I'm not going to https://python.zulipchat.com/ anymore, I guess that
it has been replaced with Discord.

Victor

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

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

2022-04-07 Thread Victor Stinner

On Thu, Apr 7, 2022 at 12:02 PM Petr Viktorin  wrote:
> - This API stays with the regular public API (Include/cpython/), but to
> use it you'll need to #define Py_USING_UNSTABLE_API (name up for
> bikeshedding).

Since there is already something similar called "Py_LIMITED", I
suggest dropping "USING_" for just: "Py_UNSTABLE_API".

> - The functions will be renamed to drop the leading underscore. The old
> names will be available as aliases (using #define) and may be removed
> whenever the API changes. (Ideally, the underscore should always mark
> API that's fully private with no guarantees at all.)

Should functions entering the "unstable API" be documented and tested?

For example, _PyEval_EvalFrameDefault() and
_PyInterpreterState_SetEvalFrameFunc() have no test nor doc.

> This applies to:
>
> - PyCode_New, PyCode_NewWithPosOnlyArgs

It would be nice to update Cython to define the Py_UNSTABLE_API macro
before the macro is required to get the function, since Cython still
uses PyCode_New().

Should we deprecate types.CodeType constructor in the Python API,
since types.CodeType.replace() exists and seems to be a better API
("more stable")?

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

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread Jean Abou Samra

Le 07/04/2022 à 15:59, Victor Stinner a écrit :

Hi,

Would it be possible to announce new PEPs on python-dev please?

So I went to Discourse, I click on "New Topics" and I don't see any new PEP...

Now I see that Inada-san submitted the PEP 686 to the SC:
https://github.com/python/steering-council/issues/118

It's sometimes hard to keep track of everything happening around
Python development. The discussions are scattered between multiple
communication channels:

* Issues
* Pull requests
* python-dev
* python-committers
* (private) Discord
* Discourse
* (public) IRC #python-dev

I'm not going to https://python.zulipchat.com/ anymore, I guess that
it has been replaced with Discord.

Victor

I'm only a lurker here, but find the split between this mailing list
and various Discourse categories a little confusing from the outside.
As far as I understand, the Discourse server was originally an experiment.
Today, it has grown far past the size of an experiment though. Are there
any plans to retire either Discourse or the mailing list and use a
unified communication channel? This is a curiosity question.

Best,
Jean

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

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread Ethan Furman


On 4/7/22 07:31, Petr Viktorin wrote:

On 07. 04. 22 15:59, Victor Stinner wrote:



Would it be possible to announce new PEPs on python-dev please?


Currently, all PEPs should be announced on python-dev, but not necessarily right after they're published. They should be 
announced before submitting them to SC, though.


By the time a PEP is being submitted, the opportunity to contribute has passed.

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

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread Gregory P. Smith

On Thu, Apr 7, 2022 at 4:31 PM Jean Abou Samra  wrote:

>
> I'm only a lurker here, but find the split between this mailing list
> and various Discourse categories a little confusing from the outside.
> As far as I understand, the Discourse server was originally an experiment.
> Today, it has grown far past the size of an experiment though. Are there
> any plans to retire either Discourse or the mailing list and use a
> unified communication channel? This is a curiosity question.
>

We feel it too. We've been finding Discourse more useful from a community
moderation and thread management point of view as well as offering markdown
text and code rendering. Ideal for PEP discussions. Many of us expect
python-dev to wind up obsoleted by Discourse as a result. I encourage
everyone to use https://discuss.python.org/ first for Dev audience
communications. And for lurkers and subscribers here to enable email
notifications for categories of interest over there.

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

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread David Mertz, Ph.D.

FWIW, I find Discourse (and everything similar that I've seen), awkward,
difficult to use, poorly organized, and in every way inferior to my mail
client.

Obviously, other people differ in opinion. Quite likely the majority of
cpython developers disagree. I don't think I'm entirely alone in this
experience though. Of course it's possible that the move will happen (I'm
basically a lurker here, andy preference really shouldn't be very
important).

On Thu, Apr 7, 2022, 8:17 PM Gregory P. Smith  wrote:

>
> On Thu, Apr 7, 2022 at 4:31 PM Jean Abou Samra  wrote:
>
>>
>> I'm only a lurker here, but find the split between this mailing list
>> and various Discourse categories a little confusing from the outside.
>> As far as I understand, the Discourse server was originally an experiment.
>> Today, it has grown far past the size of an experiment though. Are there
>> any plans to retire either Discourse or the mailing list and use a
>> unified communication channel? This is a curiosity question.
>>
>
> We feel it too. We've been finding Discourse more useful from a community
> moderation and thread management point of view as well as offering markdown
> text and code rendering. Ideal for PEP discussions. Many of us expect
> python-dev to wind up obsoleted by Discourse as a result. I encourage
> everyone to use https://discuss.python.org/ first for Dev audience
> communications. And for lurkers and subscribers here to enable email
> notifications for categories of interest over there.
>
> -gps
> ___
> 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/2TPHCHVB7NEMMTEWWYBYFZNIFBEE2S4W/
> 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/E2UCA43NV3XEU7JHRJZVLTEHSD634S4U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread Stephen J. Turnbull

Gregory P. Smith writes:

> We feel it too. We've been finding Discourse more useful from a community
> moderation and thread management point of view as well as offering markdown
> text and code rendering. Ideal for PEP discussions.

The specific mention of "community moderation" and "thread management"
makes me suspect that part of that effect is due to increased cost of
participation for casual observers. That's not necessarily a bad
thing (except for us dilettantes :-), but please make sure that
there's some convenient way for affected non-core communities (PyPy,
SciPy, Django, random PyPI package owners, and Victor ;-) to stay
abreast of proposed changes that (a) may affect them or (b) they may
have relevant expertise in the matter they could contribute.

Suggestion for PEP monitoring:

AIUI the PEP process at a high level view is fairly well monitored by
a certain set of GitHub commits: the proto-PEP "PEP-" commit, the
commit that assigns it a PEP number, and commits that change status.
How about a GitHub bot that does nothing but post PEP commit logs to a
dedicated Discourse channel? It should be possible to remove typo
fixes and the like by posting any that change title, number, or
status, and from the rest exclude any commits that change less than a
dozen lines or something like that. Or perhaps PEP committers could
be asked to include some kind of tag like "#trivial" to distinguish
them.

Steve

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

[Python-Dev] PEP 686 – Make UTF-8 mode default

2022-04-07 Thread Inada Naoki

Hi, all.

I wrote a new PEP last month.
I'm sorry that I forgot to announce it here.

The pep is here:
https://peps.python.org/pep-0686/

Discussions:
* https://discuss.python.org/t/14737 (current thread)
* https://discuss.python.org/t/14435 (previous thread)

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

[Python-Dev] Re: About PEPs being discussed on Discourse

2022-04-07 Thread Christopher Barker

On Thu, Apr 7, 2022 at 7:19 PM David Mertz, Ph.D. 
wrote:

> FWIW, I find Discourse (and everything similar that I've seen), awkward,
> difficult to use, poorly organized, and in every way inferior to my mail
> client.
>


>  I don't think I'm entirely alone in this experience though.
>

You're not -- I agree

This was brought up when Discourse was first introduced (as an experiment)
--and I suspect both you and I made a similar comment.

But if Discourse has been adopted, I guess it's time for us curmudgeons to
bite the bullet and start monitoring it -- and frankly, this list (and
python-ideas) should probably be retired, or turned into an
announcement-only list -- having the current split is the worst option of
all.

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/C23QR5T65VHNL4ZF7CJYJQGEZ4LDLS6S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Python-Dev] Re: [python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

[Python-Dev] Re: [python-committers] Re: [IMPORTANT] Preparations for 3.11.0 beta 1

[Python-Dev] About PEPs being discussed on Discourse

[Python-Dev] Re: About PEPs being discussed on Discourse

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

[Python-Dev] Re: About PEPs being discussed on Discourse

[Python-Dev] Re: About PEPs being discussed on Discourse

[Python-Dev] Re: About PEPs being discussed on Discourse

[Python-Dev] Re: About PEPs being discussed on Discourse

[Python-Dev] Re: About PEPs being discussed on Discourse

[Python-Dev] PEP 686 – Make UTF-8 mode default

[Python-Dev] Re: About PEPs being discussed on Discourse

13 matches

Site Navigation

Mail list logo

Footer information