Raymond Hettinger wrote:
> Please go ahead and get the patch together for localcontext(). This
> should be an easy sell:
>
> * simple bugs can be fixed in Py2.5.1 but API mistakes are forever. *
> currently, all of the docs, docstrings, and whatsnew are incorrect.
> * the solution has already b
Patch / Bug Summary
___
Patches : 412 open ( +5) / 3397 closed ( +4) / 3809 total ( +9)
Bugs: 900 open (+12) / 6149 closed ( +4) / 7049 total (+16)
RFE : 233 open ( +1) / 236 closed ( +0) / 469 total ( +1)
New / Reopened Patches
__
set liter
+1
On 9/1/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Currently, both the partition() and rpartition() methods return a (head,
> sep, tail) tuple and the only difference between the two is whether the
> partition element search starts from the beginning or end of the
> string. When no sepa
Currently, both the partition() and rpartition() methods return a (head,
sep, tail) tuple and the only difference between the two is whether the
partition element search starts from the beginning or end of the
string. When no separator is found, both methods return the string S
and two empty s
>>> The right way to do it was presented in PEP343. The implementation
>>> was correct and the API was simple.
>>
>>
>>
>> Raymond's persuaded me that he's right on the API part at the very
>> least. The current API was a mechanical replacement of the initial
>> __context__ based API with a no
For 2.x we really don't want to reformat all code. I even think it's
questionable to use 4 spaces for new files since it will mean problems
for editors switching between files.
For 3.0 we really do. But as long as 2.x and 3.0 aren't too far apart
I'd rather not reformat everything because it would
This 8 vs 4 is getting cruftier and cruftier. (And does it deal
properly with existing code that already has four spaces because it
was written recently?)
"Tim" regularly fixes whitespace already, with little damage.
Would it make sense to do a one-time cutover on the 2.6 trunk?
How about the bu
"Johann C. Rocholl" wrote:
> What is the status of http://effbot.org/lib/ ?
>
> I think it's a step in the right direction. Is it still in progress?
the pushback from the powers-that-be was massive, so we're currently working
"under
the radar", using alternative deployment approaches (see pytut.
