I'm suggesting a modification to the AttributeError/__getattr__ mechanism,
I used __getattr__ sometimes, and *descriptor* especially *property* is so
widely used. I wonder whether someone
had encountered the same problem with me.
However, this is a complicated problem including performance issues, and
Thanks for your attention,
On Nov 24, 2015 6:28 AM, "Laura Creighton" <lac(a)openend.se> wrote:
> In a message of Tue, 24 Nov 2015 14:05:53 +0000, Paul Moore writes:
> >Simply adding "people who have no control over their broken
> >infrastructure" with a note that this PEP helps them, would be
> >sufficient here (and actually helps the case for the PEP, so why not?
> But does it help them? Or does it increase the power of those who
> hand out certificates and who are intensely security conscious over
> those who would like to get some work done this afternoon?
My reading is that it will help more people but lockdown environments can
still trump their users if they wish.
If a distribution wishes to give users of older python versions the option
of verifying certificates then they will need to backport changes
authorized by previous peps. By themselves, those changes would make it so
environment owners and application authors are in complete control. If an
application is coded to do cert verification and the remote end has
certificates that aren't recognized as valid on the client end then the
user would have to change the client application code to be able to use it
in their environment (or figure out how to get the ca for the remote end
into their local certificate store... in extreme cases, this might be
impossible - the ca cert has been lost or belongs to another company).
This pep tells distributions how they might give the client end a bit more
power when they backport. The settings file allows the client to toggle
verification site wide. The environment variable allows clients to toggle
it per application invocation. Both of these situations are better for a
client than having the backport and nothing else. Both of these can be
shut down by an environment owner with sufficient authority to limit what's
running on the client (not sure the scope of the environment owner's powers
here so I thought I should acknowledge this factor).
So basically: backporting other peps (to increase security) will subtract
power from the clients. This pep specifies several facilities the
backporters can implement to give some of that power back to the clients.
collections.Counter.__add__ as a bit of a quirk.
Counters allow for negative numbers. You can subtract from a counter
into the negative no problem. However, if you have a counter with a
negative value and add it to another counter, and if that value, after
addition, would still be negative... that value is not included in the
resulting Counter object. This is kind of weird, to the point of
thinking I had a bug in other code for several hours until I went and
checked how Counters are implemented.
Is there any particular reason counters drop negative values when you
add them together? I definitely expected them to act like ints do when
you add negatives, and had to subclass it to get what I think is the
3.5.1rc1 is tagged, merged, and pushed back into the central repo. At
this point I don't plan to merge further changes from hg.python.org into
3.5.1 final. If you have an important bug fix that didn't make it into
3.5.1rc1 and *has* to go into 3.5.1 final, add me to the issue and we'll
talk about it. If it happens I'll have to manually cherry-pick the change.
I've added a 3.5.2rc1 section to Misc/NEWS; please add new entries there.
On behalf of the Python development community and the Python 3.5 release
team, I'm pleased to announce the availability of Python 3.5.1rc1.
Python 3.5.1 will be the first update for Python 3.5. Python 3.5 is the
newest version of the Python language, and it contains many exciting new
features and optimizations.
You can see what's changed in Python 3.5.1rc1 (as compared to 3.5.0) here:
And you can download Python 3.5.1 here:
Windows and Mac users: please read the important platform-specific
"Notes on this release" section near the end of that page.
We hope you enjoy Python 3.5.1!
Sorry for the short notice of this schedule, but... here goes:
Sat Dec 05 - tag 3.4.4rc1
Sun Dec 06 - release 3.4.4rc1
Sat Dec 19 - tag 3.4.4 final
Sun Dec 20 - release 3.4.4 final
The reason for the short notice: we may have to change personnel for
this release, and we need to work around some holiday vacation schedules
too. However, note that we have two weeks for the RC release. Because
of the short notice, I plan to be a little more flexible about changes
between RC1 and final. It also means we can pretty easily add a second
RC if we need to.
Unless something amazing happens, 3.4.4 will be the final release of 3.4
with binary installers. 3.4 will also move into "security fixes only"
mode at that time.
Best wishes, and again my apologies for the short notice,
It is my duty and honor to announce the immediate availability of Python
2.7.11 release candidate 1. Python 2.7.11 will be another bug fix
release for the 2.7.x series.
Downloads are at:
Please test the candidate and report bugs to
If no serious problems are found, 2.7.11 final will be released in two
(on behalf of Python 2.7.11's contributors)
For anyone interested in tickling the low-level CPython
internals (in this case eval loop and generators
implementations), here's an interesting bug:
I have a patch that fixes it, but I'm not sure that it's
correct, and I desperately need someone to review it.
While debugging the issue, I found another oddity:
class MainError(Exception): pass
class SubError(Exception): pass
coro = main()
On the last line of the above snippet, SubError will
propagate. However, it won't have it's __context__ set
to MainError. Martin Panter suggests that it's not a bug,
and after giving this some thought, I now don't think it's
a bug too -- SubError was instantiated outside of MainError
from a code location where there was no error. Thoughts?
Here's a separate issue for the __context__ bug/feature: