Merry Christmas for you who celebrates Christmas! Happy holidays for
you who don't.
Anyway, sometimes when people review my patches for CPython, they send
me a notice through Rietveld Code Review Tool which later will send an
email to me. However, my GMail spam filter is aggressive so the email
will always be classified as spam because it fails spf checking. So if
Taylor Swift clicks 'send email' in Rietveld after reviewing my patch,
Rietveld will send email to me but the email pretends as if it is sent
from taylor(a)swift.com. Hence, failing spf checking.
Take an example where R. David Murray commented on my patch, I
wouldn't know about it if I did not click Spam folder out of the blue.
I remember in the past I had ignored Serhiy Storchaka's advice for
months because his message was buried in spam folder.
Maybe we shouldn't pretend as someone else when sending email through Rietveld?
On Wed, Dec 24, 2014, at 15:59, Terry Reedy wrote:
> On 12/24/2014 2:59 PM, benjamin.peterson wrote:
> > https://hg.python.org/cpython/rev/2c87dd2d821e
> > changeset: 93958:2c87dd2d821e
> > branch: 3.4
> > parent: 93955:08972a47f710
> > user: Benjamin Peterson <benjamin(a)python.org>
> > date: Wed Dec 24 13:58:05 2014 -0600
> > summary:
> > improve incorrect French (#23109)
> > Following suggestions from Clément.
> > files:
> > Doc/howto/unicode.rst | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> > diff --git a/Doc/howto/unicode.rst b/Doc/howto/unicode.rst
> > --- a/Doc/howto/unicode.rst
> > +++ b/Doc/howto/unicode.rst
> > @@ -32,8 +32,8 @@
> > In the mid-1980s an Apple II BASIC program written by a French speaker
> > might have lines like these::
> > - PRINT "FICHIER EST COMPLETE."
> > - PRINT "CARACTERE NON ACCEPTE."
> > + PRINT "MISE A JOUR TERMINEE"
> > + PRINT "PARAMETRES ENREGISTRES"
> > Those messages should contain accents (completé, caractère, accepté),
> It seems that this list should have been changed also, to the words that
> need accents in the replacement.
Good point. Thank you.
On Fri, Dec 19, 2014 at 5:39 AM, Guido van Rossum <guido(a)python.org> wrote:
>---------- Forwarded message ----------
> From: Victor Stinner <victor.stinner(a)gmail.com>
> Yes, the link is dead. It looks like the following link contains the same
> Dead page:
> "Core Development > Issue Workflow"
Edits made to PEP 3, link now updated. Noticed along the way that the
next link down (for people _submitting_ bugs) is pointing to the /2/
section of the docs; should that be updated to send people to /3/, or
are the two kept in sync?
Don't remember where to ask for changing the redirection of that
domain name. Somebody knows?
I need for the redirection to be to pycon.python.org.ar (and we'll
take care of proper year-by-year redirection from there).
On Thu, Dec 18, 2014, at 14:50, Maciej Fijalkowski wrote:
> well, the problem is essentially that libffi gets patched (e.g. for
> ARM) and it does not make it's way to CPython quickly. This is
> unlikely to be a security issue (for a variety of reasons, including
> ctypes), but it's still an issue I think. Segfaults related to e.g.
> stack alignment are hard to debug
Certainly it's a suboptimal situation, but resolving it requires someone
to figure out whether we still need/want whatever patches are in there.
Hello my name is Raymond and I would like to fix a broken link on pep 3. If
you go to
https://www.python.org/dev/peps/pep-0003/ and click on link
http://www.python.org/dev/workflow/, it returns a 404.
What is the correct url? Should we also update the description "It has
been replaced by the Issue Workflow"?
After I'll get the correct answers, I will submit a patch.
Thanks for your help.
The recent release of setuptools 8.0 brought with it the migration to
the more explicit version handling semantics defined in PEP 440.
Some of the feedback on that release showed us that we could really
use the equivalent of PEP 411 for interoperability PEPs as well as for
standard library modules: a way to say "this is well defined enough
for us to publish a reference implementation in the default packaging
tools, but needs additional user feedback before we consider it
The reasons for this are mostly pragmatic: the kinds of tweaks we're
talking about are small (in this specific case, changing the
normalised form when publishing release candidates from 'c' to 'rc' ,
when installation tools are already required to accept either spelling
as valid), but updating hyperlinks, other documentation references,
etc means that spinning a full PEP revision just for that change would
be excessively expensive in contributor time and energy.
So over on distutils-sig, we're currently considering PEP 440
provisional until we're happy with the feedback we're receiving on
setuptools 8.x and the upcoming pip 6.0 release.
However, I'd be happier if we could communicate that status more
explicitly through the PEP process, especially as I think such a
capability would be useful more generally as we move towards
implementing metadata 2.0 and potentially other enhancements for pip
7+ next year.
If folks are OK with this idea, I'll go ahead and make the appropriate
changes to PEP 1 and the PEP index generator. I'm also happy to file a
tracker issue, or write a short PEP, if folks feel making such a
change requires a little more formality in its own right.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Recently when I am writing a computer algebra system for a very special
purpose, it is found that being able to have objects of user-defined
classes immutable can be very nice. It would greatly enhance the safety of
the code. For example in the code that I were writing, objects hold a lot
of references to other objects of user-defined class. If other parts of the
code mutates the objects that is referenced, quite expected things could
As a result, an initial tentative implementation of a metaclass for making
objects of user-defined classes immutable is written and put into a Github
repository https://github.com/tschijnmo/immutableclass. Since I am not a
python expert yet, could you please help me
1. If such a metaclass is Pythonic? Is it considered a good practice to use
such a metaclass in a code that needs frequent maintenance?
2. Is this metaclass of interest to other Python developers as well? I mean
is it worth-while to try to put this, or something like this, into the
standard Python library?
3. If the answer to the above questions are affirmative, is my current
implementation Pythonic? Especially if it is better implemented as a class
decorator rather than a metaclass?
Most of the code should be quite straightforward. It is mimicked after the
named tuple in the collections library. Just for the initialization,
basically what I did is to make a mutable proxy class for every immutable
class. This proxy class is attempted to carry as much behaviour of the
immutable class as possible, except it is mutable.Then the initializer
defined by users are in fact called with self being an instance of the
proxy class, then the actual immutable object is built out of it.
This is my first time posting to this list. Any feedback is greatly
appreciated. Thank you!