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

Christian Heimes added the comment: I agree! Can you provide a patch please? -- assignee: - tiran nosy: +tiran priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1510 __

[issue1509] Documentation lacking for the sqlite3 module.

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] http://bugs.python.org/issue1509

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

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] http://bugs.python.org/issue1508

[issue1509] Documentation lacking for the sqlite3 module.

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

[issue1509] Documentation lacking for the sqlite3 module.

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

[issue1509] Documentation lacking for the sqlite3 module.

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

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

Changes by Skip Montanaro: -- assignee: - skip.montanaro nosy: +skip.montanaro __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1511 __ ___ Python-bugs-list mailing list

[issue1505] Changes to PyMethod_New breaks ctypes on Windows

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] http://bugs.python.org/issue1505

[issue1512] Removal of stale code in pyconfig.h

Changes by Christian Heimes: -- assignee: - loewis nosy: +loewis priority: - low __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1512 __ ___ Python-bugs-list mailing

[issue1512] Removal of stale code in pyconfig.h

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

[issue1160] Medium size regexp crashes python

Changes by mathieu Clabaut: -- nosy: +mathieu.clabaut __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1160 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1513] object.c do_compare comparison ordering error

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 stdin, line 1, in module TypeError: unorderable types: NoneType() NoneType()

[issue1513] object.c do_compare comparison ordering error

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] http://bugs.python.org/issue1513

[issue1513] object.c do_compare comparison ordering error

Guido van Rossum added the comment: This is not a bug. There's not much point is supporting cmp(None, None) when cmp(None, anything else) would still fail. cmp() should only be used when you know that the arguments belong to an orderable type. -- resolution: - rejected status: open -

[issue1513] object.c do_compare comparison ordering error

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] http://bugs.python.org/issue1513

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

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

[issue1513] object.c do_compare comparison ordering error

Guido van Rossum added the comment: All three of those are errors in 3.0. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1513 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1513] object.c do_compare comparison ordering error

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]

[issue1514] missing constants in socket module

New submission from David Binger: TCP_NODELAY and some constants are not present in the socket module. I think maybe #include netinet/tcp.h 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),

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

Greg Couch added the comment: Turns out callproc.c forgot to include ffi_common.h after ffi.h which conditionally includes alloca.h. So it's a one-line fix. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1506 __

[issue1515] deepcopy doesn't copy instance methods

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

[issue1516] make _ctypes work with non-gcc compilers

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 ffi_common.h in callproc.c to conditionally

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

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

[issue1516] make _ctypes work with non-gcc compilers

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