[issue3112] implement PEP 3134 exception reporting

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

On Sun, Jun 22, 2008 at 2:56 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Le dimanche 22 juin 2008 à 20:40 +, Adam Olsen a écrit :
>> Passing in e.args is probably sufficient.
>
> I think it's very optimistic :-) Some exception objects can hold dynamic
> state which is simply not stored in the "args" tuple. See Twisted's
> Failure objects for an extreme example:
> http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py
>
> (yes, it is used an an exception: see "raise self" in the trap() method)

Failure doesn't have an args tuple and doesn't subclass Exception (or
BaseException) - it already needs modification in 3.0.  It's heaped
full of complexity and implementation details.  I wouldn't be
surprised if your changes break it in subtle ways too.

In short, if forcing Failure to be rewritten is the only consequence
of using .args, it's an acceptable tradeoff of not corrupting
exception contexts.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10705/stringobject_format_Lf.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

The tests for PyString_FromFormat are in file Modules/_testcapimodule.c.

Attached is yet another update of the patch, this one also includes 3 
tests for the new %f format specification added to file 
Modules/_testcapimodule.c.

Added file: http://bugs.python.org/file10706/stringobject_format_Lf.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10703/stringobject_format_Lf.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Another rev of the patch now including updates to 2 documentation files: 
Doc/c-api/exceptions.rst and Doc/c-api/string.rst.  As before the patch is 
relative to the source of Python 2.6b1.

Where should test cases for the new formats in the PyString_FromFormat* 
and PyErr_Format functions be added?

Added file: http://bugs.python.org/file10705/stringobject_format_Lf.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2885] Create the urllib package

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

- Docs updated.
- Still pending: 2to3 updates and Deprecation warnings.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3142] urllib docs don't match the new modules

[Senthil]

Senthil <[EMAIL PROTECTED]> added the comment:

Hi Georg,

Updated all the required docs and Committed revision 64476.
Let me know if any more changes required.

Thanks,
Senthil

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3173] external strftime for Python?

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

So how does it work for non-English locales?

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3161] Missing import for sys in _abcoll

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Applied in r64475 .
Thanks for the patch.

--
resolution:  -> accepted
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3173] external strftime for Python?

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

Ummm...  I think I only modified timemodule.c.  datetimemodule.c
probably needs a tweak as well.  I need to get this off my desk though.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3173] external strftime for Python?

[Skip Montanaro]

New submission from Skip Montanaro <[EMAIL PROTECTED]>:

Back in April we had a thread on xmlrpclib's problematic handling of dates
before 1900:

http://thread.gmane.org/gmane.comp.python.devel/93273/focus=93309

I'm still of the opinion that strftime() is the culprit and xmlrpclib is
just an innocent bystander.  Guido worried that to correct this we'd have 
to
implement strftime() from scratch.

I took a different approach and scouted around for an existing version of
strftime() which we could suck into the distribution.  I found a modified
version of the BSD 4.4 strftime which came with (I see to recall) Tcl.
The attached patch is against the py3k svn repo.  It passes all tests as
far as I can tell.

Also, see http://bugs.python.org/issue1777412 which appears to be related.

--
files: strftime.diff
keywords: patch, patch
messages: 68603
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: external strftime for Python?
versions: Python 3.0
Added file: http://bugs.python.org/file10704/strftime.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3165] cPickle recursion problem

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Applied this patch.

Daniel, don't know about that "rule"... I didn't get any warning with gcc...

Anyway, this fixes the issue of #2702.

Thanks cuerty!

--
resolution:  -> accepted
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2702] pickling of large recursive structures crashes cPickle

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Commited this patch to the test cases, and the patch from #3165 to fix
the problem, thank you all!

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3161] Missing import for sys in _abcoll

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2683] subprocess.Popen.communicate takes bytes, not str

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I say docs.

--
assignee:  -> georg.brandl
components: +Documentation -Extension Modules
nosy: +benjamin.peterson, georg.brandl

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1534607] IndexError: Add bad index to msg

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
resolution: invalid -> 
status: closed -> open

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1534607] IndexError: Add bad index to msg

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1180470] BaseHTTPServer uses deprecated mimetools.Message

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Let's save ourselves the trouble...

--
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3172] test macos skipped "unexpected" on linux2

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

This was fixed on the trunk by r64408.

--
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Jean, you can increase *hugely* the possibility of this being accepted
if you submit a comprehensive suite test for this.

Thanks!!

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file10703/stringobject_format_Lf.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file10702/stringobject_format_Lf.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2813] No float formatting in PyString_FromFormat

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Attached is another patch for file Objects/stringobject.c(relative to 
Python 2.6b1) which supports the double %f and long double %LF formats.  

However, %Lf is included only if symbol  LDBL_DIG is defined in header 
file  on the underlying platform.

This patch also handles the long and size_t flags correctly in the first 
loop to determine the size of the buffer under
...
case 'd': case 'u': case 'i': case 'x':
...

Btw, it does not make sense to handle float since there is not formnat 
specification for floats.

Added file: http://bugs.python.org/file10702/stringobject_format_Lf.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3165] cPickle recursion problem

[Daniel Darabos]

Daniel Darabos <[EMAIL PROTECTED]> added the comment:

Added lines have to come after the "static char..." declarations to
comply with C.

Unfortunately I am not experienced with building Python on Windows, so I
could not really try the patch, sorry. (I can get a cPickle.pyd, but it
does not replace the built-in cPickle module.)

Anyway, thanks for the patch, I hope it fixes "my" issue (#2702).

--
nosy: +cyhawk

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3167] math test fails on Solaris 10

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Here is that in from 32- and 64-bit Python 2.6b1:

> ./python (32-bit)
Python 2.6b1 (r26b1:64398, Jun 20 2008, 09:20:49) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(float('-inf'))
-inf
>>> math.log(float('inf'))
inf
>>> math.log(float('nan'))
nan

> ./python (64-bit)  
Python 2.6b1 (r26b1:64398, Jun 19 2008, 20:27:39) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(float('-inf'))
Traceback (most recent call last):
  File "", line 1, in 
ValueError: math domain error
>>> math.log(float('inf')) 
inf
>>> math.log(float('nan'))
nan

Look like a Sun issue, doesn't it?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3172] test macos skipped "unexpected" on linux2

[Jean Brouwers]

New submission from Jean Brouwers <[EMAIL PROTECTED]>:

Test test_macos is reported as an "unexpected skip" on linux2 by Python 
2.6b1 make test.

35 tests skipped:
...
test_macos test_macostools ...
...
2 skips unexpected on linux2:
test_tcl test_macos

$ uname -a
Linux ... 2.6.9-11.EL #1 Fri May 20 18:17:57 EDT 2005 i686 i686 i386 
GNU/Linux

$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)

--
components: Tests
messages: 68593
nosy: MrJean1
severity: normal
status: open
title: test macos skipped "unexpected" on linux2
type: behavior
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1003935] xrange overflows

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

This was fixed for Py3.0.
No interest was shown in backporting.

--
resolution:  -> out of date
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2702] pickling of large recursive structures crashes cPickle

[Daniel Darabos]

Daniel Darabos <[EMAIL PROTECTED]> added the comment:

It works for me as a test case too:

test_deep_recursive (__main__.cPickleDeepRecursive) ... ERROR

==
ERROR: test_deep_recursive (__main__.cPickleDeepRecursive)
--
Traceback (most recent call last):
  File "c:\devel\Python25\Lib\test\test_cpickle.py", line 107, in
test_deep_recursive
self.assertRaises(RuntimeError, cPickle.dumps, n)
  File "C:\devel\Python25\lib\unittest.py", line 320, in failUnlessRaises
callableObj(*args, **kwargs)
KeyError: 13352688

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue775340] OSX 'freeze' bug

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Justin, Jack, how this evolved to the newer Python versions? Do you
think it's worth it to keep it open?

Thank you!

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2702] pickling of large recursive structures crashes cPickle

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Daniel, it'd be great, because it does not crash in linux, so I can not
test it... and I have a patch to apply (see issue 3165), so I wanted to
test it that way.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2702] pickling of large recursive structures crashes cPickle

[Daniel Darabos]

Daniel Darabos <[EMAIL PROTECTED]> added the comment:

I have just quickly pasted it into an interpreter.

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Node(object):
... pass
...
>>> nodes = [Node() for i in range(500)]
>>> for n in nodes:
... n.connections = list(nodes)
... n.connections.remove(n)
...
>>> import cPickle
>>> s = cPickle.dumps( n )

After this line, the interpreter terminated without any further output
(no Python exception and no Windows "General Exception" message box either).

Is it sufficient, or would you prefer me to run the test properly?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2702] pickling of large recursive structures crashes cPickle

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Could you please tell me if this problem arises with this test?

--
keywords: +patch
nosy: +facundobatista
Added file: http://bugs.python.org/file10701/test_cpickle.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1746088] long.__str__ is quadratic time

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Still waiting for the patch.

--
assignee: rhettinger -> 

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3069] Let set.union and set.intersection accept multiple arguments

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3051] heapq change breaking compatibility

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue701743] Reloading pseudo modules

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Walter, the import mechanisms changed by a big rework from Brett Cannon
in the last months. 

Do you think still have a use case that should be fulfilled? Do you want
to update your patch?

Thank you!

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue678464] Docs don't define sequence-ness very well

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Skip, don't you think it's better to raise this kind of generic question
in the python-dev list?

This should probably lay down here for ever before a discussion raises
to decide this.

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1567948] poplib.py list interface

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Hasan, are you still interested in this or wants to drop this request?
Passing almost two years without comments it's no good if you'll be the
package maintainer.

Thanks!

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Le dimanche 22 juin 2008 à 20:40 +, Adam Olsen a écrit :
> > How do you duplicate an instance of an user-defined exception? Using
> an
> > equivalent of copy.deepcopy()? It will probably end up much more
> > expensive than the above-mentioned O(n) search.
> 
> Passing in e.args is probably sufficient.

I think it's very optimistic :-) Some exception objects can hold dynamic
state which is simply not stored in the "args" tuple. See Twisted's
Failure objects for an extreme example:
http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py

(yes, it is used an an exception: see "raise self" in the trap() method)

> Can be, or will be?  Only the most common behaviour needs to be optimized.

Well, the "most common behaviour" is a very short context chain, which
is already optimized by my reference-avoidance proposal...

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

On Sun, Jun 22, 2008 at 2:20 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le dimanche 22 juin 2008 à 19:57 +, Adam Olsen a écrit :
>> That's still O(n).  I'm not so easily convinced it's cheap enough.
>
> O(n) when n will almost never be greater than 5 (and very often equal to
> 1 or 2), and when the unit is the cost of a pointer dereference plus the
> cost of a pointer comparison, still sounds cheap. We could bench it
> anyway.

Indeed.

>> And for that matter, I'm not convinced it's correct.  The inner
>> exception's context becomes clobbered when we modify the outer
>> exception's traceback.  The inner's context should reference the
>> traceback as it was at that point.
>
> Yes, I've just thought about that, it's a bit annoying... We have to
> decide what is more annoying: that, or a reference cycle that can delay
> deallocation of stuff attached to an exception (including local
> variables attached to the tracebacks)?

The cycle is only created by broken behaviour.  The more I think about
it, the more I want to fix it (by not reusing the exception).

>> This would all be a lot easier if reraising always created a new
>> exception.
>
> How do you duplicate an instance of an user-defined exception? Using an
> equivalent of copy.deepcopy()? It will probably end up much more
> expensive than the above-mentioned O(n) search.

Passing in e.args is probably sufficient.  All this would need to be
discussed on python-dev (or python-3000?) though.

>> Can you think of a way to skip that only when we can be
>> sure its safe?  Maybe as simple as counting the references to it?
>
> I don't think so, the exception can be referenced in an unknown number
> of local variables (themselves potentially referenced by tracebacks).

Can be, or will be?  Only the most common behaviour needs to be optimized.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Le dimanche 22 juin 2008 à 19:57 +, Adam Olsen a écrit :
> That's still O(n).  I'm not so easily convinced it's cheap enough.

O(n) when n will almost never be greater than 5 (and very often equal to
1 or 2), and when the unit is the cost of a pointer dereference plus the
cost of a pointer comparison, still sounds cheap. We could bench it
anyway.

> And for that matter, I'm not convinced it's correct.  The inner
> exception's context becomes clobbered when we modify the outer
> exception's traceback.  The inner's context should reference the
> traceback as it was at that point.

Yes, I've just thought about that, it's a bit annoying... We have to
decide what is more annoying: that, or a reference cycle that can delay
deallocation of stuff attached to an exception (including local
variables attached to the tracebacks)?

(just a small note: it's exception objects that are chained, not
tracebacks... we never modify tracebacks at any point)

> This would all be a lot easier if reraising always created a new
> exception.

How do you duplicate an instance of an user-defined exception? Using an
equivalent of copy.deepcopy()? It will probably end up much more
expensive than the above-mentioned O(n) search.

> Can you think of a way to skip that only when we can be
> sure its safe?  Maybe as simple as counting the references to it?

I don't think so, the exception can be referenced in an unknown number
of local variables (themselves potentially referenced by tracebacks).

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

On Sun, Jun 22, 2008 at 1:48 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le dimanche 22 juin 2008 à 19:23 +, Adam Olsen a écrit :
>> For this behaviour, this is the most natural way to write it.
>> Conceptually, there shouldn't be a cycle
>
> I agree your example is not far-fetched. How about avoiding cycles for
> implicit chaining, and letting users shoot themselves in the foot with
> explicit recursive chaining if they want? Detection would be cheap
> enough, just a simple loop without any memory allocation.

That's still O(n).  I'm not so easily convinced it's cheap enough.

And for that matter, I'm not convinced it's correct.  The inner
exception's context becomes clobbered when we modify the outer
exception's traceback.  The inner's context should reference the
traceback as it was at that point.

This would all be a lot easier if reraising always created a new
exception.  Can you think of a way to skip that only when we can be
sure its safe?  Maybe as simple as counting the references to it?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Le dimanche 22 juin 2008 à 19:23 +, Adam Olsen a écrit :
> For this behaviour, this is the most natural way to write it.
> Conceptually, there shouldn't be a cycle

I agree your example is not far-fetched. How about avoiding cycles for
implicit chaining, and letting users shoot themselves in the foot with
explicit recursive chaining if they want? Detection would be cheap
enough, just a simple loop without any memory allocation.

> the traceback should be the
> lookup, then the fallback, then whatever code is about this - exactly
> the order the code executed in.

It would be the reverse: first the fallback, then the re-raised
exception. The last caught exception is always reported last, because
it's supposed to be the "main" or "highest-level" one.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1523853] 2.4.2 file.read caches EOF state

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

In Linux, it seems to be the behaviour of the underlying C function 'fread'.

Do you think it's ok to add the following line in the read() documentation?

"""
As this function depends of the underlying C function :cfunc:`fread`,
inheritates its behaviour in details like caching EOF and others.
"""

Assigning this to George, to reword that in nicer English and apply.

Regards,

--
assignee:  -> georg.brandl
nosy: +facundobatista, georg.brandl

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

On Sun, Jun 22, 2008 at 1:04 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le dimanche 22 juin 2008 à 17:17 +, Adam Olsen a écrit :
>> I meant only that trivial cycles should be detected.  However, I
>> hadn't read your patch, so I didn't realize you already knew of a way
>> to create a non-trivial cycle.
>>
>> This has placed a niggling doubt in my mind about chaining the
>> exceptions, rather than the tracebacks.  Hrm.
>
> Chaining the tracebacks rather than the exceptions loses important
> information: what is the nature of the exception which is the cause or
> context of the current exception?

I assumed each leg of the traceback would reference the relevant exception.

Although.. this is effectively the same as creating a new exception
instance when reraised, rather than modifying the old one.  Reusing
the old is done for performance I believe.

> It is improbable to create such a cycle involuntarily, it means you
> raise an old exception in replacement of a newer one caused by the
> older, which I think is quite contorted. It is also quite easy to avoid
> creating the cycle, simply by re-raising outside of any except handler.

I'm not convinced.

try:
...  # Lookup
except A as a:  # Lookup failed
try:
...  # Fallback
except B as b:  # Fallback failed
raise a  # The original exception is of the type we want

For this behaviour, this is the most natural way to write it.
Conceptually, there shouldn't be a cycle - the traceback should be the
lookup, then the fallback, then whatever code is about this - exactly
the order the code executed in.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Le dimanche 22 juin 2008 à 17:17 +, Adam Olsen a écrit :
> I meant only that trivial cycles should be detected.  However, I
> hadn't read your patch, so I didn't realize you already knew of a way
> to create a non-trivial cycle.
> 
> This has placed a niggling doubt in my mind about chaining the
> exceptions, rather than the tracebacks.  Hrm.

Chaining the tracebacks rather than the exceptions loses important
information: what is the nature of the exception which is the cause or
context of the current exception?

It is improbable to create such a cycle involuntarily, it means you
raise an old exception in replacement of a newer one caused by the
older, which I think is quite contorted. It is also quite easy to avoid
creating the cycle, simply by re-raising outside of any except handler.

> Ahh, harmless then, but to what benefit?

I don't know, I've never used that API, I just proposed returning that
error code since it is computed inside the function anyway.
But let's drop that proposal. Same for PyErr_DisplaySingle if nobody
cares.

> Wouldn't the traceback
> module be better suited to any possible error reporting?

I suppose built-in reporting is needed when reporting a grave error such
as a MemoryError (C code can avoid doing any memory allocations), or an
error that occurred during startup before any pure Python modules could
be initialized (how would you report a syntax error in the traceback
module itself?).

But application code should use the traceback module rather than try to
access the C API.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

I don't maintain the 2.5 docs anymore, at least for such minor bugs.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3146] Sphinx/LaTeX fails on Python 3.0b1 documentation

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Thanks, should be fixed with Sphinx r64465.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error

[Manuel Kaufmann]

Manuel Kaufmann <[EMAIL PROTECTED]> added the comment:

This bug was reported on Python 2.5 version and was applied on 2.6 
branch. That's correct?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3157] sqlite3 minor documentation issues

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

I fixed the docstring in r64463 (2.5 branch, already fixed in trunk) and
expanded the connect() docstring in r64464.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3085] chapter 17.1.3.5 'Replacing os.popen*' in the Python library reference contains an error

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r64461. Thanks!

--
resolution:  -> fixed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

On Sun, Jun 22, 2008 at 8:07 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> You mean they should be detected when the exception is set? I was afraid
> that it may make exception raising slower. Reporting is not performance
> sensitive in comparison to exception raising.
>
> (the "problem mentioned here" is already avoided in the patch, but the
> detection of other cycles is deferred to exception reporting for the
> reason given above)

I meant only that trivial cycles should be detected.  However, I
hadn't read your patch, so I didn't realize you already knew of a way
to create a non-trivial cycle.

This has placed a niggling doubt in my mind about chaining the
exceptions, rather than the tracebacks.  Hrm.

>> * PyErr_Display is used by PyErr_Print, and it must end up with no
>> active exception.  Additionally, third party code may depend on this
>> semantic.  Maybe PyErr_DisplayEx?
>
> I was not proposing to change the exception swallowing semantics, just
> to add a return value indicating if any errors had occurred while
> displaying the exception.

Ahh, harmless then, but to what benefit?  Wouldn't the traceback
module be better suited to any possible error reporting?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header

[Chris Withers]

Chris Withers <[EMAIL PROTECTED]> added the comment:

Andi, I'm in total agreement with you :-)
(so if this bug could get fixed, both issues could get closed)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3165] cPickle recursion problem

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

What is this fixing? Could you please provide a test cases that fails
without this patch?

Thank you!!

--
nosy: +facundobatista

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3164] cPickle calls to save_string and save_unicode with unicode objects.

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Commited in 64455, thank you!

--
nosy: +facundobatista
resolution:  -> accepted
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Le dimanche 22 juin 2008 à 07:04 +, Adam Olsen a écrit :
> Adam Olsen <[EMAIL PROTECTED]> added the comment:
> 
> * cause/context cycles should be avoided.  Naive traceback printing
> could become confused, and I can't think of any accidental way to
> provoke it (besides the problem mentioned here.)

You mean they should be detected when the exception is set? I was afraid
that it may make exception raising slower. Reporting is not performance
sensitive in comparison to exception raising.

(the "problem mentioned here" is already avoided in the patch, but the
detection of other cycles is deferred to exception reporting for the
reason given above)

> * PyErr_Display is used by PyErr_Print, and it must end up with no
> active exception.  Additionally, third party code may depend on this
> semantic.  Maybe PyErr_DisplayEx?

I was not proposing to change the exception swallowing semantics, just
to add a return value indicating if any errors had occurred while
displaying the exception.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2732] curses.textpad loses characters at the end of lines

[A.M. Kuchling]

A.M. Kuchling <[EMAIL PROTECTED]> added the comment:

This bug was fixed in 2.5 and 2.6, in rev. 60118 and 60119.  Thanks for
your bug report!

--
assignee:  -> akuchling
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2722] os.getcwd fails for long path names on linux

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Went for the malloc only patch. Just fixed a small detail (weird corner
case if malloc returned NULL first time, res will be unassigned).

The test could be better (no necessity of using a recursive function, it
could be done with a while), but it works.

Commited in r64452.

--
nosy: +facundobatista
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1974] email.MIMEText.MIMEText.as_string incorrectly folding long subject header

[Andi Albrecht]

Andi Albrecht <[EMAIL PROTECTED]> added the comment:

For me this issue seems to be a duplicate of issue1645148.

In my opinion the test case that checks if headers created by strings or
Header instances are equal is incorrect. It shouldn't set the
continuation whitespace explicitly when creating a Headers instance. I
would expect that

  A) msg['aheader'] = 'a long string that breaks, but shortened here'

and

  B) msg['aheader'] = Header('a long string that breaks, but shortened
here')

result in the same output. But for A) a Header instance is initialized
in Generator._write_headers() with continuation_ws set to `\t` and for
B) the default ' ' is used (see http://bugs.python.org/msg31102).

I'm uploading a patch that modifies test_string_headerinst_eq() to what
I think it should look like with this message. Of course, this test will
fail at the moment, but maybe you agree that the Header instance in this
test should be initialized without explicitly setting continuation_ws.

--
keywords: +patch
nosy: +aalbrecht
Added file: http://bugs.python.org/file10700/py_issue1974.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3167] math test fails on Solaris 10

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Could you tell me what

>>> import math
>>> math.log(float('-inf'))

gives instead of the expected ValueError?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3168] cmath test fails on Solaris 10

[Mark Dickinson]

Changes by Mark Dickinson <[EMAIL PROTECTED]>:


--
assignee:  -> marketdickinson
nosy: +marketdickinson

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3167] math test fails on Solaris 10

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I'll take a look.

--
assignee:  -> marketdickinson
nosy: +marketdickinson

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3112] implement PEP 3134 exception reporting

[Adam Olsen]

Adam Olsen <[EMAIL PROTECTED]> added the comment:

* cause/context cycles should be avoided.  Naive traceback printing
could become confused, and I can't think of any accidental way to
provoke it (besides the problem mentioned here.)

* I suspect PyErr_Display handled string exceptions in 2.x, and this is
an artifact of that

* No opinion on PyErr_DisplaySingle

* PyErr_Display is used by PyErr_Print, and it must end up with no
active exception.  Additionally, third party code may depend on this
semantic.  Maybe PyErr_DisplayEx?

* +1 on standardizing tracebacks

--
nosy: +Rhamphoryncus

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com