[issue2223] regrtest.py -R not working

[Hirokazu Yamamoto]

Hirokazu Yamamoto added the comment:

>I'll run py regrtest.py -R :: on r61203 - r61098 and compare its
>result to Alexander's result, but my machine is damn slow, probably
>it'll take long time.

Sorry, I abandoned this at test_compiler. Please forget this sentense...

Anyway, Christian's fix greatly works for me. Thanks!

>E:\python-dev\trunk\Lib\test>py regrtest.py -R :: test_collections.py

For this error, I could write a minimam code to reproduce it.
Please expand the attached zip file into lib/test and run a.py.
You'll see similar error.

Added file: http://bugs.python.org/file9599/doctest_twice.zip

__
Tracker <[EMAIL PROTECTED]>

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

[issue2127] sqlite3 docs should mention utf8 requirement

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Sorry, my patch corrected only sqlite3.Connection().
I join a new version, which also changes sqlite3.connect().

By the way, the test should test that the file is created with the
correct name. A call to os.stat() could be enough.

Added file: http://bugs.python.org/file9600/sqlite_connect2.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2127] sqlite3 docs should mention utf8 requirement

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc:


Removed file: http://bugs.python.org/file9474/sqlite_connect.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2223] regrtest.py -R not working

[Hirokazu Yamamoto]

Hirokazu Yamamoto added the comment:

I wrote simple patch to workaround this problem.
(avoid to reuse DocTestSuite)

# To my eyes, doctest.DocTestSuite(module=collections)
# and test_support.run_doctest(collections, verbose)
# are doing same test???

Added file: http://bugs.python.org/file9601/fix_test_collections.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2222] Memory leak in os.rename?

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

The affected code is the only case I could find in stdlib where O& 
format was used to populate PyObject* variables.  Although it appears to 
be valid usage, the code presents an exception to the following note at 
http://docs.python.org/dev/c-api/arg.html : "Note that any Python object 
references which are provided to the caller are borrowed references; do 
not decrement their reference count!"

Should we add that O& a possible exception to this rule?  I'll propose a  
specific change if we agree in principle.  I am not sure if O& 
documentation should make any recommendations to the writers of 
conversion functions.  For example, O& convertors returning a borrowed 
reference may be discouraged in favor of O or O& variants or returning 
PyObject* from a convertor may be discouraged altogether.

I am adding Georg who accepted my other documentation changes in this 
area to the "nosy" list.

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue2231] Memory leak in itertools.chain()

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto:

Fixed memory leak in itertools.chain().
This fixes following refleak errors shown in issue2223.
test_deque test_heapq test_itertools test_list test_set test_userlist

--
components: Extension Modules
files: fix_leak.patch
keywords: patch
messages: 63252
nosy: ocean-city
severity: normal
status: open
title: Memory leak in itertools.chain()
type: resource usage
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9602/fix_leak.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2231] Memory leak in itertools.chain()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Good catch, Hirokazu!

The patch looks correct to me.

Works as advertised on Mac OS 10.4.

--
nosy: +belopolsky

__
Tracker <[EMAIL PROTECTED]>

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

[issue2231] Memory leak in itertools.chain()

[Raymond Hettinger]

Changes by Raymond Hettinger:


--
assignee:  -> rhettinger
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue2223] regrtest.py -R not working

[Raymond Hettinger]

Changes by Raymond Hettinger:


--
assignee:  -> rhettinger
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8.

[Trent Nelson]

New submission from Trent Nelson:

posix_tmpfile() needs to be reworked such that tmpfile() isn't used if 
MS_WINDOWS is defined, as it requires administrative privileges to run 
(it creates the file in the root directory) on Vista/2k8 (although 
there are reports of this not working on XP w/ 2.5: 
http://www.thescripts.com/forum/thread600423.html).

The recommended approach in MSDN is to use, quote, "tmpname or tempnam 
in conjunction with fopen": http://msdn2.microsoft.com/en-
us/library/x8x7sakw(VS.80).aspx

Assuming no one beats me to it, I'll look at creating a patch in the 
next day or two when I get some spare time.

--
components: Windows
messages: 63254
nosy: Trent.Nelson
severity: normal
status: open
title: Current os.tmpfile() implementation requires admin privs on Vista/2k8.
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

[issue2222] Memory leak in os.rename?

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

On the test_os patch: I would rename LeakTest to ErrorTest and leave it 
on for all platforms.  BTW, I cannot produce a definitive proof that 
posix_2str leaks when second conversion fails (regrtest -R does not 
catch it because the leaked buffer is not a PyObject).  Nevertheless, it 
would be a good idea to add tests that exercise os.rename("foo", 0), 
os.link("foo", 0) and os.symlink("foo", 0) errors on all platforms.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2225] py_compile.main() does not return error code

[A.M. Kuchling]

Changes by A.M. Kuchling:


--
keywords: +easy

__
Tracker <[EMAIL PROTECTED]>

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

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

[Jason Tishler]

New submission from Jason Tishler:

Makefile.pre.in contains extra slash before $(DESTDIR) in two locations
as in the following:

sharedinstall:
$(RUNSHARED) ./$(BUILDPYTHON) -E $(srcdir)/setup.py install \
--prefix=$(prefix) \
--install-scripts=$(BINDIR) \
--install-platlib=$(DESTSHARED) \
--root=/$(DESTDIR)

This causes Cygwin builds to fail if DESTDIR is set as follows:

creating //tmp
error: could not create '//tmp': No such host or network path

The following Open Group Specification:

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html

indicates the following:

4.11 Pathanme Resolution 

[snip]

A pathname that begins with two successive slashes may be interpreted
in an implementation-defined manner,...

IMO, these extra slashes should be removed as indicated in the
attached patch.  OK to commit?  If so, to which branches?

--
assignee: jlt63
components: Build
files: python.patch
keywords: patch, patch
messages: 63256
nosy: jlt63
priority: low
severity: normal
status: open
title: Makefile.pre.in contains extra slash before $(DESTDIR) which can cause 
Cygwin build to fail
type: compile error
versions: Python 2.5
Added file: http://bugs.python.org/file9603/python.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2234] cygwinccompiler.py fails for latest MinGW releases.

[Lenard Lindstrom]

New submission from Lenard Lindstrom:

The cygwinccompiler.py module for distutils on Pythons 2.5 and 2.4 fails
with an exception for the latest MinGW tools.

running build_ext
Traceback (most recent call last):
  File "setup.py", line 224, in 
setup(**PACKAGEDATA)
  File "C:\PRG\PYTHON25\lib\distutils\core.py", line 151, in setup
dist.run_commands()
  File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 974, in run_commands
self.run_command(cmd)
  File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "C:\PRG\PYTHON25\lib\distutils\command\build.py", line 112, in run
self.run_command(cmd_name)
  File "C:\PRG\PYTHON25\lib\distutils\cmd.py", line 333, in run_command
self.distribution.run_command(command)
  File "C:\PRG\PYTHON25\lib\distutils\dist.py", line 994, in run_command
cmd_obj.run()
  File "setup.py", line 186, in run
build_ext.run(self)
  File "C:\PRG\PYTHON25\lib\distutils\command\build_ext.py", line 264,
in run
force=self.force)
  File "C:\prg\pygame\trunk_\mingw32distutils.py", line 31, in new_compiler
return Mingw32DefaultCCompiler (None, dry_run, force)
  File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 292, in
__init__

CygwinCCompiler.__init__ (self, verbose, dry_run, force)
  File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 84, in
__init__
get_versions()
  File "C:\PRG\PYTHON25\lib\distutils\cygwinccompiler.py", line 424, in
get_vers
ions
ld_version = StrictVersion(result.group(1))
  File "C:\PRG\PYTHON25\lib\distutils\version.py", line 40, in __init__
self.parse(vstring)
  File "C:\PRG\PYTHON25\lib\distutils\version.py", line 107, in parse
raise ValueError, "invalid version number '%s'" % vstring
ValueError: invalid version number '2.18.50.20080109'

For instance "ld -v" now returns "GNU ld (GNU Binutils)
2.18.50.20080109", not "GNU ld version 2.17.50 20060824". The extra
period between the version number and date causes class StrictVersion to
raise a ValueError. A fix is to alter the regular expressions in
cygwinccompiler.get_versions().

This enclosed patch to cygwinccompiler.py has been tested with the
current and previous linker as well as gcc 4.2.1 and gcc 3.4.5.

--
components: Distutils
files: cygwinccompiler.patch
keywords: patch
messages: 63257
nosy: kermode
severity: normal
status: open
title: cygwinccompiler.py fails for latest MinGW releases.
versions: Python 2.5
Added file: http://bugs.python.org/file9604/cygwinccompiler.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

[Jason Tishler]

Changes by Jason Tishler:


__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[jason kirtland]

New submission from jason kirtland:

In 2.6a, seems like the __hash__ implementation and __eq__ must be
defined together, in the same class.  See also #1549.  Ensuring that a
__hash__ implementation isn't being pulled from a builtin type is
probably a sufficient check...?

>>> class Base(object):
... def __init__(self, name):
... self.name = name
... def __eq__(self, other):
... return self.name == other.name
... def __hash__(self):
... return hash(self.name)
... 
>>> class Extended(Base):
... def __eq__(self, other):
... print "trace: __eq__ called"
... return Base.__eq__(self, other)
... 
>>> hash(Base('b1'))
603887253
>>> hash(Extended('e1'))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unhashable type: 'Extended'

--
components: Interpreter Core
messages: 63258
nosy: jek
severity: normal
status: open
title: __eq__ / __hash__ check doesn't take inheritance into account
type: crash
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

[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter

[Henrique Romano]

New submission from Henrique Romano:

The default value for mkpath's mode parameter is 0777 but it isn't used
at any place; attached is a patch that just pass the parameter to
os.mkdir call, this seems to fix the problem.

--
components: Library (Lib)
files: python2.5-distutils_mkpath_filemode.v1.diff
keywords: patch
messages: 63259
nosy: henrique
severity: normal
status: open
title: Distutils' mkpath implementation ignoring the "mode" parameter
type: resource usage
versions: Python 2.5
Added file: 
http://bugs.python.org/file9605/python2.5-distutils_mkpath_filemode.v1.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8.

[Christian Heimes]

Christian Heimes added the comment:

Side note:
I've removed the methods from Python 3.0 about half a year ago. Code
should use the tempfile module anyway. Does any of the Python 2.6 stdlib
code use an os.tmp* method?

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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

[issue2237] Inconsistent variable lookup

[Sylwester Warecki]

New submission from Sylwester Warecki:

Hi!

An example below shows how differently local variables are treated in
case of simple variables and classes. In case of objects the variable
refers to global object, in case of simple number - it refers to a local.

Example 2 shows worse case scenario. 
>From the text alone of the test2() function it is impossible to forsee
its behavior (!). If there is no global variable 'a' then it crashes
although without declaration of 'a' as a global it runs fine with the
'+' operator on 'a'. However that will not be the case IF test3() is
invoked.
That is illogical.

Example 3 shows the worst case scenario.
functions z0 and z1 differ only by the variable name on the left side of
the equation. In first case a is understood as global in second as
local. What makes no sense is that the right side of equation does not
change, however its interpretation is based on the left side of the
equation. 

Example 4
This is an alteration of example 3 that shows the problem in full swing.
2 functions differ only by 2 last lines and yet they interpret the
variables in completely different way. In other words, adding a line to
end the code AFFECTS its beginning. That is least to say bizzaare.
..

I tried to keep examples simple - hopefully that will help.

Regards,
Sylwester

=

class cheat:
  def __init__( self ):
self.q = 4

a = cheat( )
b = 3

def test():
  a.q = 22
  b   = 65
  print "test a=", a.q
  print "test b=", b
  
print "a=", a.q
print "b=", b

test()

print "a=", a.q
print "b=", b


=

example 2

class cheat2:
  def __init__( self ):
self.q = 4
  def __add__( self, val ):
self.q += val

a=cheat2()

def test2():
  c = a + 4
  print a.q

def test3():
  a += 4

test2()
test3()

===
example 3

def z0():
  c = a + 2

def z1():
  a = a + 2

a = 10

z0()
z1()

=
example 4

def t1():
  print a
  x=a+2
  print x

An example below shows how differently local variables are treated in
case of simple variables and classes. In case of objects the variable
refers to global object, in case of simple number - it refers to a local.

Example 2 shows worse case scenario. 
>From the text alone of the test2() function it is impossible to forsee
its behavior (!). If there is no global variable 'a' then it crashes
although without declaration of 'a' as a global it runs fine with the
'+' operator on 'a'. However that will not be the case IF test3() is
invoked.
That is illogical.

Example 3 shows the worst case scenario.
functions z0 and z1 differ only by the variable name on the left side of
the equation. In first case a is understood as global in second as
local. What makes no sense is that the right side of equation does not
change, however its interpretation is based on the left side of the
equation. 

Example 4
This is an alteration of example 3 that shows the problem in full swing.
2 functions differ only by 2 last lines and yet they interpret the
variables in completely different way. In other words, adding a line to
end the code AFFECTS its beginning. That is least to say bizzaare.
..

I tried to keep examples simple - hopefully that will help.

Regards,
Sylwester

=

class cheat:
  def __init__( self ):
self.q = 4

a = cheat( )
b = 3

def test():
  a.q = 22
  b   = 65
  print "test a=", a.q
  print "test b=", b
  
print "a=", a.q
print "b=", b

test()

print "a=", a.q
print "b=", b


=

example 2

class cheat2:
  def __init__( self ):
self.q = 4
  def __add__( self, val ):
self.q += val

a=cheat2()

def test2():
  c = a + 4
  print a.q

def test3():
  a += 4

test2()
test3()

===
example 3

def z0():
  c = a + 2

def z1():
  a = a + 2 # crash will happen here

a = 10

z0()
z1()

=
example 4

def t1():
  print a
  x=a+2
  print x

def t2():
  print a  #crash will happen here
  x=a+2
  print x
  a=a+4
  print a

t1()
t2() # this one will crash!

--
components: Interpreter Core
messages: 63261
nosy: swarecki
severity: normal
status: open
title: Inconsistent variable lookup
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

[issue2237] Inconsistent variable lookup

[Benjamin Peterson]

Changes by Benjamin Peterson:


--
type:  -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2232] Current os.tmpfile() implementation requires admin privs on Vista/2k8.

[Benjamin Peterson]

Benjamin Peterson added the comment:

According to grep, the only place where os.tmp* is referenced is in test_os.

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

This issue is similar to issue1549. Note that only new-style classes are
concerned.

I think the change was intentional. Guido, do you confirm?

However there should be some documentation about it, a NEWS entry or an
item in the "porting to 2.6" section.

The initial modification appeared in the py3k branch (r51454):
"""
Change the way __hash__ is inherited; when __eq__ or __cmp__ is
overridden but __hash__ is not, set __hash__ explicitly to None (and
tp_hash to NULL).
"""

--
nosy: +amaury.forgeotdarc, gvanrossum
type: crash -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Raymond Hettinger]

Raymond Hettinger added the comment:

Wouldn't you expect this sort of thing to break code?  Does it meet the
criteria for backporting to 2.6?

--
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Guido van Rossum]

Guido van Rossum added the comment:

The py3k feature was intentional.

I'm not sure who did the backport (could've been me, long ago).  I think
the backport should be replaced with a warning that is only issued when
-3 is given.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Raymond Hettinger]

Changes by Raymond Hettinger:


--
priority:  -> high

__
Tracker <[EMAIL PROTECTED]>

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

[issue2237] Inconsistent variable lookup

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

> ... adding a line to end the code AFFECTS its beginning ...

Exactly. Please see
http://docs.python.org/dev/reference/executionmodel.html
"""
If a name binding operation occurs anywhere within a code block, all
uses of the name within the block are treated as references to the
current block. This can lead to errors when a name is used within a
block before it is bound. This rule is subtle. Python lacks declarations
and allows name binding operations to occur anywhere within a code
block. The local variables of a code block can be determined by scanning
the entire text of the block for name binding operations.
"""

For more general discussions, see also:
http://www.python.org/doc/faq/programming/#what-are-the-rules-for-local-and-global-variables-in-python
http://docs.python.org/dev/tutorial/classes.html#python-scopes-and-name-spaces

In other words, this is one of the key features of the python language,
and I don't see how it could change.

--
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

[issue2231] Memory leak in itertools.chain()

[Raymond Hettinger]

Raymond Hettinger added the comment:

Fixed in r61237.

--
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

[issue2218] Enhanced hotshot profiler with high-resolution timer

[Jean Brouwers]

Jean Brouwers added the comment:

Attached are the improved hotspot files, rev 2.  The changes are rather 
drastic, in particular since hires time delta's may exceed 32-bit int.

These 3 files have been tested with Python 2.5.2 only and on 32-bit 
Linux and MacOS X and on 64-bit Linux and Solaris 10.  They do pass the 
hotspot and other tests.

However, no other platforms or compilers have been tested.  Except for 
64-bit PPC, the code should fall back to the previous behavior using 
gettimeofday.

Added file: http://bugs.python.org/file9606/hires_hotshot2.tgz

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

The attached patch reverts r59576 and the part of r59106 about the
tp_hash slot.

It also adds the py3k warning::
   type defines __eq__ but not __hash__, and will not be hashable in 3.x
printed when calling hash() on such an object.

--
keywords: +patch
Added file: http://bugs.python.org/file9607/inherit_hash.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

I noticed that my patch uses Py_TYPE(self)->tp_hash, whereas normal
processing of slot_tp_hash() uses lookup_method(self,"__hash__",hash_str).

I am almost sure that both expressions return the same value.
Is this correct? Py_TYPE(self)->tp_hash seems much faster.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Guido van Rossum]

Guido van Rossum added the comment:

>  I noticed that my patch uses Py_TYPE(self)->tp_hash, whereas normal
>  processing of slot_tp_hash() uses lookup_method(self,"__hash__",hash_str).
>
>  I am almost sure that both expressions return the same value.
>  Is this correct? Py_TYPE(self)->tp_hash seems much faster.

HERE BE DRAGONS

There are cases where Py_TYPE(self)->tp_hash is the function currently
executing (some wrapper(s) in typeobject.c). OTOH, lookup_method(...)
finds the Python code in the class __dict__s along the MRO.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Ah, I remember that it took me some time to understand the boundaries
between a slot and the corresponding special method.

Here is another version of the patch, which does not test tp_hash while
we are currently running the tp_hash function...
I also added the warning for old-style classes.

Added file: http://bugs.python.org/file9608/inherit_hash2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2238] TypeError instead of SyntaxError for syntactically invalid gen exp

[Nathan Collins]

New submission from Nathan Collins:

I have a file f1.py

$ cat f1.py
import os
(lambda **x:x)(**dict(y,y for y in ()))

and when I run it

$ python f1.py
Traceback (most recent call last):
  File "f1.py", line 1, in 
import os
TypeError: 'int' object is not iterable

Notice that the TypeError exception is from the import os on line 1.
But the import isn't the problem.  The problem is the illegal
generator expression on line 2.  I.e. if

$ cat f2.py
#import os
dict(y,y for y in ())

then

$ python f2.py
  File "f2.py", line 2
dict(y,y for y in ())
SyntaxError: Generator expression must be parenthesized if not sole argument

The mess

(lambda **x:x)(**dict(y,y for y in ()))

is a simplified version of something I had about 100 lines into a
file, but the resulting TypeError still complains about an import on
line 1, which is really confusing.

I'm using

Python 2.5.2 (r252:60911, Mar  4 2008, 14:33:51)
[GCC 3.4.4] on linux2

for python.



The above is probably a good enough description, but here's some more
weirdness in case it's helpful:

Some variations of f1.py cause the same error, but others don't.
E.g. if f4.py is

for c in [1]: pass
(lambda **x:x)(**dict(y,y for y in ()))

I get

Traceback (most recent call last):
  File "f4.py", line 1, in 
for c in [1]: pass
TypeError: 'int' object is not iterable

as before.  But if f5.py is

for c in "1": pass
(lambda **x:x)(**dict(y,y for y in ()))

running the script results in no output and a successful run

$ echo $?
0

Finally, if f6.py is just the single line

(lambda **x:x)(**dict(y,y for y in ()))

then my 2.5.2 python has the same successful with no output result as
for f5.py, but if I run f6.py in an older

Python 2.5 (r25:51908, Oct 30 2006, 16:20:39)
[GCC 3.4.4] on linux2

python I get

Exception exceptions.SyntaxError: ('Generator expression must be
parenthesized if not sole argument', 1) in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
zsh: abort (core dumped)  python f6.py

The older 2.5 python runs f5.py successfully with no output like 2.5.2 does.

I searched the bug tracker for "TypeError: 'int' object is not
iterable" and didn't find anything, so I'm assuming this bug is
unknown.  I'm sure someone will let me know if I'm mistaken =)

I'd guess the problem has to do with a bad parse.

--
components: None
messages: 63273
nosy: NathanCollins
severity: normal
status: open
title: TypeError instead of SyntaxError for syntactically invalid gen exp
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

[issue2238] TypeError instead of SyntaxError for syntactically invalid gen exp

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

Interestingly, in debug mode, the message "XXX undetected error" is
printed to stderr.
And this gives the solution: in ast.c, some calls did not check the
return status.

Committed revision 61240, will backport to 2.5.
Thanks for the report!
Thanks for the report!

--
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> pending

__
Tracker <[EMAIL PROTECTED]>

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

[issue2223] regrtest.py -R not working

[Hirokazu Yamamoto]

Hirokazu Yamamoto added the comment:

I did more investigation.
Failure on second DocTestSuite run happens because
lib/doctest.py (2107) test.globs.clear()
is executed after first test runs.

I don't know if this is bug or not. Document in
doctest.py says test.globs will be untouched on
failure but become empty on success, but this
behavior prevents reusage of DocTestSuite.

__
Tracker <[EMAIL PROTECTED]>

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