[Python-Dev] Volunteer
You may remember me from a couple of years ago when I was trying to help out with Python. Unfortunately I trod on a few toes. I now know why. I have been diagnosed with Asperger Syndrome at 55 years old. I would like to give it another go. -- Cheers. Mark Lawrence. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer
On 2/5/2012 12:44 PM, Blockheads Oi Oi wrote: You may remember me from a couple of years ago when I was trying to help out with Python. Unfortunately I trod on a few toes. I now know why. I have been diagnosed with Asperger Syndrome at 55 years old. I would like to give it another go. Hi Mark, I noticed you posting recently in python-list. Welcome back. I will let others speak for themselves as far as the tracker goes. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
In article , georg.brandl wrote: > +Bugfix Releases > +=== > + > +- 3.2.1: released July 10, 2011 > +- 3.2.2: released September 4, 2011 > + > +- 3.2.3: planned February 10-17, 2012 I would like to propose that we plan for 3.2.3 and 2.7.3 immediately after PyCon, so approximately March 17, if that works for all involved. My primary rationale is to allow time to address all of the OS X Xcode 4 issues for 10.6 and 10.7. They need to be fixed in 2.7.x, 3.2.x, and 3.3: right now it is not possible to build C extension modules in some sets of configurations. As I mentioned the other day, it is going to take a few more weeks to finish testing and generate all the fixes. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
2012/2/5 Ned Deily : > In article , > georg.brandl wrote: >> +Bugfix Releases >> +=== >> + >> +- 3.2.1: released July 10, 2011 >> +- 3.2.2: released September 4, 2011 >> + >> +- 3.2.3: planned February 10-17, 2012 > > I would like to propose that we plan for 3.2.3 and 2.7.3 immediately > after PyCon, so approximately March 17, if that works for all involved. > My primary rationale is to allow time to address all of the OS X Xcode 4 > issues for 10.6 and 10.7. They need to be fixed in 2.7.x, 3.2.x, and > 3.3: right now it is not possible to build C extension modules in some > sets of configurations. As I mentioned the other day, it is going to > take a few more weeks to finish testing and generate all the fixes. The reason 3.2.3 is so soon is the need to patch the hash collision attack. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
On Feb 5, 2012, at 20:25 , Benjamin Peterson wrote: > 2012/2/5 Ned Deily : >> In article , >> georg.brandl wrote: >>> +Bugfix Releases >>> +=== >>> + >>> +- 3.2.1: released July 10, 2011 >>> +- 3.2.2: released September 4, 2011 >>> + >>> +- 3.2.3: planned February 10-17, 2012 >> >> I would like to propose that we plan for 3.2.3 and 2.7.3 immediately >> after PyCon, so approximately March 17, if that works for all involved. >> My primary rationale is to allow time to address all of the OS X Xcode 4 >> issues for 10.6 and 10.7. They need to be fixed in 2.7.x, 3.2.x, and >> 3.3: right now it is not possible to build C extension modules in some >> sets of configurations. As I mentioned the other day, it is going to >> take a few more weeks to finish testing and generate all the fixes. > > The reason 3.2.3 is so soon is the need to patch the hash collision attack. I understand that but, to me, it makes no sense to send out truly broken releases. Besides, the hash collision attack is not exactly new either. Another few weeks can't make that much of a difference. -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
I understand that but, to me, it makes no sense to send out truly broken releases. Besides, the hash collision attack is not exactly new either. Another few weeks can't make that much of a difference. Why would the release be truly broken? It surely can't be worse than the current releases (which apparently aren't truly broken, else there would have been no point in releasing them back then). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
In article <[email protected]>, [email protected] wrote: > > I understand that but, to me, it makes no sense to send out truly > > broken releases. Besides, the hash collision attack is not exactly > > new either. Another few weeks can't make that much of a difference. > > Why would the release be truly broken? It surely can't be worse than > the current releases (which apparently aren't truly broken, else > there would have been no point in releasing them back then). They were broken by the release of OS X 10.7 and Xcode 4.2 which were subsequent to the previous releases. None of the currently available python.org installers provide a fully working system on OS X 10.7, or on OS X 10.6 if the user has installed Xcode 4.2 for 10.6. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
On Mon, Feb 6, 2012 at 5:45 AM, wrote: > >> I understand that but, to me, it makes no sense to send out truly broken >> releases. Besides, the hash collision attack is not exactly new either. >> Another few weeks can't make that much of a difference. > > > Why would the release be truly broken? It surely can't be worse than > the current releases (which apparently aren't truly broken, else > there would have been no point in releasing them back then). Because Apple wasn't publishing versions of gcc-llvm that miscompile Python when those releases were made. (However, that's just a clarification of what changed to break the Mac OS X builds, I don't think it's a reason to hold up the hash security fix, even if it means spinning 3.2.4 not long after PyCon to sort out the XCode build problems). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
In article , Nick Coghlan wrote: > Because Apple wasn't publishing versions of gcc-llvm that miscompile > Python when those releases were made. More importantly, Apple removed gcc-4.2 with the current versions of Xcode 4 and the Pythons installed by our current installers require gcc-4.2 to build extension modules. That will be changed but the situation is much more complex than when the previous set of releases went out. > (However, that's just a > clarification of what changed to break the Mac OS X builds, I don't > think it's a reason to hold up the hash security fix, even if it means > spinning 3.2.4 not long after PyCon to sort out the XCode build > problems). I don't think it is a service to any of our users to hurry out two releases with minimal testing and with the knowledge that a major platform is crippled and with the expectation that another set of releases will be issued within 4 to 6 weeks, all just because of a fairly obscure problem that has been around for years (even if not publicized). Releases add a lot of work and risk for everyone in the Python chain, especially distributors of Python and end-users. That's just my take on it, of course. I can live with either option. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Volunteer
Blockheads Oi Oi writes: > I would like to give it another go. Welcome back. Your signature shows the name “Mark Lawrence”. It would help with initial impressions if your ‘From’ field, instead of the pseudonym currently shown, shows your name. Could you please change it to that? -- \“I washed a sock. Then I put it in the dryer. When I took it | `\ out, it was gone.” —Steven Wright | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
On Feb 05, 2012, at 02:25 PM, Benjamin Peterson wrote: >The reason 3.2.3 is so soon is the need to patch the hash collision attack. Also remember that we are coordinating releases between several versions of Python for this issue, some of which are in security-only mode. The RMs of the active stable branches agree it's best to get these coordinated security releases out as soon as possible. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
Paul Moore wrote:
On 4 February 2012 11:25, Steven D'Aprano wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise "preview" modules in the std lib. Could we have a recommendation
in PEP 8 that such modules should have a global variable called PREVIEW, and
non-preview modules should not, so that the recommended way of telling them
apart is with hasattr(module, "PREVIEW")?
In what situation would you want that when you weren't referring to a
specific module? If you're referring to a specific module and you
really care, just check sys.version. (That's annoying and ugly enough
that it'd probably make you thing about why you are doing it - I
cannot honestly think of a case where I'd actually want to check in
code if a module is a preview - hence my question as to what your use
case is).
What's the use-case for any sort of introspection functionality? I would say
that the ability to perform introspection is valuable in and of itself,
regardless of any other concrete benefits.
We expect that modules may change APIs between the preview and non-preview
("stable") releases. I can see value in (say) being forewarned of API changes
from the interactive interpreter, without having to troll through
documentation looking for changes, or waiting for an exception. Or having to
remember exactly which version modules were added in, and when they left
preview. (Will this *always* be one release later? I doubt it.)
If you don't believe that preview modules will change APIs, or that it would
be useful to detect this programmatically when using such a module, then
there's probably nothing I can say to convince you otherwise. But I think it
will be useful. Python itself has a sys.version so you can detect feature sets
and changes in semantics; this is just the same thing, only milder.
The one obvious way[1] is to explicitly tag modules as preview, and the
simplest way to do this is with an attribute. (Non-preview modules shouldn't
have the attribute at all -- non-preview is the default state, averaged over
the entire lifetime of a module in the standard library.)
It would be just nice to sit down at the interactive interpreter and see
whether a module you just imported was preview or not, without having to look
it up in the docs. I do nearly everything at the interpreter: I read docs
using help(), I check where modules are located using module.__file__. This is
just more of the same.
Some alternatives:
1) Don't try to detect whether it is a preview module, but use EAFP to detect
features that have changed:
try:
result = spam.foo(x, y)
except AttributeError:
# Must be a preview release. Do something else.
result = spam.bar(y, x)
This is preferred so long as the differences between preview and stable
releases are big, obvious changes like a function being renamed. But if there
are subtle changes that you care about, things get dicey. spam.foo may not
raise an exception, but just do something completely unexpected.
2) As you suggest, write version-specific code:
if sys.version >= "3.4":
result = spam.foo(x, y)
else:
# Preview release.
result = spam.bar(y, x)
This starts to get messy fast, particularly if (worst case, and I *really*
hope this doesn't happen!) modules get put into preview, then get withdrawn,
then a few releases later get put back in. This sort of mess shouldn't ever
happen with non-preview modules, but preview modules explicitly have weaker
guarantees.
And I can never remember when modules were added to the std lib.
Feels like YAGNI to me.
When people talk about YAGNI, they are referring to the principle that you
shouldn't waste time and effort over-engineering a complex solution or
providing significant additional functionality for no obvious gain. I don't
think that
PREVIEW = True
in a module *quite* counts as over-engineered.
[1] Disclaimer: I am not Dutch.
--
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.2): remove unused import
I'm going to assume pylint or pyflakes would throw too many warnings on the stdlib, but would it be worth someone's time to write a simple unused import checker to run over the stdlib on occasion? I bet even one that did nothing more than a regex search for matched import statements would be good enough. On Fri, Feb 3, 2012 at 19:09, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/9eb5fec8674b > changeset: 74749:9eb5fec8674b > branch: 3.2 > parent: 74746:5eb47e1732a0 > user:Benjamin Peterson > date:Fri Feb 03 19:07:30 2012 -0500 > summary: > remove unused import > > files: > Lib/threading.py | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > > diff --git a/Lib/threading.py b/Lib/threading.py > --- a/Lib/threading.py > +++ b/Lib/threading.py > @@ -5,7 +5,6 @@ > > from time import time as _time, sleep as _sleep > from traceback import format_exc as _format_exc > -from collections import deque > from _weakrefset import WeakSet > > # Note regarding PEP 8 compliant names > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): remove unused import
Am 06.02.2012 01:39, schrieb Brett Cannon: > I'm going to assume pylint or pyflakes would throw too many warnings on > the stdlib, but would it be worth someone's time to write a simple > unused import checker to run over the stdlib on occasion? I bet even one > that did nothing more than a regex search for matched import statements > would be good enough. Zope 3 has an import checker that uses the compiler package and AST tree to check for unused imports. It seems like a better approach than a simple regex search. http://svn.zope.org/Zope3/trunk/utilities/importchecker.py?rev=25177&view=auto The importorder tool uses the tokenizer module to order import statements. http://svn.zope.org/Zope3/trunk/utilities/importorder.py?rev=25177&view=auto Both are written by Jim Fulton. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
On Feb 5, 2012 5:36 PM, "Steven D'Aprano" wrote:
>
> Paul Moore wrote:
>>
>> On 4 February 2012 11:25, Steven D'Aprano wrote:
>>>
>>> It strikes me that it would be helpful sometimes to programmatically
>>> recognise "preview" modules in the std lib. Could we have a
recommendation
>>> in PEP 8 that such modules should have a global variable called
PREVIEW, and
>>> non-preview modules should not, so that the recommended way of telling
them
>>> apart is with hasattr(module, "PREVIEW")?
>>
>>
>> In what situation would you want that when you weren't referring to a
>> specific module? If you're referring to a specific module and you
>> really care, just check sys.version. (That's annoying and ugly enough
>> that it'd probably make you thing about why you are doing it - I
>> cannot honestly think of a case where I'd actually want to check in
>> code if a module is a preview - hence my question as to what your use
>> case is).
>
>
> What's the use-case for any sort of introspection functionality? I would
say that the ability to perform introspection is valuable in and of itself,
regardless of any other concrete benefits.
>
> We expect that modules may change APIs between the preview and
non-preview ("stable") releases. I can see value in (say) being forewarned
of API changes from the interactive interpreter, without having to troll
through documentation looking for changes, or waiting for an exception. Or
having to remember exactly which version modules were added in, and when
they left preview. (Will this *always* be one release later? I doubt it.)
>
> If you don't believe that preview modules will change APIs, or that it
would be useful to detect this programmatically when using such a module,
then there's probably nothing I can say to convince you otherwise. But I
think it will be useful. Python itself has a sys.version so you can detect
feature sets and changes in semantics; this is just the same thing, only
milder.
>
> The one obvious way[1] is to explicitly tag modules as preview, and the
simplest way to do this is with an attribute. (Non-preview modules
shouldn't have the attribute at all -- non-preview is the default state,
averaged over the entire lifetime of a module in the standard library.)
>
> It would be just nice to sit down at the interactive interpreter and see
whether a module you just imported was preview or not, without having to
look it up in the docs. I do nearly everything at the interpreter: I read
docs using help(), I check where modules are located using module.__file__.
This is just more of the same.
>
> Some alternatives:
>
> 1) Don't try to detect whether it is a preview module, but use EAFP to
detect features that have changed:
>
> try:
>result = spam.foo(x, y)
> except AttributeError:
># Must be a preview release. Do something else.
>result = spam.bar(y, x)
>
> This is preferred so long as the differences between preview and stable
releases are big, obvious changes like a function being renamed. But if
there are subtle changes that you care about, things get dicey. spam.foo
may not raise an exception, but just do something completely unexpected.
>
>
>
> 2) As you suggest, write version-specific code:
>
> if sys.version >= "3.4":
>result = spam.foo(x, y)
> else:
># Preview release.
>result = spam.bar(y, x)
>
>
> This starts to get messy fast, particularly if (worst case, and I
*really* hope this doesn't happen!) modules get put into preview, then get
withdrawn, then a few releases later get put back in. This sort of mess
shouldn't ever happen with non-preview modules, but preview modules
explicitly have weaker guarantees.
>
> And I can never remember when modules were added to the std lib.
>
>
>
>
>> Feels like YAGNI to me.
>
>
> When people talk about YAGNI, they are referring to the principle that
you shouldn't waste time and effort over-engineering a complex solution or
providing significant additional functionality for no obvious gain. I don't
think that
>
>PREVIEW = True
>
> in a module *quite* counts as over-engineered.
How about sys.preview_modules to list all the preview modules in the
current release? This would be useful at the interactive prompt, at the
least.
-eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
Am 06.02.2012 00:01, schrieb Barry Warsaw: > On Feb 05, 2012, at 02:25 PM, Benjamin Peterson wrote: > >>The reason 3.2.3 is so soon is the need to patch the hash collision attack. > > Also remember that we are coordinating releases between several versions of > Python for this issue, some of which are in security-only mode. The RMs of > the active stable branches agree it's best to get these coordinated security > releases out as soon as possible. Well, one way to do it would be to release a rc now-ish, giving the community time to test it, and to already use it productively in critical cases, and release the final with the OSX fixes after/at PyCon. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
