I am beginning to think that `from __future__ import unicode_literals` does
more harm than good. I don't recall exactly why we introduced it, but with
the restoration of u"" literals in Python 3.3 we have a much better story
for writing straddling code that is unicode-correct.
The problem is that the future import does both too much and not enough --
it does too much because it changes literals to unicode even in contexts
where there is no benefit (e.g. the argument to getattr() -- I still hear
of code that breaks due to this occasionally) and at the same time it
doesn't do anything for strings that you read from files, receive from the
network, or even from other files that don't use the future import.
I wonder if we can add an official note to the 2.7 docs recommending
against it? (And maybe even to the 3.x docs if it's mentioned there at all.)
--
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
Hi,
I made multiple changes to the Include/abstract.h header file, because
it was inconsistent in different manners:
* Parameter names of functions of the PyObject_Call family were
inconsistent: "func" versus "callable" for a Python callable object
for example (sometimes, .c and .h files were inconsistent too)
* Only this header file used an indentation of 4 spaces in the whole space
* Only this header used comments *after* the function declaration and
with a newline between the comment and the declaration. Other headers
use a comment *before* the declaration and no newline.
* Some comments were far (100 lines) from function declaration, so it
wasn't possible anymore to understand these comments.
* Other tiny changes
Before:
https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h
Now:
https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h
(Not sure that it's easy to compare such long header file, ~1 200
lines, in a web browser.)
See http://bugs.python.org/issue28838 for more information.
Serhiy Storchaka was opposed to these changes, some extract of his comments:
* "Isn't this just a lot of churn for not a lot of benefit?" - Eric V.
Smith asked the same question
* "It breaks "hg annotation" and makes harder researching the history
of the file"
I already pushed all my changes anyway, but Serhiy asked me to discuss
these changes on Python-Dev, so here I am.
I decided to cleanup abstract.h because I had to modify it multiple
times last 2 years, especially when I added new functions for fast
calls, and I was always surprised and confused by the style of header.
I didn't know how to format my code, and it seems like I also
introduced some inconsistent coding style in the newly added code.
For the first change that I made recently, normalizing parameter
names, I first pushed directly a change without review, but Serhiy
asked me on this list to revert it. So I reverted the change and
continued the discussion on the issue #28838. We agreed on better
names, and so I pushed a different change.
Victor
Originally C API didn't use the const qualifier. Over few last years the
const qualifier was added to C API if that preserved backward
compatibility. For example input "char *" parameters were changed to
"const char *". This makes C API compatible with C++, eliminates C
compiler warnings, and helps to found possible errors.
Now I have started to make changes that are not absolute compatible, and
can need modifying third-party code (but unlikely).
* The const qualifier was added to "char *" fields name and doc of some
structures. They always point to C string literals.
https://bugs.python.org/issue28761
* The const qualifier was added to private global variable
_Py_PackageContext. https://bugs.python.org/issue28748
Now I'm going to add the const qualifier to the result of
PyUnicode_AsUTF8AndSize() and PyUnicode_AsUTF8(). These functions return
a reference to internal cached UTF8 representations of a string. It
should never be modified. https://bugs.python.org/issue28769
Later I'm planning following changes:
* Add the const qualifier to the result of functions that return
references to internal representation of immutable objects, like
PyBytes_AS_STRING() or PyUnicode_DATA(). While CPython internally can
modify the content of immutable objets, this is very dangerous, because
this can invalidates invariants and cached values. Third-party code
shouldn't do this.
* Add the const qualifier to the format field of Py_buffer. It is a
reference to C string literal or to the content of bytes object.
Mutating its content is an error. Only _testbuffer overuses the format
field of internal Py_buffer object for owning a reference to allocated
memory. But this is not leaked outside.
What are you think about this?
On 17 December 2016 at 20:39, brett.cannon <python-checkins(a)python.org> wrote:
> https://hg.python.org/cpython/rev/287d4290b1b4
> changeset: 105714:287d4290b1b4
> branch: 2.7
> parent: 105677:eb02db65e148
> user: Brett Cannon <brett(a)python.org>
> date: Sat Dec 17 12:38:54 2016 -0800
> summary:
> Update the porting HOWTO
>
> diff --git a/Doc/howto/pyporting.rst b/Doc/howto/pyporting.rst
> --- a/Doc/howto/pyporting.rst
> +++ b/Doc/howto/pyporting.rst
> . . .
> Have good test coverage
> -----------------------
>
> @@ -106,10 +107,11 @@
> thumb is that if you want to be confident enough in your test suite that any
> failures that appear after having tools rewrite your code are actual bugs in the
> tools and not in your code. If you want a number to aim for, try to get over 80%
> -coverage (and don't feel bad if you can't easily get past 90%). If you
> +coverage (and don't feel bad if you can't easily get passed 90%). If you
> don't already have a tool to measure test coverage then coverage.py_ is
> recommended.
Hi Brett, why did you make the above change (get past → get passed)?
To me, “get past 90%” means achieving over 90%, but “you can’t get
passed 90%” would mean that 90% cannot be given (passed) to you. The
original made more sense. Another option would be “get over 90%”,
consistent with the previous sentence.
It is my pleasure to announce the release of Python 2.7.13, the latest
bugfix release of the venerable Python 2.7 series. This release
incorporates conservative bugfixes as well as improvements to keep
Python 2.7 running on modern systems.
The only change from the 2.7.13 release candidate 2 weeks ago is the
revert of a change that broke backwards compatibility with some rare C
extension patterns. See https://bugs.python.org/issue5322 for more
details.
Source archives and binaries are available at
https://www.python.org/downloads/release/python-2713/
Please report bugs to our tracker:
https://bugs.python.org/
2.7.14 will appear mid-2017.
All the best in the new year,
Benjamin Peterson
2.7 release manager
On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.0rc2. 3.6.0rc2
is the second release candidate for Python 3.6, the next major release of
Python.
Code for 3.6.0 is now frozen. 3.6.0rc2 is the same code base as the first
release candidate, 3.6.0rc1, with the addition of fixes for a couple of
critical problems and with some documentation additions and updates.
Assuming no further release critical problems are found prior to the 3.6.0
final release date, now planned for 2016-12-23, the 3.6.0 final release
will be the same code base as this 3.6.0rc2. Maintenance releases for the
3.6 series will follow at regular intervals starting in the first quarter
of 2017.
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
* PEP 529 - Change Windows filesystem encoding to UTF-8
* PEP 530 - Asynchronous Comprehensions
Please see "What’s New In Python 3.6" for more information:
https://docs.python.org/3.6/whatsnew/3.6.html
You can find Python 3.6.0rc2 here:
https://www.python.org/downloads/release/python-360rc2/
Note that 3.6.0rc2 is still a preview release and thus its use is not
recommended for production environments.
More information about the release schedule can be found here:
https://www.python.org/dev/peps/pep-0494/
--
Ned Deily
nad(a)python.org -- []
[sending this independently to python-dev and core-workflow]
I have promised Ned that we will not migrate before 3.6.0 is released and
not for a week following in case an emergency 3.6.1 is necessary. I also
promised Larry we wouldn't migrate the week before 3.5.3 is released. That
means the windows for migrating are 2016-12-30 to 2017-01-09, and then any
time after 2016-01-16 (this of course assumes all release schedules don't
slip).
I'm now on vacation until January 3 so I will have time to work on the
migration some more. I will port hg.python.org/lookup to work with git, hg,
and svn probably this week or next. That leaves the only true blockers as
http://psf.upfronthosting.co.za/roundup/meta/issue589 and
http://psf.upfronthosting.co.za/roundup/meta/issue590 (webhook for PR to
issue and notifying an issue when a commit has occurred, respectively; we
already have a GitHub PR field on b.p.o for manual entry). Once those
changes to bugs.python.org land and have been tested live against the
GitHub mirror, we can do the migration (which will most likely take a day
or two). All other issues either require the repo to have already been
migrated and working or can wait post-migration (
https://www.python.org/dev/peps/pep-0512/#cpython-repo).
So if the above wasn't clear, if you want to help then please help with the
b.p.o issues as those are the remaining blockers I can't deal with on my
own. And I actually have GitHub-themed gifts I bought myself sitting under
my Xmas tree that I won't open until we migrate, so let's not take too
long. ;)
Hello, this week-end is the last two days for the Call For Proposals of
PythonFOSDEM 2017. We have received a lot of topics, but if you want to
become a speaker and that you have a very cool topic to submit, please
don't hesite and send us your proposal.
Deadline is 2016-12-18.
Stephane
Call For Proposals
==================
This is the official call for sessions for the Python devroom at FOSDEM 2017.
FOSDEM is the Free and Open source Software Developers' European Meeting, a free
and non-commercial two-day week-end that offers open source contributors a place
to meet, share ideas and collaborate.
It's the biggest event in Europe with +5000 hackers, +400 speakers.
For this edition, Python will be represented by its Community.
If you want to discuss with a lot of Python Users, it's the place to be!
Important dates
===============
* Submission deadlines: 2016-12-18
* Acceptance notifications: 2016-12-23
Practical
=========
* The duration for talks will be 30 minutes, including presentations and
questions and answers.
* Presentation can be recorded and streamed, sending your proposal implies
giving permission to be recorded.
* A mailing list for the Python devroom is available for discussions about
devroom organisation. You can register at this address:
https://lists.fosdem.org/listinfo/python-devroom
How to submit
=============
All submissions are made in the Pentabarf event planning tool at
https://penta.fosdem.org/submission/FOSDEM17
When submitting your talk in Pentabarf, make sure to select the Python devroom
as the Track.
Of course, if you already have a user account, please reuse it.
Questions
=========
Any questions, please send an email to info AT python-fosdem DOT org
Thank you for submitting your sessions and see you soon in Brussels to talk
about Python.
If you want to keep informed for this edition, you can follow our twitter
account @PythonFOSDEM.
* FOSDEM 2017: https://fosdem.org/2017
* Python Devroom: http://python-fosdem.org
* Twitter: https://twitter.com/PythonFOSDEM
Stephane
--
Stéphane Wirtel - http://wirtel.be - @matrixise
I'm currently working on http://bugs.python.org/issue25458 .
There are a few options there, and each one has drawbacks.
So, I'd like to get some feedback on which way is prefereable before
working towards any of them and/or other ideas should they arise.
The problem and the options are summarized in
http://bugs.python.org/issue25458#msg283073 and the message after that one.
Apart from the options, I'd like to know if I must solve the 2nd problem
(error handling), too, or it can be handled in a separate ticket.
--
Regards,
Ivan
