David Bolen and I started producing daily OSX installers, at
http://www.python.org/dev/daily-dmg/
If you find problems with these, please report them to bugs.python.org.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
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
> 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
On Mon, May 3, 2010 at 7:34 PM, Barry Warsaw 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?
-- Alexandre
___
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 finall
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
> indent
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
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" wrote:
Benjamin Peterson pyth
Benjamin Peterson python.org> writes:
>
> 2010/5/3 Brett Cannon 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 files, so the
2010/5/3 Brett Cannon :
> 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 returne
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
PyObje
-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 ca
Benjamin Peterson wrote:
> 2010/5/3 Guido van Rossum :
>> On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw 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
2010/5/3 Guido van Rossum :
> On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw 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 increase the workload on the R
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 suppor
> 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.or
On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw 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 should
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 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
On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw 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
newly-required metadata; l
On May 01, 2010, at 08:58 AM, Dirkjan Ochtman wrote:
>On Fri, Apr 30, 2010 at 21:09, Barry Warsaw 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 updat
On Sun, May 2, 2010 at 1:36 PM, Tarek Ziadé 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 an issue, I
Jesus Cea 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.
___
Python-D
23 matches
Mail list logo
