PEP 1 states that plain/text is an acceptable value for a PEP's content
type, and it is the default value if no content type is specified.
May I propose adding something along the line of: "new PEPs should use
restructured Text format", and that reST format becomes the default.
Based on couple tickets in peps repo, it seems like the reST format is
preferred anyway, and there have been thoughts about converting text based
PEPs into reST format
I hope this is not too controversial.
Discussed this with Guido earlier. He is supportive, and asked me to send
email to python-dev :)
The documentation for PyWeakref_GetObject() states:
Return value: Borrowed reference.
Return the referenced object from a weak reference, ref. If the
referent is no longer live, returns Py_None.
Given that the weakref doesn't have a reference to the object--merely a
weak reference, different thing--whose reference is it borrowing?
FWIW, yes, this is playing merry hell with the Gilectomy. If there are
two threads, and one calls PyWeakref_GetObject(obj), and there's only
one reference to obj, and the other thread blows it away... now what?
It's my contention that this API is simply untenable under the
Gilectomy, and that it needs to change to returning a new (strong)
I work with a full-stack web development bootcamp. Most of the course
one-week period in which each student gets to pick some technology to
learn, and at the end of the week, demos to the group some project
s/he has mastered. Two chose to learn Python, and I've been mentoring
them through this week.
The comments from each of them have been fairly glowing. Python is
this incredible thing that has immense power and flexibility;
significant-whitespace hasn't been a cause of confusion (not even
mentioned after the first day); and
The most notable features of Python, for these two
JS-only-up-until-now guys, are the simplicity of the 'for' loop
(including that you don't need lots of different forms - you can
iterate over a dictionary without having to learn some new type of
loop), the list comprehension, and metaprogramming - mainly function
decorator syntax. And both of them are starting to talk about being
"converts" to Python :)
Great job, all. Not that it's particularly difficult to compete with a
language that was originally designed and developed in under two
weeks, but still. :D
I posted here a while back asking what you guys thought about implementing
radix sort for strings in list.sort(). You gave me a lot of reasons why
that would be a bad idea. However, it got me thinking, and I came up with
something that you may find interesting.
First, some simple benchmark results (numbers are seconds, check out the
extension module at https://github.com/embg/python-fast-listsort.git):
*** 1e3 ints ***
*** 1e3 strings ***
*** 1e7 ints ***
*** 1e7 strings ***
The optimization uses the fact that, in practice, we are almost always
sorting keys of the same type (note: not objects of the same type, *keys*
of the same type; we could have a complex key function like str that takes
many different types, but the keys are still all the same type). So we can
just do one typecheck up front and then do unsafe comparisons during the
sort (if our initial check passes). Specifically, we check that for all the
PyObject* in saved_ob_item, the ob->ob_type are the same. Then we replace
PyObject_RichCompare with ob_type->tp_richcompare. Additionally, we can
check for the very common cases of ints and strings and give optimized
comparison functions for those cases. It might not seem like this would
save a lot of time, but it turns out that PyObject_RichCompare is a massive
clusterf**k that has to test tons of type stuff before it can actually
compare. Cutting that out ends up saving a *lot* of time, as the benchmark
What do you think? I'm planning on writing this up into a patch, but wanted
to get some feedback on the implementation and ideas for improvement first.
Hit "Reply" instead of "Reply All" last night, oops. Forwarding to the
list for posterity's sakes.
-------- Forwarded Message --------
Subject: Re: [Python-Dev] PyWeakref_GetObject() borrows its reference
Date: Mon, 10 Oct 2016 23:01:10 +0200
From: Larry Hastings <larry(a)hastings.org>
To: Nathaniel Smith <njs(a)pobox.com>
On 10/10/2016 07:50 PM, Nathaniel Smith wrote:
> If we say that borrowing reference from a dict is one of the things
> that counts as mucking about with that dict, and thus requires you to
> hold the dict lock for as long as you hold the borrowed reference,
> then all should be well.
That's not how locking works in the Gilectomy right now. If you call
PyDict_GetItem(), it locks the dict at the beginning, then looks up the
thingy, then releases the lock just before returning. It's hard for me
to imagine how the dict would magically know when it could drop the
borrowed reference returned by PyDict_GetItem().
> I assume Larry is way ahead of us on this,
I would say "that's your first mistake!" but I bet you've made others.
Anyway, tbh most of the time I feel awfully unqualified to work on the
Fools rush in,
This is what I've bumped into just now:
python setup.py upload_sphinx --upload-dir=docs/_build/html
Submitting documentation to https://upload.pypi.org/legacy/
Upload failed (410): Uploading documentation is no longer supported, we
recommend using https://readthedocs.org/.
Personally I prefer pythonhosted over readthedocs as I can provide the same
style as official Python's doc (see https://pythonhosted.org/psutil/) and,
most importantly, because I can automatize doc upload just by running "make
Is there a reason upload functionality has been disabled?
Is pythonhosted.org going to be dismissed or something?
Giampaolo - http://grodola.blogspot.com
On behalf of the Python development community and the Python 3.6 release
team, I'm happy to announce the availability of Python 3.6.0b2. 3.6.0b2
is the second of four planned beta releases of Python 3.6, the next major
release of Python, and marks the end of the feature development phase
Among the new major new features in Python 3.6 are:
* PEP 468 - Preserving the order of **kwargs in a function
* PEP 487 - Simpler customization of class creation
* PEP 495 - Local Time Disambiguation
* PEP 498 - Literal String Formatting
* PEP 506 - Adding A Secrets Module To The Standard Library
* PEP 509 - Add a private version to dict
* PEP 515 - Underscores in Numeric Literals
* PEP 519 - Adding a file system path protocol
* PEP 520 - Preserving Class Attribute Definition Order
* PEP 523 - Adding a frame evaluation API to CPython
* PEP 524 - Make os.urandom() blocking on Linux (during system startup)
* PEP 525 - Asynchronous Generators (provisional)
* PEP 526 - Syntax for Variable Annotations (provisional)
* PEP 528 - Change Windows console encoding to UTF-8 (provisional)
* PEP 529 - Change Windows filesystem encoding to UTF-8 (provisional)
* PEP 530 - Asynchronous Comprehensions
Please see "What’s New In Python 3.6" for more information:
You can find Python 3.6.0b2 here:
Beta releases are intended to give the wider community the opportunity
to test new features and bug fixes and to prepare their projects to
support the new feature release. We strongly encourage maintainers of
third-party Python projects to test with 3.6 during the beta phase and
report issues found to bugs.python.org as soon as possible. While the
release is feature complete entering the beta phase, it is possible that
features may be modified or, in rare cases, deleted up until the start
of the release candidate phase (2016-12-05). Our goal is have no changes
after rc1. To achieve that, it will be extremely important to get as
much exposure for 3.6 as possible during the beta phase. Please keep in
mind that this is a preview release and its use is not recommended for
The next planned release of Python 3.6 will be 3.6.0b3, currently
scheduled for 2016-10-31. More information about the release schedule
can be found here:
nad(a)python.org -- 
Since dict is ordered in CPython 3.6, it can be used instead of
OrderedDict in some places (e.g. for implementing simple limited
caches). But since this is implementation detail, it can't be used in
the stdlib unconditionally. Needed a way to check whether dict is ordered.
Actually there are two levels of "ordering".
1. Dict without deletions is iterated in the order of adding items.
Raymond's original compact dict implementation satisfied this claim.
2. In addition the order is preserved after deletion operations. Naoki's
implementation satisfies this more strong claim.