[Python-Dev] Re: Migrate typing in builtin

2019-10-08 Thread Philippe Prados 
Ok,

But _GenericAlias and dependencies are written with Python (Lib/typing.py),
not with C.
So, I must rewrite the _GenericAlias in C or it's possible to merge the C
and Python in builtin and add a direct reference to _GenericAlias with C,
and add the reference in builtin module ?

Philippe


Le lun. 7 oct. 2019 à 22:58, Random832  a écrit :

> On Mon, Oct 7, 2019, at 12:02, Philippe Prados wrote:
> > Because this PEP propose to accept, for all classes
> > assert isinstance("", int | str)
> > assert issubclass(int, int | str)
> > and add an operator __or__() for type type.
> > def f(list: List[int | str], param: int | None) -> float | str:
> > pass
>
> Oh, sorry, I didn't realize that this also included the | operator, I
> thought this was just for isinstance("", Union[int, str]).
>
___
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/GD7WXPD26VUPMZT6WAATCJJBB42DDYYQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Migrate typing in builtin

2019-10-08 Thread Ivan Levkivskyi 
You will need to rewrite most of things in C.

--
Ivan


On Tue 8 Oct 2019, 08:53 Philippe Prados,  wrote:

> Ok,
>
> But _GenericAlias and dependencies are written with Python
> (Lib/typing.py), not with C.
> So, I must rewrite the _GenericAlias in C or it's possible to merge the C
> and Python in builtin and add a direct reference to _GenericAlias with C,
> and add the reference in builtin module ?
>
> Philippe
>
>
> Le lun. 7 oct. 2019 à 22:58, Random832  a écrit :
>
>> On Mon, Oct 7, 2019, at 12:02, Philippe Prados wrote:
>> > Because this PEP propose to accept, for all classes
>> > assert isinstance("", int | str)
>> > assert issubclass(int, int | str)
>> > and add an operator __or__() for type type.
>> > def f(list: List[int | str], param: int | None) -> float | str:
>> > pass
>>
>> Oh, sorry, I didn't realize that this also included the | operator, I
>> thought this was just for isinstance("", Union[int, str]).
>>
> ___
> 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/GD7WXPD26VUPMZT6WAATCJJBB42DDYYQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/5UT7NKKB3KM6K67YL2ERMLX6YKLMAPAB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Migrate typing in builtin

2019-10-08 Thread Philippe Prados 
Glups.

I am not an expert of Pyhton source code. May be after this patch ;-)

I think I should discuss with the authors of the module typing, to identify
the best strategy.
Who is he ?

Philippe


Le mar. 8 oct. 2019 à 10:19, Ivan Levkivskyi  a
écrit :

> You will need to rewrite most of things in C.
>
> --
> Ivan
>
>
> On Tue 8 Oct 2019, 08:53 Philippe Prados, 
> wrote:
>
>> Ok,
>>
>> But _GenericAlias and dependencies are written with Python
>> (Lib/typing.py), not with C.
>> So, I must rewrite the _GenericAlias in C or it's possible to merge the C
>> and Python in builtin and add a direct reference to _GenericAlias with C,
>> and add the reference in builtin module ?
>>
>> Philippe
>>
>>
>> Le lun. 7 oct. 2019 à 22:58, Random832  a écrit :
>>
>>> On Mon, Oct 7, 2019, at 12:02, Philippe Prados wrote:
>>> > Because this PEP propose to accept, for all classes
>>> > assert isinstance("", int | str)
>>> > assert issubclass(int, int | str)
>>> > and add an operator __or__() for type type.
>>> > def f(list: List[int | str], param: int | None) -> float | str:
>>> > pass
>>>
>>> Oh, sorry, I didn't realize that this also included the | operator, I
>>> thought this was just for isinstance("", Union[int, str]).
>>>
>> ___
>> 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/GD7WXPD26VUPMZT6WAATCJJBB42DDYYQ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
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/4K7WZ3RBGG7K6E6XK65MS44VQYZIKQS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Migrate typing in builtin

2019-10-08 Thread Brandt Bucher 
I’m a bit confused. For my own understanding: what’s stopping 
PyObject_IsInstance/PyObject_IsSubclass from just trying 
PyImport_GetModule("typing") here?

If NULL, carry on. Otherwise, check the Union case.

Brandt

> On Oct 8, 2019, at 05:44, Philippe Prados  wrote:
> 
> 
> Glups.
> 
> I am not an expert of Pyhton source code. May be after this patch ;-)
> 
> I think I should discuss with the authors of the module typing, to identify 
> the best strategy.
> Who is he ?
> 
> Philippe
> 
> 
>> Le mar. 8 oct. 2019 à 10:19, Ivan Levkivskyi  a écrit :
>> You will need to rewrite most of things in C.
>> 
>> --
>> Ivan
>> 
>> 
>>> On Tue 8 Oct 2019, 08:53 Philippe Prados,  wrote:
>>> Ok, 
>>> 
>>> But _GenericAlias and dependencies are written with Python (Lib/typing.py), 
>>> not with C.
>>> So, I must rewrite the _GenericAlias in C or it's possible to merge the C 
>>> and Python in builtin and add a direct reference to _GenericAlias with C, 
>>> and add the reference in builtin module ?
>>> 
>>> Philippe
>>> 
>>> 
 Le lun. 7 oct. 2019 à 22:58, Random832  a écrit :
 On Mon, Oct 7, 2019, at 12:02, Philippe Prados wrote:
 > Because this PEP propose to accept, for all classes
 > assert isinstance("", int | str)
 > assert issubclass(int, int | str)
 > and add an operator __or__() for type type.
 > def f(list: List[int | str], param: int | None) -> float | str:
 > pass
 
 Oh, sorry, I didn't realize that this also included the | operator, I 
 thought this was just for isinstance("", Union[int, str]).
>>> ___
>>> 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/GD7WXPD26VUPMZT6WAATCJJBB42DDYYQ/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> 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/4K7WZ3RBGG7K6E6XK65MS44VQYZIKQS2/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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/RYGHVWJZT76GNDWNRSOLA74SHZFNDW42/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Migrate typing in builtin

2019-10-08 Thread Guido van Rossum 
That would mean that all of typing will be imported as part of startup, and
that module is too heavy for that. Also it might end up on recursion.

On Tue, Oct 8, 2019 at 09:06 Brandt Bucher  wrote:

> I’m a bit confused. For my own understanding: what’s stopping
> PyObject_IsInstance/PyObject_IsSubclass from just trying
> PyImport_GetModule("typing") here?
>
> If NULL, carry on. Otherwise, check the Union case.
>
> Brandt
>
> On Oct 8, 2019, at 05:44, Philippe Prados 
> wrote:
>
> 
>
> Glups.
>
> I am not an expert of Pyhton source code. May be after this patch ;-)
>
> I think I should discuss with the authors of the module typing, to
> identify the best strategy.
> Who is he ?
>
> Philippe
>
>
> Le mar. 8 oct. 2019 à 10:19, Ivan Levkivskyi  a
> écrit :
>
>> You will need to rewrite most of things in C.
>>
>> --
>> Ivan
>>
>>
>> On Tue 8 Oct 2019, 08:53 Philippe Prados, 
>> wrote:
>>
>>> Ok,
>>>
>>> But _GenericAlias and dependencies are written with Python
>>> (Lib/typing.py), not with C.
>>> So, I must rewrite the _GenericAlias in C or it's possible to merge the
>>> C and Python in builtin and add a direct reference to _GenericAlias with C,
>>> and add the reference in builtin module ?
>>>
>>> Philippe
>>>
>>>
>>> Le lun. 7 oct. 2019 à 22:58, Random832  a
>>> écrit :
>>>
 On Mon, Oct 7, 2019, at 12:02, Philippe Prados wrote:
 > Because this PEP propose to accept, for all classes
 > assert isinstance("", int | str)
 > assert issubclass(int, int | str)
 > and add an operator __or__() for type type.
 > def f(list: List[int | str], param: int | None) -> float | str:
 > pass

 Oh, sorry, I didn't realize that this also included the | operator, I
 thought this was just for isinstance("", Union[int, str]).

>>> ___
>>> 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/GD7WXPD26VUPMZT6WAATCJJBB42DDYYQ/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
> 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/4K7WZ3RBGG7K6E6XK65MS44VQYZIKQS2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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/RYGHVWJZT76GNDWNRSOLA74SHZFNDW42/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/JNGUBZNMC5YMCW2RU2EJTAZBCKLXUNWD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Migrate typing in builtin

2019-10-08 Thread Eric V. Smith 

Ivan (who you cc'd) is a good start!

Eric

On 10/8/2019 8:35 AM, Philippe Prados wrote:

Glups.

I am not an expert of Pyhton source code. May be after this patch ;-)

I think I should discuss with the authors of the module typing, to 
identify the best strategy.

Who is he ?

Philippe


Le mar. 8 oct. 2019 à 10:19, Ivan Levkivskyi > a écrit :


You will need to rewrite most of things in C.

--
Ivan


On Tue 8 Oct 2019, 08:53 Philippe Prados, mailto:[email protected]>> wrote:

Ok,

But _GenericAlias and dependencies are written with Python
(Lib/typing.py), not with C.
So, I must rewrite the _GenericAlias in C or it's possible to
merge the C and Python in builtin and add a direct reference to
_GenericAlias with C, and add the reference in builtin module ?

Philippe


Le lun. 7 oct. 2019 à 22:58, Random832 mailto:[email protected]>> a écrit :

On Mon, Oct 7, 2019, at 12:02, Philippe Prados wrote:
 > Because this PEP propose to accept, for all classes
 > assert isinstance("", int | str)
 > assert issubclass(int, int | str)
 > and add an operator __or__() for type type.
 > def f(list: List[int | str], param: int | None) -> float
| str:
 >     pass

Oh, sorry, I didn't realize that this also included the |
operator, I thought this was just for isinstance("",
Union[int, str]).

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


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


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

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

2019-10-08 Thread David Cuthbert via Python-Dev 
This is too-little, too-late (I was offline this past week), but for those who 
enjoy digging through historical archives, the Tcl folks had an interesting 
stubs mechanism that was *supposed* to solve the versioning issue (although I 
suspect it hasn’t actually done much in that regard) in addition to the 
“cross-platform dynamic linking is a royal pain” (circa 1999) issue: 
https://wiki.tcl-lang.org/page/Stubs

Basically, you just use a vtable of function pointers exported by version, e.g. 
Tcl_8_0_Stubs, Tcl_8_1_Stubs, etc. The clients call each function via a layer 
of indirection, Tcl_8_0_Stubs->Tcl_Tell(), Tcl_8_1_Stubs->Tcl_Tell(), etc.; 
this is hidden by C macros. (From what I recall of COM, this is a rudimentary 
implementation of a COM interface.)


I’m not sure I would recommend this today -- we were solving different problems 
back then (CAD workstations from various Unix vendors patched 
Frankenstein-esque library mismatches), and compiler optimizations weren’t as 
sophisticated. It had the nice advantage of crashing immediately due to a 
version mismatch rather than silently corrupting data structures that had 
undergone changes, etc.


Back then, GNU Binutils symbol versioning was just adding to our headaches 
(again, telling our customers to fix their workstations wasn’t a plausible 
solution, and it was only on Linux, which was then a very small part of the 
installed base).





> On Oct 1, 2019, at 1:45 AM, Victor Stinner  wrote:
> 
> Sorry for the bad timing. I dislike working under pressure. The
> discussion on python-dev, the bug tracker and pull requests was really
> interesting.
> 
> The issue has been fixed: the whole idea of stable ABI for PyConfig
> has been abandoned. If you want to switch to a different version of
> Python when you embed Python, you must recompile your code. It was
> always like that and the PEP 587 doesn't change anything.
> 
> PyConfig_InitPythonConfig() and PyConfig_InitIsolatedConfig()
> initialize PyConfig to sane default configuration. So if we add new
> fields in Python 3.9, you don't have to manually initialize these
> fields, except if you explicitly want to use these new fields to
> benefit of new configuration options.
> 
> Victor
> 
> Le mar. 1 oct. 2019 à 00:38, Nick Coghlan  a écrit :
>> 
>> 
>> 
>> On Tue., 1 Oct. 2019, 6:47 am Victor Stinner,  wrote:
>>> 
>>> Hi back,
>>> 
>>> It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not
>>> really liked".
>>> 
>>> I don't see any traction to provide a stable ABI for embedded Python.
>>> The consensus is more towards: "it doesn't work and we don't want to
>>> bother with false promises" (nor add code for that).
>>> 
>>> Since Lukasz is supposed to tag 3.8.0rc1 today, I propose to remove
>>> anything related to "stable API" or "stable ABI" from the PEP 587
>>> right now. I wrote two PRs to remove struct_size:
>>> 
>>> * CPython: https://github.com/python/cpython/pull/16500
>>> * PEP 587: https://github.com/python/peps/pull/1185
>>> 
>>> Later, if we decide to start proving a stable ABI for embedded Python,
>>> we can still add a "version" or "struct_size" field to PyConfig later
>>> (for example in Python 3.9).
>> 
>> 
>> Thanks Victor, I think this is the right way for us to go, given the 
>> relative timing in the release cycle.
>> 
>> The idea of some day expanding the stable ABI to cover embedding 
>> applications, not just extension modules, is an intriguing one, but I'm 
>> genuinely unsure anyone would ever actually use it.
>> 
>> Cheers,
>> Nick.
>> 
>> 
>> 
>>> 
>>> Victor
>>> ___
>>> 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/2JAJQA5OANFPXAJ3327RRPHPQLKVP2EW/
> 
> 
> 
> -- 
> 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/36RTEPNE6HSPMXGDGSHWDJN56GZRX4YU/

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

[Python-Dev] Python Profilers documentation - typo?

2019-10-08 Thread Rob Cliffe via Python-Dev 

The documentation at
    https://docs.python.org/3.2/library/profile.html
contains the sentence
    For example, if your_integer_time_func() returns times measured in 
thousands of seconds, you would construct the Profile instance as follows:


"thousands of seconds" should ISTM be "thousandths of a second".

There is essentially the same thing in the Python 2 docs at
    https://docs.python.org/2/library/profile.html
viz.
    For example, if the timer returns times measured in _thousands_ of 
seconds, the time unit would be |.001|.


Just trying for perfection!
Best wishes
Rob Cliffe
___
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/JNAFSXJS3ZYZHVNFSV53SDZIBHHU7YNU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Profilers documentation - typo?

2019-10-08 Thread Guido van Rossum 
Pretty embarrassing, I agree. Can you submit a PR?

On Tue, Oct 8, 2019 at 17:38 Rob Cliffe via Python-Dev <
[email protected]> wrote:

> The documentation at
> https://docs.python.org/3.2/library/profile.html
> contains the sentence
> For example, if your_integer_time_func() returns times measured in
> thousands of seconds, you would construct the Profile instance as follows:
>
> "thousands of seconds" should ISTM be "thousandths of a second".
>
> There is essentially the same thing in the Python 2 docs at
> https://docs.python.org/2/library/profile.html
> viz.
> For example, if the timer returns times measured in *thousands* of
> seconds, the time unit would be .001.
>
> Just trying for perfection!
> Best wishes
> Rob Cliffe
> ___
> 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/JNAFSXJS3ZYZHVNFSV53SDZIBHHU7YNU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/PY7A5UL7H2PPOVATZCPDIUUIVH6G55J7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Profilers documentation - typo?

2019-10-08 Thread Chris Angelico 
On Wed, Oct 9, 2019 at 11:44 AM Rob Cliffe via Python-Dev
 wrote:
>
> The documentation at
> https://docs.python.org/3.2/library/profile.html
> contains the sentence
> For example, if your_integer_time_func() returns times measured in 
> thousands of seconds, you would construct the Profile instance as follows:
>
> "thousands of seconds" should ISTM be "thousandths of a second".
>
> There is essentially the same thing in the Python 2 docs at
> https://docs.python.org/2/library/profile.html
> viz.
> For example, if the timer returns times measured in thousands of seconds, 
> the time unit would be .001.
>

Python 3.2 is out of support, but the text is the same in current versions:

https://docs.python.org/3/library/profile.html

The wording in cProfile.Profile.__cod__ (as per help() etc) is:

For custom timer functions returning integers, timeunit can
be a float specifying a scale (i.e. how long each integer unit
is, in seconds).

Which supports your expectation that this should be "thousandths of a
second". The wording currently in the docs appears to date all the way
back to the introduction of the module in 2006, and other than
formatting changes, hasn't been touched since.

I think your wording would be correct. The file to change is
Doc/library/profile.rst if you want to put in a patch.

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

[Python-Dev] [RELEASE] Python 2.7.17 release candidate 1

2019-10-08 Thread Benjamin Peterson 
The first release candidate of Python 2.7.17 is now available for download and 
testing. Python 2.7.17 includes 80 fixes over Python 2.7.16.

Downloads may be found on python.org:

https://www.python.org/downloads/release/python-2717rc1/

Read the full changelog at:


https://raw.githubusercontent.com/python/cpython/1c7b14197b10924e2efc1e6c99c720958be1f681/Misc/NEWS.d/2.7.17rc1.rst

As always with prereleases, please test your applications and libraries and 
report bugs to:

https://bugs.python.org/

A final release is scheduled to follow in 12 days.

PEP 373, the Python 2.7 release schedule, calls for 2.7.17 to be the 
penultimate bug fix release of the Python 2.7 series. Time for Python 2 is 
running low!

Regards,
Benjamin
2.7 release manager
___
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/ARKAZWUM3HAGLDDCJW2BMJMCDF5UJS5U/
Code of Conduct: http://python.org/psf/codeofconduct/