I am Surya, studying final year of Engineering. I have looked into Core
Python's ideas list and got interested in Email module.
I've been working on Django over the past few years, and now like to work
on slightly a different layer of protocols and this idea happened to be it.
That said, I have been just using the Email module earlier along with other
similar modules and never dwell into the internal protocol standards before.
It would be great if someone initially can let me know what documentation I
should start reading to get up to the speed and probably bugs related to
this idea I can look into.
Also, I am looking forward to talk about the project with the mentor!
I think I'm about ready to ask for pronouncement for this PEP, but I would like opinions on the Open Questions question
so I can close it. :)
Please let me know if anything else needs tweaking.
Title: Adding % formatting to bytes and bytearray
Author: Ethan Furman <ethan(a)stoneleaf.us>
Type: Standards Track
Post-History: 2014-01-14, 2014-01-15, 2014-01-17, 2014-02-22
This PEP proposes adding % formatting operations similar to Python 2's ``str``
type to ``bytes`` and ``bytearray`` _ _.
While interpolation is usually thought of as a string operation, there are
cases where interpolation on ``bytes`` or ``bytearrays`` make sense, and the
work needed to make up for this missing functionality detracts from the overall
readability of the code.
With Python 3 and the split between ``str`` and ``bytes``, one small but
important area of programming became slightly more difficult, and much more
painful -- wire format protocols _.
This area of programming is characterized by a mixture of binary data and
ASCII compatible segments of text (aka ASCII-encoded text). Bringing back a
restricted %-interpolation for ``bytes`` and ``bytearray`` will aid both in
writing new wire format code, and in porting Python 2 wire format code.
In order to avoid the problems of auto-conversion and Unicode exceptions
that could plague Python 2 code, :class:`str` objects will not be supported as
interpolation values _ _.
Proposed semantics for ``bytes`` and ``bytearray`` formatting
All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
``%g``, etc.) will be supported, and will work as they do for str, including
the padding, justification and other related modifiers.
>>> b'%4x' % 10
>>> '%#4x' % 10
>>> '%04X' % 10
``%c`` will insert a single byte, either from an ``int`` in range(256), or from
a ``bytes`` argument of length 1, not from a ``str``.
>>> b'%c' % 48
>>> b'%c' % b'a'
``%s`` is restricted in what it will accept::
- input type supports ``Py_buffer`` _?
use it to collect the necessary bytes
- input type is something else?
use its ``__bytes__`` method _ ; if there isn't one, raise a ``TypeError``
>>> b'%s' % b'abc'
>>> b'%s' % 3.14
Traceback (most recent call last):
TypeError: 3.14 has no __bytes__ method, use a numeric code instead
>>> b'%s' % 'hello world!'
Traceback (most recent call last):
TypeError: 'hello world' has no __bytes__ method, perhaps you need to encode it?
Because the ``str`` type does not have a ``__bytes__`` method, attempts to
directly use ``'a string'`` as a bytes interpolation value will raise an
exception. To use strings they must be encoded or otherwise transformed
into a ``bytes`` sequence::
``%a`` will call :func:``ascii()`` on the interpolated value's :func:``repr()``.
This is intended as a debugging aid, rather than something that should be used
in production. Non-ascii values will be encoded to either ``\xnn`` or ``\unnnn``
``%r`` (which calls ``__repr__`` and returns a :class:`str`) is not supported.
It was suggested to let ``%s`` accept numbers, but since numbers have their own
format codes this idea was discarded.
It has been proposed to automatically use ``.encode('ascii','strict')`` for
``str`` arguments to ``%s``.
- Rejected as this would lead to intermittent failures. Better to have the
operation always fail so the trouble-spot can be correctly fixed.
It has been proposed to have ``%s`` return the ascii-encoded repr when the
value is a ``str`` (b'%s' % 'abc' --> b"'abc'").
- Rejected as this would lead to hard to debug failures far from the problem
site. Better to have the operation always fail so the trouble-spot can be
Originally this PEP also proposed adding format-style formatting, but it was
decided that format and its related machinery were all strictly text (aka
``str``) based, and it was dropped.
Various new special methods were proposed, such as ``__ascii__``,
``__format_bytes__``, etc.; such methods are not needed at this time, but can
be visited again later if real-world use shows deficiencies with this solution.
It has been suggested to use ``%b`` for bytes as well as ``%s``.
- Pro: clearly says 'this is bytes'; should be used for new code.
- Con: does not exist in Python 2.x, so we would have two ways of doing the
same thing, ``%s`` and ``%b``, with no difference between them.
..  http://docs.python.org/2/library/stdtypes.html#string-formatting
..  neither string.Template, format, nor str.format are under consideration
..  https://mail.python.org/pipermail/python-dev/2014-January/131518.html
..  to use a str object in a bytes interpolation, encode it first
..  %c is not an exception as neither of its possible arguments are str
..  http://docs.python.org/3/c-api/buffer.html
examples: ``memoryview``, ``array.array``, ``bytearray``, ``bytes``
..  http://docs.python.org/3/reference/datamodel.html#object.__bytes__
This document has been placed in the public domain.
-----BEGIN PGP SIGNED MESSAGE-----
this looks pretty serious -- and it caught me off guard, too. :(
Next time please inform the Python Security Response Team about any
and all issues that are related to buffer overflows or similar bugs.
In fact please drop a note about anything that even remotely look like
an exploitable issue. Even public bug reports should be forwarded to PSRT.
I have requested a CVE number. How about security releases? The
upcoming 3.3 and 3.4 release should contain the fix (not verified
yet). Python 2.7 to 3.2 will need a security release, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
On 26 Feb 2014 07:04, "r.david.murray" <python-checkins(a)python.org> wrote:
> changeset: 89392:4cd620d8c3f6
> user: R David Murray <rdmurray(a)bitdance.com>
> date: Tue Feb 25 16:03:14 2014 -0500
> whatsnew: DynanicClassAttribute (#19030), Py_SetStandardStreamEncoding
> Adding missing docs for DynamicClassAttribute by copying the docstring.
> doc entry could stand some expansion, which I will note on the issue.
> Doc/library/types.rst | 21 +++++++++++++++++++++
> Doc/whatsnew/3.4.rst | 17 +++++++++++++++++
> 2 files changed, 38 insertions(+), 0 deletions(-)
> diff --git a/Doc/library/types.rst b/Doc/library/types.rst
> --- a/Doc/library/types.rst
> +++ b/Doc/library/types.rst
> @@ -15,6 +15,9 @@
> Python interpreter, but not exposed as builtins like :class:`int` or
> :class:`str` are.
> +Finally, it provides some additional type-related utility classes and
> +that are not fundamental enough to be builtins.
> Dynamic Type Creation
> @@ -220,6 +223,9 @@
> Return a new view of the underlying mapping's values.
> +Additional Utility Classes and Functions
> .. class:: SimpleNamespace
> A simple :class:`object` subclass that provides attribute access to
> @@ -246,3 +252,18 @@
> .. versionadded:: 3.3
> +.. function:: DynamicClassAttribute(fget=None, fset=None, fdel=None,
> + Route attribute access on a class to __getattr__.
> + This is a descriptor, used to define attributes that act differently
> + accessed through an instance and through a class. Instance access
> + normal, but access to an attribute through a class will be routed to
> + class's __getattr__ method; this is done by raising AttributeError.
> + This allows one to have properties active on an instance, and have
> + attributes on the class with the same name (see Enum for an example).
> + .. versionadded:: 3.4
> diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst
> --- a/Doc/whatsnew/3.4.rst
> +++ b/Doc/whatsnew/3.4.rst
> @@ -1270,6 +1270,17 @@
> +A new :func:`~types.DynamicClassAttribute` descriptor provides a way to
> +an attribute that acts normally when looked up through an instance
> +which is routed to the *class* ``__getattr__`` when looked up through the
> +class. This allows one to have properties active on a class, and have
> +attributes on the class with the same name (see :mod:`Enum` for an
> +(Contributed by Ethan Furman in :issue:`19030`.)
> @@ -1512,6 +1523,12 @@
> object allocator have been silenced. (Contributed by Dhiru Kholia in
> +* New function :c:func:`Py_SetStandardStreamEncoding` allows an
> + that is embedding Python to do the equivalent of setting
> + :envvar:`PYTHONIOENCODING`. Its arguments override the equivalent
> + values from :envvar:`PYTHONIOENCODING` if it exists. (Contributed
> + by Bastien Montagne and Nick Coghlan in :issue:`16129`.)
There was an existing entry for this one: second bullet under
> .. _other-improvements-3.4:
> Repository URL: http://hg.python.org/cpython
> Python-checkins mailing list
I want to try to submit a patch for 2.7, but I don't know how to run the
tests for the 2.7 branch. `./configure` doesn't seem to create a
`python.exe` file on the 2.7 branch on OS X Mavericks, and I do need this
file according to this guide:
Anybody know how I should do this?
The Py_CLEAR macros is used as safe alternative for following unsafe
ptr = NULL;
But other unsafe idiomatic code is widely used in the sources:
ptr = new_value;
Every occurrence of such code is potential bug for same reasons as for
It was offered  to introduce new macros Py_REPLACE and Py_XREPLACE
for safe replace with Py_DECREF and Py_XDECREF respectively.
Automatically generated patch contains about 50 replaces .
23.02.14 18:42, r.david.murray написав(ла):
> changeset: 89337:4d615ab37804
> user: R David Murray <rdmurray(a)bitdance.com>
> date: Sun Feb 23 10:22:07 2014 -0500
> whatsnew: textwrap.shorten.
> Also add the missing TextWrapper.shorten method doc.
There is no the TextWrapper.shorten method. The textwrap.shorten()
function is implemented via new max_lines parameter.
Saimadhav Heblikar here.I would like to express my interest in working on
IDLE improvement project as a part of Google Summer of Code 2014 for Python
Core projects under the Python Software Foundation.I am currently a
freshman Computer Science undergraduate student at PESIT , Bangalore.
Similar to most Python programmers, i started my python journey on IDLE,and
once i came to know that IDLE was one of the prospective projects,i knew
this was great opportunity to give back to IDLE and the community as whole.
I have created an account on the bug tracker and submitted the PSF
contributor agreement.My username on the tracker is sahutd(saimadhav
heblikar) http://bugs.python.org/user18939. I use the same nickname on the
To enhance my understanding of the codebase, i have submitted few patches,
some which have been committed
and some which are under review
http://bugs.python.org/issue20403 (IDLE related)
http://bugs.python.org/issue20640 (Adds IDLE unittest)
Coming to the point,as the theme of the project which i am interested in
and the theme for the IDLE GSOC `13 projects by Jayakrishnan and Phil
Webster are the same, i have a few questions to ask the python
1.What will be the scope of the idle gsoc 2014?By scope,i want to
know,whether i will be expected to continue the work done in 2013, or
2. If i were to start afresh,i have explored the following two
a)Code recommender feature for IDLE - Similar to the feature in
Eclipse but made for Python(would work from the shell or in IDLE).As an
example of how it would work,we could think of it as a web api, which would
return information about most used functions in a module.It would help
beginners and experts alike to make better use of their dev time.It would
also go a long way in making python even more social.If any questions on
this proposal,i am looking forward to answer it. (I would like to know the
community's opinion on this,GSOC or otherwise)If this generates a positive
response, i will immediately come up with a plan to develop it.
b)Working on a project to integrate a passive checker like pyflakes
with the ability to highlight and possibly correct errors on-the-fly and on
demand.Automatically integrate the above feature to work on
folders/directories, selection of files ,projects etc.
2.If i were to continue the work done in gsoc 2013,would it involve
a)building on features for PEP8(or other style checker,though after
reading http://bugs.python.org/issue18704 i am inclined to believe it is
not a must have atm. )
b)extending the unittest framework. Would i be completing(or to an
extent) , the missing tests in idlelib/idle_test?What would be the
c)features which don't seem to have been completed from gsoc 2013 like
line numbering,improving cursor behavior and making right click more
intuitive.(Anything gsoc 13 related which i have missed out?)
I believe from the abstracts of GSOC 13 projects which were selected,that
, i am expected to increase test coverage for idle AND add a new feature .
Is my understanding correct?
I would like to know whom i can contact(mentors) if have questions about
the proposal writing and/or other technical questions relating to GSOC 14.
I would also like to come up with overall outline based on your feedback so
that it can critiqued before i submit the application on the google page.
Awaiting your replies.
Bug Tracker username: sahutd (http://bugs.python.org/user18939)
Email : saimadhavheblikar(a)gmail.com
Github : https://github.com/sahutd
On behalf of the Python development team, I'm delighted to announce
the second and final release candidate of Python 3.4.
This is a preview release, and its use is not recommended for
Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvements and bug fixes. Major new features and
changes in the 3.4 release series include:
* PEP 428, a "pathlib" module providing object-oriented filesystem paths
* PEP 435, a standardized "enum" module
* PEP 436, a build enhancement that will help generate introspection
information for builtins
* PEP 442, improved semantics for object finalization
* PEP 443, adding single-dispatch generic functions to the standard library
* PEP 445, a new C API for implementing custom memory allocators
* PEP 446, changing file descriptors to not be inherited by default
* PEP 450, a new "statistics" module
* PEP 451, standardizing module metadata for Python's module import system
* PEP 453, a bundled installer for the *pip* package manager
* PEP 454, a new "tracemalloc" module for tracing Python memory allocations
* PEP 456, a new hash algorithm for Python strings and binary data
* PEP 3154, a new and improved protocol for pickled objects
* PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O
Python 3.4 is now in "feature freeze", meaning that no new features will be
added. The final release is projected for mid-March 2014.
The python.org web site has recently been updated to something
completely new, and I'm having some difficulty updating it. For now
I've made Python 3.4.0rc2 available on the legacy web site:
Once I can update the new web site, Python 3.4.0rc2 will be available here:
(I'm not sure what the final URL will be, but you'll see it listed on
Please consider trying Python 3.4.0rc2 with your code and reporting any
new issues you notice to:
Larry Hastings, Release Manager
larry at hastings.org
(on behalf of the entire python-dev team and 3.4's contributors)