[issue2533] Invalid TypeError with class method decorator and class method parameter

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

First, your code does not compile: when compiling the DecorateMe class
body, the DecorateMe class does not yet exist, and
"callback=DecorateMe.callback" is an error!

And this explains your surprise: certainly there is a previous version
of a DecorateMe class in your module (or interactive session). This
other class has the same name, but it is still a different class, hence
the message.

--
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2303] isinstance is 4x as slow as in 2.5 because the common case raises

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

Issue #2534 has a patch which speeds up isinstance and issubclass by
implementing type.__instancecheck__ and type.__subclasscheck__.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2534] Speed up isinstance and issubclass

[Thomas Heller]

New submission from Thomas Heller <[EMAIL PROTECTED]>:

This patch implements type.__instancecheck__ and type.__subclasscheck__,
which speeds up isinstance and issubclass calls quite a bit.

See also issue #2303.

Here are the performance figures for the current trunk version:

Current SNV trunk:

Using 2.6a1+ (trunk:62102, Apr  2 2008, 11:30:16) [MSC v.1500 32 bit
(Intel)]
isinstance(42, int)100 loops, best of 3: 0.28 usec per loop
isinstance(42, type)   100 loops, best of 3: 0.974 usec per loop
issubclass(object, type)   100 loops, best of 3: 1.1 usec per loop
issubclass(object, int)100 loops, best of 3: 1.1 usec per loop
issubclass(float, int) 100 loops, best of 3: 1.15 usec per loop

Current trunk, patch applied:

Using 2.6a1+ (trunk:62102M, Apr  2 2008, 11:21:32) [MSC v.1500 32 bit
(Intel)]
isinstance(42, int)100 loops, best of 3: 0.274 usec per loop
isinstance(42, type)   100 loops, best of 3: 0.524 usec per loop
issubclass(object, type)   100 loops, best of 3: 0.661 usec per loop
issubclass(object, int)100 loops, best of 3: 0.662 usec per loop
issubclass(float, int) 100 loops, best of 3: 0.731 usec per loop

Python 2.5.2, for comparison:

Using 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
isinstance(42, int)100 loops, best of 3: 0.292 usec per loop
isinstance(42, type)   100 loops, best of 3: 0.417 usec per loop
issubclass(object, type)   100 loops, best of 3: 0.626 usec per loop
issubclass(object, int)100 loops, best of 3: 0.648 usec per loop
issubclass(float, int) 100 loops, best of 3: 0.752 usec per loop

--
files: type_instancecheck.diff
keywords: patch, patch
messages: 64842
nosy: theller
severity: normal
status: open
title: Speed up isinstance and issubclass
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file9924/type_instancecheck.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2532] file that breaks 2to3 (despite being correct python)

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Testing with a much simpler file ("a = 0\n" * 1000), there is a limit to
the number of statements in one file, around (sys.recursionlimit - 24).

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

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

[issue2422] Automatically disable pymalloc when running under valgrind

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

James Henstridge schrieb:
> James Henstridge <[EMAIL PROTECTED]> added the comment:
> 
> There are probably a few other performance optimisations that would be
> good to turn off when running under valgrind.
> 
> A big one is the tuple cache: if there are tuple reference counting
> issues, they won't necessarily be seen by valgrind if the tuple is kept
> and reused rather than being freed.

The tuple cache can't be disabled entirely. Some parts of Python and
some third party modules may depend on the fact that an empty tuple ()
is a singleton in Python.

The tuple cache could be reduced to empty tuple and some other caches
like the list and dict cache could be disabled entirely.

Christian

__
Tracker <[EMAIL PROTECTED]>

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

[issue2513] 64bit cross compilation on windows

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Could somebody with a 64bit CPU please extend the PCbuild/README.txt? I
don't have the means to test 64bit builds or cross compilation of a
32bit build on a 64bit system. I only have 32bit CPUs at home.

+1 for nmake if you can get it to work.

A while ago I suggested to ship both 32bit and 64bit lib files with
every flavor of Python. With both library sets developers could cross
compile Windows extensions. Comments?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2535] duplicate Misc.lower

[Matthias Kievernagel]

New submission from Matthias Kievernagel <[EMAIL PROTECTED]>:

ron longo posted this remark in the Tkinter list:
>Don't know if this is the place to report this.  Not really a 
bug, >however,
>method lower() is defined twice in class Misc in the module 
Tkinter.py. 
>Both definitions are identical.

So I created a patch (against rev62104 which removes the first
occurrence which seems a bit out of order
(second one is grouped with raise).

Matthias.

--
components: Tkinter
files: duplicateLower.patch
keywords: patch
messages: 64845
nosy: mkiever
severity: normal
status: open
title: duplicate Misc.lower
versions: Python 2.6
Added file: http://bugs.python.org/file9925/duplicateLower.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2536] itertools.permutations docstring is misleading

[Daniel Diniz]

New submission from Daniel Diniz <[EMAIL PROTECTED]>:

Currently, Modules/itertoolsmodule.c lines 2471-2475 are:

PyDoc_STRVAR(permutations_doc,
"permutations(iterables[, r]) --> permutations object\n\
\n\
Return successive r-length permutations of elements in the iterable.\n\n\
permutations(range(4), 3) --> (0,1,2), (0,1,3), (0,2,3), (1,2,3)");

but that describes  behavior of itertools.combinations. The correct
example is in a comment on line 2254 of the same file:

'permutations(range(3), 2) --> (0,1) (0,2) (1,0) (1,2) (2,0) (2,1)'


I used "misleading" instead of "wrong" because the current docstring
does show a subset of the real output and could be said to be
incomplete. If that is the case, I suggest being explicit:

'permutations(range(4), 3) --> (0, 1, 2), (0, 1, 3), (0, 2, 1), (0, 2,
3), (0, 3, 1), (0, 3, 2), (1, 0, 2), (1, 0, 3), (1, 2, 0), (1, 2, 3),
(1, 3, 0), (1, 3, 2), (2, 0, 1), (2, 0, 3), (2, 1, 0), (2, 1, 3), (2, 3,
0), (2, 3, 1), (3, 0, 1), (3, 0, 2), (3, 1, 0), (3, 1, 2), (3, 2, 0),
(3, 2, 1)'

--
components: Library (Lib)
messages: 64846
nosy: ajaksu2, rhettinger
severity: normal
status: open
title: itertools.permutations docstring is misleading
type: behavior
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2510] Bazaar ignore file

[Ralf Schmitt]

Ralf Schmitt <[EMAIL PROTECTED]> added the comment:

the same is true for me.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1602742] itemconfigure returns incorrect text property of text items

[Matthias Kievernagel]

Matthias Kievernagel <[EMAIL PROTECTED]> added the comment:

I no longer know what I meant with "document string is 
broken".
It is not very clear, but not broken.
It does not specify clearly the return value
in the case of 'without arguments'.

The problem is still present in trunk.
Problem is as far as I understand it:
Some return values from tcl are strings
that may contain spaces (or are even certain to contain 
spaces).
They are nonetheless translated to a Python tuple by
Tcl_SplitList in _tkinter.c.
There is no difference in syntax between tcl lists
and tcl strings (with spaces).
You have to have contextual knowledge to do the right thing.
This knowledge cannot be attached to itemconfigure alone
(for reconstitution of strings) because then information
about whitespace is already lost.
For return values known to be strings _tkinter/TkApp_SplitList
must not be used.

So I think it's a more general bug related to tcl string
return values.
Other Tkinter bugs may have the same explanation.
Don't know how to resolve this without a lot of work.

Matthias.

--
versions: +Python 2.6

_
Tracker <[EMAIL PROTECTED]>

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

[issue2513] 64bit cross compilation on windows

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

Christian, regarding shipping x64 .lib files as well as 32-bit ones -- 
sensible idea, but where would we place the x64 version libs?  In Python
[xx]\libs\amd64?  (This would mirror the approach used with PCbuild and 
PCbuild\amd64 -- although there's currently an ongoing discussion on 
this topic in python-dev.)

With regards to updating PCbuild/readme.txt, I'm planning on doing that 
by EOD today.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Daniel Diniz]

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

This patch updates the behavior as per "The Energy Policy Act of 2005":

  Start: Second Sunday in March
  End: First Sunday in November
  Time: 2 am local time

--
keywords: +patch
nosy: +ajaksu2
Added file: http://bugs.python.org/file9926/tzinfo-examples.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2444] Adding __iter__ to class Values of module optparse

[Shawn Morel]

Shawn Morel <[EMAIL PROTECTED]> added the comment:

gpolo: The argument still doesn't hold. As you point out, it's the 
Values class output from __str__ and other behaviour that is being un-
pythonic and leading you to believe it's a dictionary. Adding the 
__itter__ method would only make this worse. Then someone else would 
surely ask to have another __*__ method added since dictionaries support 
it but values don't.

The question then is one for optik. Why doesn't values simply inherit 
from dict and why does it insist on using __setattr__ rather than 
actually behaving completely like a dictionary. I know I was completely 
surprised by the following:

>>> (opts, args) = parser.parse_args(values={})
>>> print opts
{}
>>>

--
nosy: +shawnmorel

__
Tracker <[EMAIL PROTECTED]>

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

[issue2444] Adding __iter__ to class Values of module optparse

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I have asked that myself, shawnmore. Why not let Value subclass dict ?

__
Tracker <[EMAIL PROTECTED]>

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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Agreed that section of the docs should be more explicit in pointing out
that __getattr__ and __getattribute__ won't work for proxying special
methods for new-style classes.

It's also true that there are quite a few special methods where nothing
special is needed to correctly proxy the methods. That said, defining
all of the methods blindly is also bad (as a lot of informal type
testing is done by checking for certain special methods as attributes).

Perhaps it would be useful to have a method on type instances that could
be explicitly invoked to tell the type to run through all the tp_* slots
and populate them based on doing getattr(self, "__slotname__").

(Note that it's only those methods with dedicated slots in the C type
structure that are a problem here - those which are implemented solely
as normal Python methods like __enter__, __exit__ or the pickle module's
special methods can typically be overridden as expected through the use
of __getattr__ and __getattribute__)


Tracker <[EMAIL PROTECTED]>


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

[issue643841] New class special method lookup change

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

I've started a discussion on the Py3k development list regarding the
possibility of adding a new method to type to aid in converting proxy
classes from classic- to new-style.


Tracker <[EMAIL PROTECTED]>


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

[issue2531] float compared to decimal is silently incorrect.

[Facundo Batista]

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

Which version of 2.4 are you talking about?

This line in the tests...

  self.assertNotEqual(da, 32.7)

is there since almost 4 years ago (release 36325, and 2.4 is tagged in
release 37906).

Anyway, this behaviour is ok, as is the following:

>>> 2 < "1.9"
True

--
keywords: +easy -patch
nosy: +facundobatista
resolution:  -> rejected
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2210] Nested module import clutters package namespace

[Daniel Diniz]

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

Not a bug IMHO, but a gotcha. Change x.py to "from pack import y as q"
and you get the desired result. Check
http://effbot.org/zone/import-confusion.htm

--
nosy: +ajaksu2

__
Tracker <[EMAIL PROTECTED]>

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

[issue2527] Pass a namespace to timeit

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On Wed, Apr 2, 2008 at 2:42 AM, Peter Otten <[EMAIL PROTECTED]> wrote:

>  Alexander, I'm fine with a more specific argument name. ns was what
>  the Timer already used internally.
>

Maybe it should be "locals" after all.  It does not look like the
conflict with builtin locals() is an issue.  Note that this is what
__import__ uses.  I still recommend adding globals argument as well
for completeness and more accurate timings when timed code uses
globals.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1733757] RuntimeWarning: tp_compare didn't return -1 or -2

[Alain Spineux]

Alain Spineux <[EMAIL PROTECTED]> added the comment:

This has chnaged with python-2.5.2.
runing python openpkg under linux centos-5.1, 
the test case case4.py don't give any error message anymore, but
still block like with 2.5.1:
# strace -p 937
Process 937 attached - interrupt to quit
futex(0x9b9cc78, FUTEX_WAIT, 0, NULL

Hope this help

--
nosy: +aspineux
title: RuntimeWarning: tp_compare didn't return -1 or -2  -> RuntimeWarning: 
tp_compare didn't return -1 or -2

_
Tracker <[EMAIL PROTECTED]>

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

[issue2534] Speed up isinstance and issubclass

[Facundo Batista]

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

I find similar speedups:

isinstance(42, int)   -2%
isinstance(42, type)  45%
isinstance(object, type)  -1%
isinstance(object, int)   42%
isinstance(float, int)44%

(both negative ones are actually lower than original, but so low that it
could be considered timing glitches)

However, also I have an error in the test_exceptions.py suite:
[EMAIL PROTECTED]:~/devel/reps/python/trunk$ ./python
Lib/test/test_exceptions.py
testAttributes (__main__.ExceptionTests) ... ok
testInfiniteRecursion (__main__.ExceptionTests) ... FAIL
testKeywordArgs (__main__.ExceptionTests) ... ok
testRaising (__main__.ExceptionTests) ... ok
testReload (__main__.ExceptionTests) ... ok
testSettingException (__main__.ExceptionTests) ... ok
testSlicing (__main__.ExceptionTests) ... ok
testSyntaxErrorMessage (__main__.ExceptionTests) ... ok
testUnicodeStrUsage (__main__.ExceptionTests) ... ok
test_WindowsError (__main__.ExceptionTests) ... ok

==
FAIL: testInfiniteRecursion (__main__.ExceptionTests)
--
Traceback (most recent call last):
  File "Lib/test/test_exceptions.py", line 336, in testInfiniteRecursion
self.assertRaises(RuntimeError, g)
AssertionError: RuntimeError not raised

--
Ran 10 tests in 0.031s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_exceptions.py", line 351, in 
test_main()
  File "Lib/test/test_exceptions.py", line 348, in test_main
run_unittest(ExceptionTests)
  File "/home/facundo/devel/reps/python/trunk/Lib/test/test_support.py",
line 577, in run_unittest
_run_suite(suite)
  File "/home/facundo/devel/reps/python/trunk/Lib/test/test_support.py",
line 560, in _run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_exceptions.py", line 336, in testInfiniteRecursion
self.assertRaises(RuntimeError, g)
AssertionError: RuntimeError not raised

--
nosy: +facundobatista

__
Tracker <[EMAIL PROTECTED]>

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

[issue2513] 64bit cross compilation on windows

[Trent Nelson]

Trent Nelson <[EMAIL PROTECTED]> added the comment:

Updated PCbuild/readme.txt in r62105 and r62106 for trunk and py3k
respectively.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2529] list/generator comprehension parser doesn't match spec

[Nick Guenther]

Nick Guenther <[EMAIL PROTECTED]> added the comment:

Oh, okay. That's really confusing because I expect "in" to always return
a bool, but in the spirit of python there's no reason it should I guess.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2444] Adding __iter__ to class Values of module optparse

[Steven Bethard]

Steven Bethard <[EMAIL PROTECTED]> added the comment:

Subclassing dict seems like a bad idea. The options value returned by
.parse_args() is not supposed to be dict-like, it's supposed to be
object-like. That is, the natural way of accessing values from it is
through dotted attribute access, not dict-indexing access. All the
documentation for the module makes this clear. Giving it both attribute
access and dict-indexing access would violate TOOWTDI. The One Obvious
way to get dict-indexing access from an attribute oriented object is
already vars().

__
Tracker <[EMAIL PROTECTED]>

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

[issue2532] file that breaks 2to3 (despite being correct python)

[Collin Winter]

Collin Winter <[EMAIL PROTECTED]> added the comment:

Yes, this is a known problem with the pattern matching system.

--
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1555570] email parser incorrectly breaks headers with a CRLF at 8192

[Karen Tracey]

Karen Tracey <[EMAIL PROTECTED]> added the comment:

Opening the file in universal newline mode doesn't work for cases where
the 'file' contains multipart MIME data (eg. multipart/form-data) where
one of the included parts is binary data (eg. application/octet-stream).
 In that case, blind translation of CRLF to LF may corrupt the binary
data.  (Thanks to Thomas Guettler for pointing that out to me.)

FeedParser goes to considerable trouble to split on any conceivable line
boundary but retain whatever line boundary existed in the stream when
putting things back together.  (Look at BufferedSubFile's push() code in
feedparser.py.)  It was not written on the assumption that it would be
getting LFs only.  

The only code that knows enough to know which CRLFs are really line
breaks is the code that is breaking the stream up based on the boundary
markers -- that is the FeedParser code.  It isn't safe for the caller to
do any CRLF conversions before calling the Parser.  Therefore I believe
the fix needs to be made to the parser.py code, not the docs.

Two people that I know of independently re-discovered this bug in the
last couple of weeks (running Django), after I re-discovered it about
three months ago after Jeremy Dunck re-discovered it a year earlier,
three months after it was originally opened.  Maybe a corner case, but
it would be nice, since it is quite difficult for people to track down,
and the fix is so trivial, if the fix could be put in.

_
Tracker <[EMAIL PROTECTED]>

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

[issue2537] re.compile(r'((x|y+)*)*') should fail

[Jason Orendorff]

New submission from Jason Orendorff <[EMAIL PROTECTED]>:

Below, the second regexp seems just as guilty as the first to me.

Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile(r'((x|y)*)*')
Traceback (most recent call last):
  File "", line 1, in 
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py",
line 180, in compile
return _compile(pattern, flags)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py",
line 233, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
>>> re.compile(r'((x|y+)*)*')
<_sre.SRE_Pattern object at 0x18548>

I don't know if that error is to protect the sre engine from bad
patterns or just a courtesy to users.  If the former, it could be a
serious bug.

--
messages: 64865
nosy: jorendorff
severity: normal
status: open
title: re.compile(r'((x|y+)*)*') should fail
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2517] Error when printing an exception containing a Unicode string

[Christoph Burgmer]

Christoph Burgmer <[EMAIL PROTECTED]> added the comment:

JFTR:
> print unicode(e.message).encode("utf-8")
only works for Python 2.5, not downwards.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1733757] RuntimeWarning: tp_compare didn't return -1 or -2

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

The "funny" errors around trace & exceptions have been corrected with
issue1265.

The remaining problem is a livelock: when the interpreter exits, 
threading.Thread.__delete is called, and this calls
"_active_limbo_lock.acquire".

But the sys.settrace is still enabled... and threading.currentThread()
can also call "_active_limbo_lock.acquire" when the main thread cannot
be found...

A solution could be to clear sys.settrace when closing the interpreter.

--
nosy: +amaury.forgeotdarc

_
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

Hi Daniel,

Can you change it so that the start and end values are chosen
dynamically based on the year?  I.e. if year < 2007 use the old values
otherwise use the new ones.  A tzinfo object is supposed to (within
reason) handle historical times accurately.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2534] Speed up isinstance and issubclass

[Daniel Diniz]

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

The test fails on this:

def g():
try:
return g()
except ValueError:
return -1
self.assertRaises(RuntimeError, g)


Changing that "return -1" to "return sys.exc_info()" shows that a
RuntimeError was raised indeed. Also, using TypeError or TabError
instead of ValueError gives the same result.

Shallow testing of the new methods seem to show normal results,

[Runtime,Value]Error.__[subclass,instance]check__([Runtime,Value]Error)

is False for cross-checks and True otherwise.

--
nosy: +ajaksu2

__
Tracker <[EMAIL PROTECTED]>

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

[issue2534] Speed up isinstance and issubclass

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

Running Daniels code interactively, with a debug build on Windows,
additionally prints 'XXX undetected error' before the Runtime error is
raised.

I cannot see anything that is wrong with my code.  Maybe this, and the
test failure, has to do with the fact that the new
'type___subclasscheck__' function is sometimes called with the error
indicator already set?  Maybe some PyErr_Fetch() and PyErr_Restore()
calls are needed inside this function, similar to what
PyObject_IsSubclass() does?  I must admit that I do not really
understand the purpose of these calls...

Anyway, I attach a new, cleaner patch although this one still behaves in
the same, buggy, way: type_instancecheck-2.diff.

Added file: http://bugs.python.org/file9927/type_instancecheck-2.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2444] Adding __iter__ to class Values of module optparse

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Given the disagreement found here, I suggest closing this rfe and moving
further discussions to c.l.p.
Thanks djc and rhettinger for your support, and, bethard and shawnmorel
for your different p.o.v.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Daniel Diniz]

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

That was a such silly mistake, sorry :)

Updated patch tries to keep the old behavior, but I just found out it's
mostly wrong too (DST start and end days changed a bit in the last 80
years).

>From http://aa.usno.navy.mil/faq/docs/daylight_time.php (quoted below),
I believe the best correctness/simplicity compromise would be:

 1966-1986: from the last Sunday in April to the last Sunday in October
1987-2006: from the first  Sunday in April to the last Sunday in October
2007-: from the last Sunday in March  to the second Sunday in November

Should I try it like that? Or would more attention to detail be better?

quote:
"Although standard time in time zones was instituted in the U.S. and
Canada by the railroads in 1883, it was not established in U.S. law
until the Act of March 19, 1918, sometimes called the Standard Time Act.
The act also established daylight saving time, a contentious idea then.
Daylight saving time was repealed in 1919, but standard time in time
zones remained in law. Daylight time became a local matter. It was
re-established nationally early in World War II, and was continuously
observed from 9 February 1942 to 30 September 1945. After the war its
use varied among states and localities. The Uniform Time Act of 1966
provided standardization in the dates of beginning and end of daylight
time in the U.S. but allowed for local exemptions from its observance.
The act provided that daylight time begin on the last Sunday in April
and end on the last Sunday in October, with the changeover to occur at 2
a.m. local time.

During the "energy crisis" years, Congress enacted earlier starting
dates for daylight time. In 1974, daylight time began on 6 January and
in 1975 it began on 23 February. After those two years the starting date
reverted back to the last Sunday in April. In 1986, a law was passed
that shifted the starting date of daylight time to the first Sunday in
April, beginning in 1987. The ending date of daylight time was not
subject to such changes, and remained the last Sunday in October. The
Energy Policy Act of 2005 changed both the starting and ending dates.
Beginning in 2007, daylight time starts on the second Sunday in March
and ends on the first Sunday in November."

Added file: http://bugs.python.org/file9928/tzinfo-examples2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Daniel Diniz]

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

Er...
2007- : from the second Sunday in March to the first Sunday in November.

:/

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Daniel Diniz]

Changes by Daniel Diniz <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9926/tzinfo-examples.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is out of date

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

I'd be okay with only covering 1987 and later. But it's probably good
to have a table-based solution anway, to make it easy to handle future
changes -- I'm sure 2007 is not the last year this is changing. :-)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2534] Speed up isinstance and issubclass

[Daniel Diniz]

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

Thomas: I confirm your patch triggers this behavior.  I can reliably get
a __subclasscheck__ error by trying to "import sys" after the bogus
catching happens:

>>> def g():
...   try:
... return g()
...   except ValueError:
... return sys.exc_info()
...
>>> g()
(, 'maximum recursion depth exceeded
while calling a Python object', )
>>> import sys
Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: maximum recursion depth exceeded in __subclasscheck__

I hope this helps...

__
Tracker <[EMAIL PROTECTED]>

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

[issue2517] Error when printing an exception containing a Unicode string

[Benjamin Peterson]

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

We can't do much about that because only security fixes are backported
to version < 2.5.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2316] TimedRotatingFileHandler names files incorrectly if nothing is logged during an interval

[Vinay Sajip]

Vinay Sajip <[EMAIL PROTECTED]> added the comment:

Updated SVN, but not backported to 2.5 or earlier maintenance branches.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2424] Logging module hides user code errors (bare except)

[Vinay Sajip]

Vinay Sajip <[EMAIL PROTECTED]> added the comment:

This has already been fixed in trunk.

--
nosy: +vsajip
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2315] TimedRotatingFileHandler does not account for daylight savings time

[Vinay Sajip]

Vinay Sajip <[EMAIL PROTECTED]> added the comment:

Updated SVN, but not backported to 2.5 or earlier maintenance branches.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2444] Adding __iter__ to class Values of module optparse

[Benjamin Peterson]

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

Closing on OP's request.

--
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2318] TimedRotatingFileHandler: rotate every month, or every year

[Vinay Sajip]

Vinay Sajip <[EMAIL PROTECTED]> added the comment:

I'm not sure how much of a need there is for this, and I don't have much
think time I can devote to it, but I'll be happy to consider a patch ;-)

--
resolution:  -> later
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2317] TimedRotatingFileHandler logic for removing files wrong

[Vinay Sajip]

Vinay Sajip <[EMAIL PROTECTED]> added the comment:

Updated SVN, but not backported to 2.5 or earlier maintenance branches.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2507] Exception state lives too long in 3.0

[Barry A. Warsaw]

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:

Knocking the priority down to critical for the next alpha release.  This
can be readdressed once the release is made.

--
nosy: +barry
priority: release blocker -> critical

__
Tracker <[EMAIL PROTECTED]>

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

[issue2513] 64bit cross compilation on windows

[Mark Hammond]

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

I'd like to keep this issue specifically about cross-compilation in the
current tree, and while some of the other ideas may have merit, let's
not bog this issue down with them unless they directly impact the patch.

Does anyone have any comments or concerns about my patch?  Anything
people would like to see changed before I check it in?

Martin - my patch creates a new executable in Lib\distutils\command, and
IMO it should be included in binary builds for all windows platforms. 
Is there something I should change in the MSI process?

__
Tracker <[EMAIL PROTECTED]>

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

[issue1561] py3k: test_mailbox fails on Windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Applied 2nd solution as r61951

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2538] memoryview of bytes is not readonly

[Amaury Forgeot d'Arc]

New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:

Bytes should be immutable, but in test_socket.py:
buf = b" "*1024
nbytes = self.cli_conn.recv_into(buf)

This patch attempts to enforce readonly buffer on bytes

--
components: Interpreter Core
files: buffer.patch
keywords: patch
messages: 64886
nosy: amaury.forgeotdarc
severity: normal
status: open
title: memoryview of bytes is not readonly
versions: Python 3.0
Added file: http://bugs.python.org/file9929/buffer.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2538] memoryview of bytes is not readonly

[Gregory P. Smith]

Changes by Gregory P. Smith <[EMAIL PROTECTED]>:


--
nosy: +gregory.p.smith

__
Tracker <[EMAIL PROTECTED]>

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

[issue2539] Windows Registry issue with 2.5.2 AMD64 msi

[Jason]

New submission from Jason <[EMAIL PROTECTED]>:

I have tried multiple times and even checking manually, but the
Python 2.5.2 AMD64 msi installer does not register Python correctly, or
it doesn't enter it into the registry correctly.  I'm not sure.  I
install it after uninstalling 2.5.1 and and when I try to install
wxPython2.8 and pygtk-2.10.6 both give me an error that they cannot find
Python or its path in the registry.  I reinstall 2.5.1 and it all works
perfectly.  I'm using all default selections and just clicking
"Next,Next,Next, etc."

--
components: Installation
messages: 64887
nosy: iggyboo
severity: normal
status: open
title: Windows Registry issue with 2.5.2 AMD64 msi
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2540] If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto <[EMAIL PROTECTED]>:

I noticed compiler warned "'longval' is not used anywhere."
And I found 'longval' was not initialized where HAVE_LONG_LONG
was not defined. Is attached patch intended behavior? Thanks.

--
components: Extension Modules
files: fix.patch
keywords: easy, patch, patch
messages: 64888
nosy: ocean-city
severity: normal
status: open
title: If HAVE_LONG_LONG is not defined, longval will not be initialized 
(_sqlite)
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9930/fix.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2540] If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

Oh, I forgot this. When I debuged with
#undef HAVE_LONG_LONG
I noticed test_sqlite.py failed with this error message.

==
ERROR: CheckLargeInt (sqlite3.test.types.SqliteTypeTests)
--
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\sqlite3\test\types.py", line 52, in
CheckLargeInt

self.cur.execute("insert into test(i) values (?)", (num,))
OverflowError: Python int too large to convert to C long

==
ERROR: CheckLargeInt (sqlite3.test.types.DeclTypesTests)
--
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\sqlite3\test\types.py", line 146, in
CheckLargeIn
t
self.cur.execute("insert into test(i) values (?)", (num,))
OverflowError: Python int too large to convert to C long

Maybe some fix for test is needed?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2540] If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>:


--
keywords:  -easy

__
Tracker <[EMAIL PROTECTED]>

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

[issue2541] Unicode escape sequences not parsed in raw strings.

[John Millikin]

New submission from John Millikin <[EMAIL PROTECTED]>:

According to
,
raw strings with \u and \U escape sequences should have these sequences
parsed as usual. However, they are currently escaped.

>>> r'\u0020'
'\\u0020'

Expected:
>>> r'\u0020'
' '

--
components: Unicode
messages: 64890
nosy: jmillikin
severity: normal
status: open
title: Unicode escape sequences not parsed in raw strings.
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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