[issue1510] help for file/open should state which is prefered.

[Christian Heimes]

Christian Heimes added the comment:

I agree!

Can you provide a patch please?

--
assignee:  -> tiran
nosy: +tiran
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue1509] Documentation lacking for the sqlite3 module.

[Christian Heimes]

Christian Heimes added the comment:

Are you able to provide a patch? Please use a snapshot or svn checkout
of 2.5 for the patch. We have a new documentation system.

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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

[issue1508] Removal of stale code in _csv.c / pyexpat.c

[Christian Heimes]

Christian Heimes added the comment:

Fixed in r59214
Thanks Joseph! Can you find more?

--
keywords: +py3k
nosy: +tiran
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

[issue1509] Documentation lacking for the sqlite3 module.

[Peter Mawhorter]

Peter Mawhorter added the comment:

I could try, but I honestly don't know exactly how the fetch*
functions work. It would probably take me a good couple of hours of
reading before I could write decent documentation, and as much as that
would be great, I'm not about to squeeze that into my college
schedule. I don't actually have a 2.5 checkout, but I thought that at
one point those methods were documented. Is there a way to check the
history of the online documentation and revert those pages?

-Peter Mawhorter

On 11/28/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Christian Heimes added the comment:
>
> Are you able to provide a patch? Please use a snapshot or svn checkout
> of 2.5 for the patch. We have a new documentation system.
>
> --
> nosy: +tiran
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

__
Tracker <[EMAIL PROTECTED]>

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

[issue1509] Documentation lacking for the sqlite3 module.

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

> I thought that at one point those methods were documented

sqlite3 implements the DB-API:
http://www.python.org/dev/peps/pep-0249/
is it the documentation you had in mind?

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

[issue1509] Documentation lacking for the sqlite3 module.

[Peter Mawhorter]

Peter Mawhorter added the comment:

Yes actually... the fetch documentation there is a sufficient
explanation of the functions provided. If it could be added to
docs.python.org, that would be great.

There still remains the fact that the docstrings in the sqlite3 module
don't agree with their function names, but that's a very minor issue,
and wouldn't normally impact usability of the module.

-Peter Mawhorter

On 11/28/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
>
> Amaury Forgeot d'Arc added the comment:
>
> > I thought that at one point those methods were documented
>
> sqlite3 implements the DB-API:
> http://www.python.org/dev/peps/pep-0249/
> is it the documentation you had in mind?
>
> --
> nosy: +amaury.forgeotdarc
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

__
Tracker <[EMAIL PROTECTED]>

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

[issue1511] csv input converts \r\n to \n but csv output does not when a field has internal line breaks

[Skip Montanaro]

Changes by Skip Montanaro:


--
assignee:  -> skip.montanaro
nosy: +skip.montanaro

__
Tracker <[EMAIL PROTECTED]>

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

[issue1505] Changes to PyMethod_New breaks ctypes on Windows

[Christian Heimes]

Christian Heimes added the comment:

The removal of unbound methods made it hard to bind CFunctions. I
rewrote the code in r59215.

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

[issue1512] Removal of stale code in pyconfig.h

[Christian Heimes]

Changes by Christian Heimes:


--
assignee:  -> loewis
nosy: +loewis
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

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

[issue1512] Removal of stale code in pyconfig.h

[Joseph Armbruster]

New submission from Joseph Armbruster:

Question:  Is there any harm in removing this block from pyconfig.h?

#ifndef PY_LONG_LONG
#   define PY_LONG_LONG __int64
#   define PY_LLONG_MAX _I64_MAX
#   define PY_LLONG_MIN _I64_MIN
#   define PY_ULLONG_MAX _UI64_MAX
#endif

pyconfig.h contains this small snippet:

/* 64 bit ints are usually spelt __int64 unless compiler has overridden */
#define HAVE_LONG_LONG 1
#ifndef PY_LONG_LONG
#   define PY_LONG_LONG __int64
#   define PY_LLONG_MAX _I64_MAX
#   define PY_LLONG_MIN _I64_MIN
#   define PY_ULLONG_MAX _UI64_MAX
#endif


However, in pyport.h, I can see that PY_LONG_LONG may also be defined
here, except the tokens are slightly different:


#ifdef HAVE_LONG_LONG

#ifndef PY_LONG_LONG
#define PY_LONG_LONG long long

#if defined(LLONG_MAX)
/* If LLONG_MAX is defined in limits.h, use that. */
#define PY_LLONG_MIN LLONG_MIN
#define PY_LLONG_MAX LLONG_MAX
#define PY_ULLONG_MAX ULLONG_MAX
#elif defined(__LONG_LONG_MAX__)
/* Otherwise, if GCC has a builtin define, use that. */
#define PY_LLONG_MAX __LONG_LONG_MAX__
#define PY_LLONG_MIN (-PY_LLONG_MAX-1)
#define PY_ULLONG_MAX (__LONG_LONG_MAX__*2ULL + 1ULL)
#else
/* Otherwise, rely on two's complement. */
#define PY_ULLONG_MAX (~0ULL)
#define PY_LLONG_MAX  ((long long)(PY_ULLONG_MAX>>1))
#define PY_LLONG_MIN (-PY_LLONG_MAX-1)
#endif /* LLONG_MAX */
#endif
#endif /* HAVE_LONG_LONG */

--
components: Build
messages: 57913
nosy: JosephArmbruster, tiran
severity: minor
status: open
title: Removal of stale code in pyconfig.h
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

[issue1160] Medium size regexp crashes python

[mathieu Clabaut]

Changes by mathieu Clabaut:


--
nosy: +mathieu.clabaut

__
Tracker <[EMAIL PROTECTED]>

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

[issue1513] object.c do_compare comparison ordering error

[Joseph Armbruster]

New submission from Joseph Armbruster:

URL: http://svn.python.org/projects/python/branches/py3k
Rev: 59215

Session illustrating issue:

>>> a = None
[40667 refs]
>>> cmp(a,None)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: NoneType() < NoneType()
[40715 refs]

Resolution: It appears the equality comparison in do_compare should take
place first, otherwise a TypeError thwarts the desired comparison.

rt.bat Results (I can only test core, since I do not have the third
party libs here):

Failed tests before change:
  test_ctypes test_mailbox

Failed tests after change:
  test_copy test_ctypes test_mailbox

test_copy is failing because of this block:

def test_deepcopy_reflexive_dict(self):
x = {}
x['foo'] = x
y = copy.deepcopy(x)
self.assertRaises(TypeError, cmp, y, x)
self.assert_(y is not x)
self.assert_(y['foo'] is y)
self.assertEqual(len(y), 1)

A RuntimeError now occurs instead.

self.assertRaises(RuntimeError, cmp, y, x)

Additional Patch Note:

If this is a valid patch, please add a comment prior to the code change
that indicates the EQ test is first for a good reason.

--
components: Interpreter Core
files: noneEquality.patch
messages: 57914
nosy: JosephArmbruster, loewis, tiran
severity: normal
status: open
title: object.c do_compare comparison ordering error
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8818/noneEquality.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: object.c
===
--- object.c	(revision 59215)
+++ object.c	(working copy)
@@ -494,6 +494,11 @@
 	/* Now try three-way compare before giving up.  This is intentionally
 	   elaborate; if you have a it will raise TypeError if it detects two
 	   objects that aren't ordered with respect to each other. */
+	ok = PyObject_RichCompareBool(v, w, Py_EQ);
+	if (ok < 0)
+		return -1; /* Error */
+	if (ok)
+		return 0; /* Equal */
 	ok = PyObject_RichCompareBool(v, w, Py_LT);
 	if (ok < 0)
 		return -1; /* Error */
@@ -504,11 +509,6 @@
 		return -1; /* Error */
 	if (ok)
 		return 1; /* Greater than */
-	ok = PyObject_RichCompareBool(v, w, Py_EQ);
-	if (ok < 0)
-		return -1; /* Error */
-	if (ok)
-		return 0; /* Equal */
 
 	/* Give up */
 	PyErr_Format(PyExc_TypeError,
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1513] object.c do_compare comparison ordering error

[Christian Heimes]

Christian Heimes added the comment:

Guido, do we want cmp(None, None) to return a value or is the exception
expected?

--
assignee:  -> gvanrossum
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

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

[issue1513] object.c do_compare comparison ordering error

[Guido van Rossum]

Guido van Rossum added the comment:

This is not a bug.  There's not much point is supporting cmp(None, None)
when cmp(None, ) would still fail.  cmp() should only be
used when you know that the arguments belong to an orderable type.

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

[issue1513] object.c do_compare comparison ordering error

[Joseph Armbruster]

Joseph Armbruster added the comment:

I had looked at the behavior in 2.5 and did not know if this would still
be the case:

>>> cmp(None,'a')
-1
>>> cmp('a',None)
1
>>> cmp(None,None)
0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1506] func alloca inside ctypes lib needs #include on solaris

[Greg Couch]

Greg Couch added the comment:

A better solution would be to use the HAVE_ALLOCA and HAVE_ALLOCA_H
defines that fficonfig.h provides to decide whether or not to include
alloca.h.  And in callproc.c whether or not to provide a workaround
using malloc (I'm assuming non-gcc sparc compilers also support alloca
for sparc/ffi.c, but I don't know for sure).

--
nosy: +gregcouch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1513] object.c do_compare comparison ordering error

[Guido van Rossum]

Guido van Rossum added the comment:

All three of those are errors in 3.0.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1513] object.c do_compare comparison ordering error

[Georg Brandl]

Georg Brandl added the comment:

Well, the cmp() docs say that 
cmp(x, y) is "zero if ``x == y``", so at least the docs must be changed
to explain the new behavior (which I can't specify).

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

[issue1514] missing constants in socket module

[David Binger]

New submission from David Binger:

TCP_NODELAY and some constants are not present in the socket module.
I think maybe "#include " should appear somewhere, 
perhaps at the top of socketmodule.c?
(This is on OS X 10.5.1 with py3k revision 59215).

--
components: Library (Lib), Macintosh
messages: 57921
nosy: dbinger
severity: normal
status: open
title: missing constants in socket module
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

[issue1506] func alloca inside ctypes lib needs #include on solaris

[Greg Couch]

Greg Couch added the comment:

Turns out callproc.c forgot to include  after 
which conditionally includes alloca.h.  So it's a one-line fix.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1515] deepcopy doesn't copy instance methods

[Michael Van Biesbrouck]

New submission from Michael Van Biesbrouck:

Currently, using deepcopy on instance methods causes an exception to be
thrown.  This can be fixed by adding one line to copy.py:

d[types.MethodType] = _deepcopy_atomic

This will not make duplicate copies of mutable values referenced within
the instance method (such as its associated instance), but it will be
the same as the handling of other function types (which have the same
problem).

--
messages: 57923
nosy: mlvanbie
severity: normal
status: open
title: deepcopy doesn't copy instance methods
type: behavior
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

[issue1516] make _ctypes work with non-gcc compilers

[Greg Couch]

New submission from Greg Couch:

To get _ctypes to sucessfully compile with native UNIX compilers (i.e.,
not gcc), several modifications need to be made: (1) use the equivalent
of the Py_GCC_ATTRIBUTE macro for __attribute__ (in ffi.h), (2) include
  in callproc.c to conditionally include , and
(3) modify distutils to know something about assembly language files.

The attached patch is a starting point for the proper patch.  It fixes
bugs (1) and (2), but I was unable to figure out the last tweek to get
distutils to work with gcc and native compilers.

The problem with _ctypes comes from the use of gcc's libffi.  And libffi
 uses assembly language source files for the various supported platforms
and distutils blindly compiles the .S files.  Native UNIX compilers want
a .s suffix and if the files are renamed, distutils skips the file.  I
tried modifying distutils to compile .s files and give the '-x
assembler-with-cpp' flag to gcc so gcc would still work, but the right
tweek evaded me.  So I'm hoping someone can take this and turn it into
something better or make helpful suggestions (other than switching to gcc!).

--
files: _ctypes.diffs
messages: 57924
nosy: gregcouch
severity: normal
status: open
title: make _ctypes work with non-gcc compilers
versions: Python 2.6
Added file: http://bugs.python.org/file8819/_ctypes.diffs

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

[Adam Olsen]

New submission from Adam Olsen:

(thanks go to my partner in crime, jorendorff, for helping flesh this out.)

lookdict calls PyObject_RichCompareBool without using INCREF/DECREF on
the key passed.  It's possible for the comparison to delete the key from
the dict, causing its own argument to be deallocated.  This can lead to
bogus results or a crash.

A custom type with its own __eq__ method will implicitly INCREF the key
when passing it as an argument, which prevents incorrect behaviour from
manifesting.  There are a couple ways around this though, as shown in my
attachment.

--
components: Interpreter Core
files: dictbug.py
messages: 57925
nosy: rhamphoryncus
severity: normal
status: open
title: lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool
Added file: http://bugs.python.org/file8820/dictbug.py

__
Tracker <[EMAIL PROTECTED]>

__#!/usr/bin/env python

# This first approach causes dict to return the wrong value
# for the key.  The dict doesn't create its own reference
# to startkey, meaning that address may get reused.  We
# take advantage of that to swap in a new value without it
# noticing the key has changed.
class Foo(object):
  def __init__(self, value):
self.value = value
  def __hash__(self):
return hash(self.value)
  def __eq__(self, other):
# self gets packed into a tuple to get passed to us,
# which INCREFs it and prevents us from reusing the
# address.  To get around that we move the work into
# our return value's __nonzero__ method instead.
return BadBool(self.value, other.value)

class BadBool(object):
  def __init__(self, a, b):
self.a = a
self.b = b
  def __nonzero__(self):
global counter
if not counter:
  counter = 1
  # This is the bad part.  Conceivably, another thread
  # might do this without any malicious behaviour
  # involved.
  del d[d.keys()[0]]
  d[Foo(2**32+1)] = 'this is never the right answer'
return self.a == self.b

print "Test 1, using __eq__(a, b).__nonzero__()"
d = {}
counter = 0
d[Foo(2)] = 'this is an acceptable answer'
print d.get(Foo(2), 'so is this')
print '*'


# This second version uses tuple's tp_richcompare.  tuple
# assumes the caller has a valid reference, but Bar.__eq__
# purges that reference, causing the tuple to be
# deallocated.  Watch only exists to make sure tuple
# continues to use the memory, provoking a crash.
#
# Interestingly, Watch.__eq__ never gets called.
class Bar(object):
  def __hash__(self):
return 0
  def __eq__(self, other):
d.clear()
return True

class Watch(object):
  def __init__(self):
print "New Watch 0x%x" % id(self)
  def __del__(self):
print "Deleting Watch 0x%x" % id(self)
  def __hash__(self):
return 0
  def __eq__(self):
print "eq Watch", self, other
return True

print "Test 2, using tuple's tp_richcompare"
d = {}
d.clear()
d[(Bar(), Watch())] = 'hello'
print d[(Bar(), Watch())]
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1516] make _ctypes work with non-gcc compilers

[Martin v. Löwis]

Martin v. Löwis added the comment:

Can you please be specific what compilers and systems you are talking
about? I doubt your statements hold for *all* native UNIX compilers. In
particular, .s files should be compiled with as, not cc, on the UNIX
systems I'm familiar with, but that won't involve the C preprocessor.

--
assignee:  -> theller
nosy: +loewis, theller

__
Tracker <[EMAIL PROTECTED]>

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