[ python-Bugs-1487389 ] datetime.time and datetime.timedelta
Bugs item #1487389, was opened at 2006-05-12 13:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.time and datetime.timedelta Initial Comment: print datetime.time(hour=0)+datetime.timedelta(hours=1) ...gives... TypeError: unsupported operand type(s) for +: 'datetime.time' and 'datetime.timedelta' Which is a bit frustrating :-/ Does it really need to be this way? Chris -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1477968 ] Drop py.ico and pyc.ico
Feature Requests item #1477968, was opened at 2006-04-27 22:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1477968&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Drop py.ico and pyc.ico Initial Comment: These files should be dropped from the Windows distribution, as they duplication python_icon.exe, and confuse tab completion. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-05-12 15:57 Message: Logged In: YES user_id=21627 It turns out that it isn't possible to refer to the location of the Icon table files from the Registry table, so that cannot be done. However, to improve tab completion, the icon files have been moved into the DLLs dir in r45975. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1477968&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1487420 ] can't pickle slice objects
Bugs item #1487420, was opened at 2006-05-12 16:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487420&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: can't pickle slice objects Initial Comment: for some reason, slices are not-picklable. i guess someone just forgot to add support for those >>> import pickle >>> pickle.dumps(slice(1,2,3)) Traceback (most recent call last): File "", line 1, in ? File "D:\Python24\Lib\pickle.py", line 1386, in dumps Pickler(file, protocol, bin).dump(obj) File "D:\Python24\Lib\pickle.py", line 231, in dump self.save(obj) File "D:\Python24\Lib\pickle.py", line 313, in save rv = reduce(self.proto) File "D:\Python24\Lib\copy_reg.py", line 69, in _reduce_ex raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle slice objects >>> -tomer -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487420&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1431582 ] long path support in win32 part of os.listdir(posixmodule.c)
Bugs item #1431582, was opened at 2006-02-14 16:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Sergey Dorofeev (fidoman) Assigned to: Martin v. Löwis (loewis) Summary: long path support in win32 part of os.listdir(posixmodule.c) Initial Comment: When passing path to os.listdir that is longer then MAX_PATH (what is supported in Windows API, http://msdn.microsoft.com/library/default.asp? url=/library/en-us/fileio/fs/naming_a_file.asp) the path is truncated at position MAX_PATH=260 and appended with "/*.*", so underlying Windows API function FindFirstFileW gets garbage on input: original path truncated, and symbol "/" is added, which may not be used as path separator in long path. I think posix_listdir should or raise error when getting extra long string, or pass it unchanged to underlying API. Affected code is in Modules\posixmodule.c, lines 1470- 1478 (Python 2.4.2). I think there is enough to change base when calculating size of allocated memory and copied block from fixed value of MAX_PATH to length of passed to function string. And use os.sep instead of "/", of course. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-05-12 15:58 Message: Logged In: YES user_id=21627 This has been fixed in r45973. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1485576 ] Backwards compatibility support for Py_ssize_t
Feature Requests item #1485576, was opened at 2006-05-10 15:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: Backwards compatibility support for Py_ssize_t Initial Comment: PEP353 recommends to add the following code snippet to extension modules to ensure compatibility with pre-2.5 interpreters: #if PY_VERSION_HEX < 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN #endif This is insufficient, because type definitions that use Py_ssize_t must also be added. Here is what works for me, though they may be more definitions to be included: #if PY_VERSION_HEX < 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN typedef Py_ssize_t (*lenfunc)(PyObject *); typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t); typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, Py_ssize_t); typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *); typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, PyObject *); typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **); typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **); typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *); typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **); #endif However, the main problem is elsewhere. Extension modules may well need to use Py_ssize_t in their own data types, and may furthermore with to make these data types available to yet other extension modules. In practice, this requires the inclusion of a code block such as the one shown above inside header files. However, this requires a mechanism for avoiding redefinitions, which at the moment does not seem to exist. My request is to add such a mechanism to Python 2.5 and recommend its consistent use in an update of PEP353. Concretely, I propose that Python 2.5 should define a macro PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion of the code snippet #ifndef PY_HAS_PY_SSIZE_T #define PY_HAS_PY_SSIZE_T typedef int Py_ssize_t; /* add all the other definitions here */ #endif that contains an exhaustive set of definitions that depend on Py_ssize_t. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-05-12 16:06 Message: Logged In: YES user_id=21627 Please re-read the section immediately following the #ifdef code in PEP 353. It explains how you should avoid these other typedefs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1417699 ] float/atof have become locale aware
Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Nobody/Anonymous (nobody)
Summary: float/atof have become locale aware
Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:
Python 2.4.2 (#1, Nov 29 2005, 16:07:55)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5
This doesn't match what's specified in pep 331:
- float() and str() stay locale-unaware.
It also doesn't match the documentation for atof:
Convert a string to a floating point number.
The string must have the standard syntax for a
floating point literal in Python, optionally
preceded by a sign ("+" or "-"). Note that this
behaves identical to the built-in function float()
when passed a string.
The documentation for float() doesn't state which
format is accepted by float(), though.
The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:
This function behaves like the standard strtod()
function does in the C locale.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-05-12 16:14
Message:
Logged In: YES
user_id=21627
Unassigning myself - I don't plan to work on this anytime soon.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 20:00
Message:
Logged In: YES
user_id=849994
I grepped around and found PyOS_ascii_strtod in the
following places:
* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string
In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.
--
Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 11:47
Message:
Logged In: YES
user_id=908
My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?
I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python. But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from the original author of the code, Alexander
Larsson.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-05-04 06:42
Message:
Logged In: YES
user_id=21627
It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version.
I'd like Gustavo Carneiro to comment.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19
Message:
Logged In: YES
user_id=1188172
Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1485576 ] Backwards compatibility support for Py_ssize_t
Feature Requests item #1485576, was opened at 2006-05-10 13:28 Message generated for change (Comment added) made by hinsen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: Backwards compatibility support for Py_ssize_t Initial Comment: PEP353 recommends to add the following code snippet to extension modules to ensure compatibility with pre-2.5 interpreters: #if PY_VERSION_HEX < 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN #endif This is insufficient, because type definitions that use Py_ssize_t must also be added. Here is what works for me, though they may be more definitions to be included: #if PY_VERSION_HEX < 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN typedef Py_ssize_t (*lenfunc)(PyObject *); typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t); typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, Py_ssize_t); typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *); typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, PyObject *); typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **); typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **); typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *); typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **); #endif However, the main problem is elsewhere. Extension modules may well need to use Py_ssize_t in their own data types, and may furthermore with to make these data types available to yet other extension modules. In practice, this requires the inclusion of a code block such as the one shown above inside header files. However, this requires a mechanism for avoiding redefinitions, which at the moment does not seem to exist. My request is to add such a mechanism to Python 2.5 and recommend its consistent use in an update of PEP353. Concretely, I propose that Python 2.5 should define a macro PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion of the code snippet #ifndef PY_HAS_PY_SSIZE_T #define PY_HAS_PY_SSIZE_T typedef int Py_ssize_t; /* add all the other definitions here */ #endif that contains an exhaustive set of definitions that depend on Py_ssize_t. -- >Comment By: Konrad Hinsen (hinsen) Date: 2006-05-12 14:18 Message: Logged In: YES user_id=11850 I have read that section, but I am not yet convinced that I can avoid those casts with all common C compilers - and since I cannot try them all, I'd rather play safe and keep the casts. If they were never necessary, why were those typedefs introduced at all? Anyway, it is not the additional typedefs that are the essence of my feature request. The main issue is that if multiple header files introduce Py_ssize_t, the compiler will stop with an error message. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-12 14:06 Message: Logged In: YES user_id=21627 Please re-read the section immediately following the #ifdef code in PEP 353. It explains how you should avoid these other typedefs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1485576 ] Backwards compatibility support for Py_ssize_t
Feature Requests item #1485576, was opened at 2006-05-10 13:28
Message generated for change (Comment added) made by hinsen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t
Initial Comment:
PEP353 recommends to add the following code snippet to extension
modules to ensure compatibility with pre-2.5 interpreters:
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif
This is insufficient, because type definitions that use Py_ssize_t must
also be added. Here is what works for me, though they may be more
definitions to be included:
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t,
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t,
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif
However, the main problem is elsewhere. Extension modules may well
need to use Py_ssize_t in their own data types, and may furthermore
with to make these data types available to yet other extension
modules. In practice, this requires the inclusion of a code block such
as the one shown above inside header files. However, this requires a
mechanism for avoiding redefinitions, which at the moment does not
seem to exist. My request is to add such a mechanism to Python 2.5
and recommend its consistent use in an update of PEP353.
Concretely, I propose that Python 2.5 should define a macro
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion
of the code snippet
#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;
/* add all the other definitions here */
#endif
that contains an exhaustive set of definitions that depend on
Py_ssize_t.
--
>Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:26
Message:
Logged In: YES
user_id=11850
Here is an illustration of my problem. Given the following three files:
-- foo.h -
#include
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#endif
typedef struct {
Py_ssize_t index;
} foo;
-- bar.h -
#include
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#endif
typedef struct {
Py_ssize_t index;
} bar;
-- foobar.c --
#include "foo.h"
#include "bar.h"
foo a;
bar b;
int main(int argc, char **argv) {
return 0;
}
--
I get from gcc:
gcc foobar.c
In file included from foobar.c:1:
foo.h:1:20: error: Python.h: No such file or directory
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here
I see no solution to this problem that would work in the most general case in
which all three files are part of different packages written by different
authors, i.e. in the absence of a coordination.
--
Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:18
Message:
Logged In: YES
user_id=11850
I have read that section, but I am not yet convinced that I can avoid those
casts with all common C compilers - and since I cannot try them all, I'd rather
play safe and keep the casts. If they were never necessary, why were those
typedefs introduced at all?
Anyway, it is not the additional typedefs that are the essence of my feature
request. The main issue is that if multiple header files introduce Py_ssize_t,
the compiler will stop with an error message.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-05-12 14:06
Message:
Logged In: YES
user_id=21627
Please re-read the section immediately following the #ifdef
code in PEP 353. It explains how you should avoid these
other typedefs.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&g
[ python-Feature Requests-1485576 ] Backwards compatibility support for Py_ssize_t
Feature Requests item #1485576, was opened at 2006-05-10 13:28
Message generated for change (Comment added) made by hinsen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Backwards compatibility support for Py_ssize_t
Initial Comment:
PEP353 recommends to add the following code snippet to extension
modules to ensure compatibility with pre-2.5 interpreters:
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif
This is insufficient, because type definitions that use Py_ssize_t must
also be added. Here is what works for me, though they may be more
definitions to be included:
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
typedef Py_ssize_t (*lenfunc)(PyObject *);
typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t);
typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t,
Py_ssize_t);
typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *);
typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t,
PyObject *);
typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **);
typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *);
typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **);
#endif
However, the main problem is elsewhere. Extension modules may well
need to use Py_ssize_t in their own data types, and may furthermore
with to make these data types available to yet other extension
modules. In practice, this requires the inclusion of a code block such
as the one shown above inside header files. However, this requires a
mechanism for avoiding redefinitions, which at the moment does not
seem to exist. My request is to add such a mechanism to Python 2.5
and recommend its consistent use in an update of PEP353.
Concretely, I propose that Python 2.5 should define a macro
PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion
of the code snippet
#ifndef PY_HAS_PY_SSIZE_T
#define PY_HAS_PY_SSIZE_T
typedef int Py_ssize_t;
/* add all the other definitions here */
#endif
that contains an exhaustive set of definitions that depend on
Py_ssize_t.
--
>Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:34
Message:
Logged In: YES
user_id=11850
Oops, I forgot the -I option, but that doesn't really make a difference.
For Python 2.5:
gcc -I /usr/local/include/python2.5 foobar.c
--> no error message
For Python 2.4:
gcc -I /Library/Frameworks/Python.framework/Versions/2.4/include/
python2.4 foobar.c
In file included from /Library/Frameworks/Python.framework/Versions/2.4/
include/python2.4/Python.h:55,
from foo.h:1,
from foobar.c:1:
/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/
pyport.h:396: warning: 'struct winsize' declared inside parameter list
/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/
pyport.h:397: warning: 'struct winsize' declared inside parameter list
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here
--
Comment By: Konrad Hinsen (hinsen)
Date: 2006-05-12 14:26
Message:
Logged In: YES
user_id=11850
Here is an illustration of my problem. Given the following three files:
-- foo.h -
#include
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#endif
typedef struct {
Py_ssize_t index;
} foo;
-- bar.h -
#include
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#endif
typedef struct {
Py_ssize_t index;
} bar;
-- foobar.c --
#include "foo.h"
#include "bar.h"
foo a;
bar b;
int main(int argc, char **argv) {
return 0;
}
--
I get from gcc:
gcc foobar.c
In file included from foobar.c:1:
foo.h:1:20: error: Python.h: No such file or directory
In file included from foobar.c:2:
bar.h:4: error: redefinition of typedef 'Py_ssize_t'
foo.h:4: error: previous declaration of 'Py_ssize_t' was here
I see no solution to this problem that would work in the most general case in
which all three files are part of different packages written by different
authors, i.e. in the absence of a coordination.
--
Comment By: K
[ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Bugs item #1487481, was opened at 2006-05-12 17:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Göran Uddeborg (goeran) Assigned to: Martin v. Löwis (loewis) Summary: Could BIND_FIRST be removed on HP-UX? Initial Comment: I'm trying to build Python 2.4.3 on HP-UX 11. I need tkinter, so I have first built Tcl and Tk 8.4.13. During the build, the python interpreter crashes. When running the setup.py script, just after making the _tkinter.sl module, it crashes with a memory fault. I've tried to investigate this, and it seems that malloc and friends gets confused by the dynamic loading. I've filed a support request with HP about this. One observation I made is that this malloc bug seems to be connected with the use of BIND_FIRST in dynload_hpux.c. If I just remove this flag (in two places) it appears as if Python works normally. I'm hesitant if this is a good idea. BIND_FIRST is there as an explicit, non-default, flag. Somebody must have choosen to do so for some reason. What was that reason? And is it still valid? If not, maybe the flag could be removed, and this problem in HP-UX be avoided? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1487481 ] Could BIND_FIRST be removed on HP-UX?
Bugs item #1487481, was opened at 2006-05-12 17:32 Message generated for change (Settings changed) made by goeran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Göran Uddeborg (goeran) Assigned to: Martin v. Löwis (loewis) Summary: Could BIND_FIRST be removed on HP-UX? Initial Comment: I'm trying to build Python 2.4.3 on HP-UX 11. I need tkinter, so I have first built Tcl and Tk 8.4.13. During the build, the python interpreter crashes. When running the setup.py script, just after making the _tkinter.sl module, it crashes with a memory fault. I've tried to investigate this, and it seems that malloc and friends gets confused by the dynamic loading. I've filed a support request with HP about this. One observation I made is that this malloc bug seems to be connected with the use of BIND_FIRST in dynload_hpux.c. If I just remove this flag (in two places) it appears as if Python works normally. I'm hesitant if this is a good idea. BIND_FIRST is there as an explicit, non-default, flag. Somebody must have choosen to do so for some reason. What was that reason? And is it still valid? If not, maybe the flag could be removed, and this problem in HP-UX be avoided? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1487481&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1487389 ] datetime.time and datetime.timedelta
Feature Requests item #1487389, was opened at 2006-05-12 09:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1487389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.time and datetime.timedelta Initial Comment: print datetime.time(hour=0)+datetime.timedelta(hours=1) ...gives... TypeError: unsupported operand type(s) for +: 'datetime.time' and 'datetime.timedelta' Which is a bit frustrating :-/ Does it really need to be this way? Chris -- >Comment By: Tim Peters (tim_one) Date: 2006-05-12 12:15 Message: Logged In: YES user_id=31435 Since the lack of arithmetic on `time` objects is both intended and documented, this isn't "a bug". I moved this to the Feature Requests tracker. The problem with arithmetic on time objects is that it's not obvious what to do in case of overflow or underflow: wrap around or raise OverflowError? Either way violates _some_ reasonable expectation. Embed your time in a `datetime` object and then you can decide what you want to do. For example, if you want to wrap around, >>> print (datetime.combine(date.today(), time(hour=0)) - timedelta(hours=1)).time() 23:00:00 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1487389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1485576 ] Backwards compatibility support for Py_ssize_t
Feature Requests item #1485576, was opened at 2006-05-10 15:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1485576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Nobody/Anonymous (nobody) Summary: Backwards compatibility support for Py_ssize_t Initial Comment: PEP353 recommends to add the following code snippet to extension modules to ensure compatibility with pre-2.5 interpreters: #if PY_VERSION_HEX < 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN #endif This is insufficient, because type definitions that use Py_ssize_t must also be added. Here is what works for me, though they may be more definitions to be included: #if PY_VERSION_HEX < 0x0205 typedef int Py_ssize_t; #define PY_SSIZE_T_MAX INT_MAX #define PY_SSIZE_T_MIN INT_MIN typedef Py_ssize_t (*lenfunc)(PyObject *); typedef PyObject *(*ssizeargfunc)(PyObject *, Py_ssize_t); typedef PyObject *(*ssizessizeargfunc)(PyObject *, Py_ssize_t, Py_ssize_t); typedef int(*ssizeobjargproc)(PyObject *, Py_ssize_t, PyObject *); typedef int(*ssizessizeobjargproc)(PyObject *, Py_ssize_t, Py_ssize_t, PyObject *); typedef Py_ssize_t (*readbufferproc)(PyObject *, Py_ssize_t, void **); typedef Py_ssize_t (*writebufferproc)(PyObject *, Py_ssize_t, void **); typedef Py_ssize_t (*segcountproc)(PyObject *, Py_ssize_t *); typedef Py_ssize_t (*charbufferproc)(PyObject *, Py_ssize_t, char **); #endif However, the main problem is elsewhere. Extension modules may well need to use Py_ssize_t in their own data types, and may furthermore with to make these data types available to yet other extension modules. In practice, this requires the inclusion of a code block such as the one shown above inside header files. However, this requires a mechanism for avoiding redefinitions, which at the moment does not seem to exist. My request is to add such a mechanism to Python 2.5 and recommend its consistent use in an update of PEP353. Concretely, I propose that Python 2.5 should define a macro PY_HAS_PY_SSIZE_T, and that PEP353 should recommend the inclusion of the code snippet #ifndef PY_HAS_PY_SSIZE_T #define PY_HAS_PY_SSIZE_T typedef int Py_ssize_t; /* add all the other definitions here */ #endif that contains an exhaustive set of definitions that depend on Py_ssize_t. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-05-12 22:32 Message: Logged In: YES user_id=21627 I understand your request, and I sympathize with it (although I would call the macro Py_ssize_t_defined). However, I find it equally important that the other issue gets understood, as well. The macros are not necessary for portable code, and they never were. They were introduced for convenience only, so that you can have the actual type name for the self parameter (e.g. FooObject* instead of PyObject*). If the signatures are corrected to have PyObject* as their first parameter, the casts *should* become unnecessary. If they are then still required, that indicates a serious programming error. The evilness of these casts comes from the fact that they can silence warnings that would point to severe type errors if the cast wouldn't silence them. For example, if the parameter order or the number is wrong for one of these functions, the compiler won't notice because of the cast. The cast is only there to convert the first parameter (self), yet it can manage to convert any other parameter, as well. So getting these function pointers type correct not only increases portabiltiy in the presence of Py_ssize_t, but also improves correctness and readability of the code. -- Comment By: Konrad Hinsen (hinsen) Date: 2006-05-12 16:34 Message: Logged In: YES user_id=11850 Oops, I forgot the -I option, but that doesn't really make a difference. For Python 2.5: gcc -I /usr/local/include/python2.5 foobar.c --> no error message For Python 2.4: gcc -I /Library/Frameworks/Python.framework/Versions/2.4/include/ python2.4 foobar.c In file included from /Library/Frameworks/Python.framework/Versions/2.4/ include/python2.4/Python.h:55, from foo.h:1, from foobar.c:1: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:396: warning: 'struct winsize' declared inside parameter list /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ pyport.h:397: warning: 'struct winsize' declared inside parameter list In file included from foobar.c:2: bar.h:4: error: redefinition of typedef 'Py_ssiz
[ python-Bugs-1467619 ] Header.decode_header eats up spaces
Bugs item #1467619, was opened at 2006-04-10 12:33
Message generated for change (Comment added) made by alexanderweb
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mathieu Goutelle (mgoutell)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Header.decode_header eats up spaces
Initial Comment:
The Header.decode_header function eats up spaces in
non-encoded part of a header.
See the following source:
# -*- coding: iso-8859-1 -*-
from email.Header import Header, decode_header
h = Header('Essai ', None)
h.append('éè', 'iso-8859-1')
print h
print decode_header(h)
This prints:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test', None), ('\xe9\xe8', 'iso-8859-1')]
This should print:
Essai =?iso-8859-1?q?=E9=E8?=
[('Test ', None), ('\xe9\xe8', 'iso-8859-1')]
^ This space disappears
This appears in Python 2.3 but the source code of the
function didn't change in 2.4 so the same problem
should still exist. Bug "[ 1372770 ] email.Header
should preserve original FWS" may be linked to that one
although I'm not sure this is exactly the same.
This patch (not extensively tested though) seems to
solve this problem:
--- /usr/lib/python2.3/email/Header.py 2005-09-05
00:20:03.0 +0200
+++ Header.py 2006-04-10 12:27:27.0 +0200
@@ -90,7 +90,7 @@
continue
parts = ecre.split(line)
while parts:
-unenc = parts.pop(0).strip()
+unenc = parts.pop(0).rstrip()
if unenc:
# Should we continue a long line?
if decoded and decoded[-1][1] is None:
--
Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-05-13 00:28
Message:
Logged In: YES
user_id=254738
I can confirm this bug and have been bitten by it as well.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
