On Mon, May 3, 2010 at 06:57, Jesus Cea j...@jcea.es wrote:
Would be enough to raise an ERROR at configure time if OSF test is
positive?. To delete that intentional ERROR would be trivial.
Oh really? I have no clue of how to do that. Doesn't like like a good
deprecation to me. :)
Is printing a
Jesus Cea jcea at jcea.es writes:
Would be enough to raise an ERROR at configure time if OSF test is
positive?. To delete that intentional ERROR would be trivial.
I think it's ok. Noone will probably notice anyway.
Regards
Antoine.
___
On Sun, May 2, 2010 at 1:36 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
a similar function in
e.g. shutils module ?
A: Yes :)
Basically, anything useful in distutils.file_util and
distutils.dir_util can maove in Shutil.
That's why I added make_archive (and unpack_archive)
Please add
On May 01, 2010, at 08:58 AM, Dirkjan Ochtman wrote:
On Fri, Apr 30, 2010 at 21:09, Barry Warsaw ba...@python.org wrote:
Though maybe it should be called Conclusion instead of Accepted and
used for Rejected PEPs, as well?
Good point. What do you think about 'Resolution'?
Fine with me.
I've
On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw ba...@python.org wrote:
but in fact, the scripts make Resolution optional (it's kind of a pain to make
it required just for Standards Track PEPs - contributions welcome).
It will also be a pain to retroactively update older PEPs with the
On Apr 30, 2010, at 04:28 PM, Steve Holden wrote:
Martin v. Löwis wrote:
As to Guido's point about the decision making process, Nick's right. I just
want to make sure we can capture the resolution in the PEP, be it by BDFL
pronouncement or hey, silence is acceptance email.
I don't think
On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote:
IIRC in the IETF this is done by the committee chair. I think it's a
good idea to have this be a single person to avoid endless indecision.
It then seems that this role should go to the release manager of the
upcoming feature release.
On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw ba...@python.org wrote:
On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote:
IIRC in the IETF this is done by the committee chair. I think it's a
good idea to have this be a single person to avoid endless indecision.
It then seems that this role
In the meantime, let's groom Benjamin to be the Sacred Next Uncle Galvanizing
the Gamut of Language Evolution.
I don't think anybody having such a position permanently can really work.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Jesus Cea wrote:
On 26/04/10 22:00, Martin v. Löwis wrote:
Maybe we can drop OSF/1 safely supporting Tru64 yet, but we don't have
any buildbot running any of this systems...
Dropping support is fine with me, in the long term. If PEP 11 is truly
followed, we should deprecate support in one
2010/5/3 Guido van Rossum gu...@python.org:
On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw ba...@python.org wrote:
I do think it makes sense for the RM to assume these responsibilities where
Guido either can't or doesn't want to make the final decision. I think it
will fairly substantially
Benjamin Peterson wrote:
2010/5/3 Guido van Rossum gu...@python.org:
On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw ba...@python.org wrote:
I do think it makes sense for the RM to assume these responsibilities where
Guido either can't or doesn't want to make the final decision. I think it
will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/05/10 21:55, Martin v. Löwis wrote:
Just to rephrase: the point of this deprecation cycle is to give users a
chance to take over maintenance, and to declare, in public, that they
are interested in that port. If nobody steps forward, we can
Since 2.7 is probably going to exist for a while, I am running Clang 2.7's
static analyzer (``clang --static``) over trunk. It's mostly just finding
stuff like unneeded variable initialization or variables that are never used
(compilation is picking up unused returned values, almost all from
2010/5/3 Brett Cannon br...@python.org:
Since 2.7 is probably going to exist for a while, I am running Clang 2.7's
static analyzer (``clang --static``) over trunk. It's mostly just finding
stuff like unneeded variable initialization or variables that are never used
(compilation is picking up
Benjamin Peterson benjamin at python.org writes:
2010/5/3 Brett Cannon brett at python.org:
When I check in these changes I will do it file by file, but my
question is
how to handle Misc/NEWS. I have gone through the underscores and the
'a's in
Modules and already have six modified
I'll just do a single entry saying that the static analyzer was used and not
list the files.
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
On May 3, 2010 4:00 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to standardize all C files on a 4-spaces
indentation rule?
I understand the
Antoine Pitrou wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to standardize all C files on a 4-spaces
indentation
On May 03, 2010, at 10:12 PM, Steve Holden wrote:
Antoine Pitrou wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to
On Mon, May 3, 2010 at 7:34 PM, Barry Warsaw ba...@python.org wrote:
Now would be a good time to convert the C files to 4 space indents. We've
only been talking about it for a decade at least.
Will changing the indentation of source files to 4 space indents break
patches on the bug tracker?
Will changing the indentation of source files to 4 space indents break
patches on the bug tracker?
Plain patch will choke, but patch -l might accept them. I have only
read the documentation, though, and don't know whether it does in practice.
Regards,
Martin
Steve Holden wrote:
Antoine Pitrou wrote:
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit :
And in reply to Benjamin's question about the whitespace, I guess it
actually doesn't matter. More important to clean up in py3k.
Would it be finally time to standardize all C files on a
23 matches
Mail list logo
