Re: [Python-Dev] That library reference, yet again

2006-09-01 Thread Fredrik Lundh 
"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.infogami.com and 
friends).

 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: [Python-checkins] r51674 - python/trunk/Misc/Vim/vimrc

2006-09-01 Thread Jim Jewett 
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 bugfix branches?

If it is ever going to happen, then immediately after a release,
before unfreezing, is probably the best time.

-jJ

-- Forwarded message --
From: brett.cannon <[EMAIL PROTECTED]>
Date: Aug 31, 2006 6:42 PM
Subject: [Python-checkins] r51674 - python/trunk/Misc/Vim/vimrc
To: [EMAIL PROTECTED]


Author: brett.cannon
Date: Fri Sep  1 00:42:37 2006
New Revision: 51674

Modified:
   python/trunk/Misc/Vim/vimrc
Log:
Have pre-existing C files use 8 spaces indents (to match old PEP 7 style), but
have all new files use 4 spaces (to match current PEP 7 style).


Modified: python/trunk/Misc/Vim/vimrc
==
--- python/trunk/Misc/Vim/vimrc (original)
+++ python/trunk/Misc/Vim/vimrc Fri Sep  1 00:42:37 2006
@@ -19,9 +19,10 @@
 " Number of spaces to use for an indent.
 " This will affect Ctrl-T and 'autoindent'.
 " Python: 4 spaces
-" C: 4 spaces
+" C: 8 spaces (pre-existing files) or 4 spaces (new files)
 au BufRead,BufNewFile *.py,*pyw set shiftwidth=4
-au BufRead,BufNewFile *.c,*.h set shiftwidth=4
+au BufRead *.c,*.h set shiftwidth=8
+au BufNewFile *.c,*.h set shiftwidth=4

 " Number of spaces that a pre-existing tab is equal to.
 " For the amount of space used for a new tab use shiftwidth.
___
Python-checkins mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: [Python-checkins] r51674 - python/trunk/Misc/Vim/vimrc

2006-09-01 Thread Guido van Rossum 
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 break all merge
capabilities.

--Guido

On 9/1/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> 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 bugfix branches?
>
> If it is ever going to happen, then immediately after a release,
> before unfreezing, is probably the best time.
>
> -jJ
>
> -- Forwarded message --
> From: brett.cannon <[EMAIL PROTECTED]>
> Date: Aug 31, 2006 6:42 PM
> Subject: [Python-checkins] r51674 - python/trunk/Misc/Vim/vimrc
> To: [EMAIL PROTECTED]
>
>
> Author: brett.cannon
> Date: Fri Sep  1 00:42:37 2006
> New Revision: 51674
>
> Modified:
>python/trunk/Misc/Vim/vimrc
> Log:
> Have pre-existing C files use 8 spaces indents (to match old PEP 7 style), but
> have all new files use 4 spaces (to match current PEP 7 style).
>
>
> Modified: python/trunk/Misc/Vim/vimrc
> ==
> --- python/trunk/Misc/Vim/vimrc (original)
> +++ python/trunk/Misc/Vim/vimrc Fri Sep  1 00:42:37 2006
> @@ -19,9 +19,10 @@
>  " Number of spaces to use for an indent.
>  " This will affect Ctrl-T and 'autoindent'.
>  " Python: 4 spaces
> -" C: 4 spaces
> +" C: 8 spaces (pre-existing files) or 4 spaces (new files)
>  au BufRead,BufNewFile *.py,*pyw set shiftwidth=4
> -au BufRead,BufNewFile *.c,*.h set shiftwidth=4
> +au BufRead *.c,*.h set shiftwidth=8
> +au BufNewFile *.c,*.h set shiftwidth=4
>
>  " Number of spaces that a pre-existing tab is equal to.
>  " For the amount of space used for a new tab use shiftwidth.
> ___
> Python-checkins mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-checkins
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented

2006-09-01 Thread Raymond Hettinger 

>>> 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 normal method, whereas I should have 
>> reverted back to the module-level localcontext() function from PEP343 
>> and thrown the method on Context objects away entirely.
>>
>> I can fix it on the trunk (and add those missing tests!), but I'll 
>> need Anthony and/or Neal's permission to backport it and remove the 
>> get_manager() method from Python 2.5 before we get stuck with it 
>> forever.
>
>
>
> I committed this fix as 51664 on the trunk (although the docstrings 
> are still example free because doctest doesn't understand __future__ 
> statements).
>

Thanks for getting this done.

Please make the following changes:
* rename ContextManger to _ContextManger and remove it from the __all__ 
listing
* move the copy() step from localcontext() to _ContextManager()
* make the trivial updates the whatsnew25 example

Once those nits are fixed, I recommend this patch be backported to the 
Py2.5 release.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Problem withthe API for str.rpartition()

2006-09-01 Thread Raymond Hettinger 
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 strings so that 'a'.partition('x') == 'a'.rpartition('x') 
== ('a', '', ''). 

For rpartition() the notion of head and tail are backwards -- you 
repeatedly search the tail, not the head.  The distinction is vital 
because the use cases for rpartition() are a mirror image of those for 
partition().  Accordingly, rpartition()'s result should be interpreted 
as (tail, sep, head) and the partition-not-found endcase needs change so 
that 'a'.rpartition('x') == ('', '', 'a') .

The test invariant should be:
For every s and p:s.partition(p) == s[::-1].rpartition(p)[::-1]

The following code demonstrates why the current choice is problematic:

line = 'a.b.c.d'
while line:
field, sep, line = line.partition('.')
print field

line = 'a.b.c.d'
while line:
line, sep, field = line.rpartition('.')
print field

The second fragment never terminates.

Since this is a critical API flaw rather than a implementation bug, I 
think it should get fixed right away rather than waiting for Py2.5.1.



Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Problem withthe API for str.rpartition()

2006-09-01 Thread Guido van Rossum 
+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 separator is found, both methods return the string S
> and two empty strings so that 'a'.partition('x') == 'a'.rpartition('x')
> == ('a', '', '').
>
> For rpartition() the notion of head and tail are backwards -- you
> repeatedly search the tail, not the head.  The distinction is vital
> because the use cases for rpartition() are a mirror image of those for
> partition().  Accordingly, rpartition()'s result should be interpreted
> as (tail, sep, head) and the partition-not-found endcase needs change so
> that 'a'.rpartition('x') == ('', '', 'a') .
>
> The test invariant should be:
> For every s and p:s.partition(p) == s[::-1].rpartition(p)[::-1]
>
> The following code demonstrates why the current choice is problematic:
>
> line = 'a.b.c.d'
> while line:
> field, sep, line = line.partition('.')
> print field
>
> line = 'a.b.c.d'
> while line:
> line, sep, field = line.rpartition('.')
> print field
>
> The second fragment never terminates.
>
> Since this is a critical API flaw rather than a implementation bug, I
> think it should get fixed right away rather than waiting for Py2.5.1.
>
>
>
> Raymond
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Weekly Python Patch/Bug Summary

2006-09-01 Thread Kurt B. Kaiser 
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 literals  (2006-08-28)
CLOSED http://python.org/sf/1547796  opened by  Georg Brandl

"for x in setliteral" peepholer optimization  (2006-08-28)
CLOSED http://python.org/sf/1548082  opened by  Georg Brandl

set comprehensions  (2006-08-29)
   http://python.org/sf/1548388  opened by  Georg Brandl

Fix for structmember conversion issues  (2006-08-29)
   http://python.org/sf/1549049  opened by  Roger Upole

Implementation of PEP 3102 Keyword Only Argument  (2006-08-31)
   http://python.org/sf/1549670  opened by  Jiwon Seo

Add a test suite for test_unittest  (2006-08-31)
   http://python.org/sf/1550272  opened by  Collin Winter

Fix numerous bugs in unittest  (2006-08-31)
   http://python.org/sf/1550273  opened by  Collin Winter

Ellipsis literal "..."  (2006-09-01)
   http://python.org/sf/1550786  opened by  Georg Brandl

make exec a function  (2006-09-01)
   http://python.org/sf/1550800  opened by  Georg Brandl

Patches Closed
__

Allow os.listdir to accept file names longer than MAX_PATH  (2006-04-26)
   http://python.org/sf/1477350  closed by  rupole

set literals  (2006-08-28)
   http://python.org/sf/1547796  closed by  gbrandl

pybench.py error reporting broken for bad -s filename  (2006-08-25)
   http://python.org/sf/1546372  closed by  lemburg

"if x in setliteral" peepholer optimization  (2006-08-28)
   http://python.org/sf/1548082  closed by  gvanrossum

New / Reopened Bugs
___

Typo in Language Reference Section 3.2 Class Instances  (2006-08-28)
   http://python.org/sf/1547931  opened by  whesse_at_clarkson

curses module segfaults on invalid tparm arguments  (2006-08-28)
   http://python.org/sf/1548092  opened by  Marien Zwart

Add 'find' method to sequence types  (2006-08-28)
   http://python.org/sf/1548178  opened by  kovan

Recursion limit exceeded in the match function  (2006-08-29)
CLOSED http://python.org/sf/1548252  opened by  wojtekwu

sgmllib.sgmlparser is not thread safe  (2006-08-28)
   http://python.org/sf/1548288  opened by  Andres Riancho

whichdb too dumb  (2006-08-28)
   http://python.org/sf/1548332  opened by  Curtis Doty

filterwarnings('error') has no effect  (2006-08-29)
   http://python.org/sf/1548371  opened by  Roger Upole

C modules reloaded on certain failed imports  (2006-08-29)
   http://python.org/sf/1548687  opened by  Josiah Carlson

shlex (or perhaps cStringIO) and unicode strings  (2006-08-29)
   http://python.org/sf/1548891  opened by  Erwin S. Andreasen

bug in classlevel variabels  (2006-08-30)
CLOSED http://python.org/sf/1549499  opened by  Thomas Dybdahl Ahle

Pdb parser bug  (2006-08-30)
   http://python.org/sf/1549574  opened by  Alexander Belopolsky

urlparse return exchanged values  (2006-08-30)
CLOSED http://python.org/sf/1549589  opened by  Oscar Acena

Enhance and correct unittest's docs (redux)  (2006-08-31)
   http://python.org/sf/1550263  reopened by  fdrake

Enhance and correct unittest's docs (redux)  (2006-08-31)
   http://python.org/sf/1550263  opened by  Collin Winter

inspect module and class startlineno  (2006-09-01)
   http://python.org/sf/1550524  opened by  Ali Gholami Rudi

SWIG wrappers incompatible with 2.5c1  (2006-09-01)
   http://python.org/sf/1550559  opened by  Andrew Gregory

itertools.tee raises SystemError  (2006-09-01)
   http://python.org/sf/1550714  opened by  Alexander Belopolsky

itertools.tee raises SystemError  (2006-09-01)
CLOSED http://python.org/sf/1550761  opened by  Alexander Belopolsky

Bugs Closed
___

x!=y and [x]=[y] (!)  (2006-08-22)
   http://python.org/sf/1544762  closed by  rhettinger

Recursion limit exceeded in the match function  (2006-08-29)
   http://python.org/sf/1548252  closed by  gbrandl

bug in classlevel variabels  (2006-08-30)
   http://python.org/sf/1549499  closed by  gbrandl

urlparse return exchanged values  (2006-08-30)
   http://python.org/sf/1549589  closed by  gbrandl

Enhance and correct unittest's docs (redux)  (2006-08-31)
   http://python.org/sf/1550263  closed by  fdrake

itertools.tee raises SystemError  (2006-09-01)
   http://python.org/sf/1550761  deleted by  belopolsky

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented

2006-09-01 Thread Nick Coghlan 
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 been worked-out in PEP343 -- it's nothing new.
> * nothing else, anywhere depends on this code -- it is as safe a change 
> as we could hope for.
> 
> Neal is tough, but he's not heartless ;-)

I backported the changes and assigned the patch to Neal:
http://www.python.org/sf/1550886

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com