[ python-Bugs-1274069 ] bz2module.c compiler warning
Bugs item #1274069, was opened at 2005-08-26 16:25
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1274069&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: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: bz2module.c compiler warning
Initial Comment:
On Python HEAD, there's a new warning while
compiling bz2module.c (MSVC 7.1):
python\Modules\bz2module.c(1095) : warning
C4244: '=' :
conversion from 'Py_off_t' to 'int', possible loss of data
Looks like a legitimate complaint to me. The line in
question:
readsize = offset-bytesread;
Those have types int, Py_off_t, and int respectively. Is
it true that offset-bytesread _necessarily_ fits in an int?
If so, a comment should explain why, and a cast should
be added to squash the warning. Or If the difference
doesn't necessarily fit in an int, the code is wrong.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-03 09:50
Message:
Logged In: YES
user_id=1188172
Applied the newest patch. The warnings should be gone now.
bz2module.c r1.26, 1.23.2.3.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-27 19:52
Message:
Logged In: YES
user_id=80475
The new patch works fine on this end.
--
Comment By: Tim Peters (tim_one)
Date: 2005-08-27 19:13
Message:
Logged In: YES
user_id=31435
Raymond, did you read the error output and verify that you're
not suffering from the sample3.bz2 problem it explains?
"""
All six of the fc's should find no differences.
If fc finds an error on sample3.bz2, this could be
because WinZip's 'TAR file smart CR/LF conversion'
is too clever for its own good. Disable this option.
The correct size for sample3.ref is 120,244. If it
is 150,251, WinZip has messed it up.
"""
Since the error you saw did come from sample3.bz2, that
would be a good thing to check ;-)
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-27 19:02
Message:
Logged In: YES
user_id=1188172
Tackled the two warnings (tell() should return a long int if
64 bits) with new patch.
I can't see the error in your output.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-08-27 18:31
Message:
Logged In: YES
user_id=80475
The latest patch gives me the following:
Configuration: bz2 - Win32
Debug
Compiling...
bz2module.c
C:\py25\Modules\bz2module.c(1143) : warning C4244:
'function' : conversion from '__int64 ' to 'long ', possible
loss of data
C:\py25\Modules\bz2module.c(1143) : warning C4761: integral
size mismatch in argument; conversion supplied
lib /out:libbz2.lib blocksort.obj huffman.obj
crctable.objrandtable.obj compress.obj
decompress.obj bzlib.obj
Microsoft (R) Library Manager Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o bzip2
bzip2.c libbz2.lib setargv.obj
bzip2.c
cl -DWIN32 -MD -Ox -D_FILE_OFFSET_BITS=64 -nologo -o
bzip2recover bzip2recover.c
bzip2recover.c
type words1
Doing 6 tests (3 compress, 3 uncompress) ...
If there's a problem, things might stop at this point.
.\bzip2 -1 < sample1.ref > sample1.rb2
.\bzip2 -2 < sample2.ref > sample2.rb2
.\bzip2 -3 < sample3.ref > sample3.rb2
.\bzip2 -d < sample1.bz2 > sample1.tst
.\bzip2 -d < sample2.bz2 > sample2.tst
.\bzip2 -ds < sample3.bz2 > sample3.tst
All six of the fc's should find no differences.
If fc finds an error on sample3.bz2, this could be
because WinZip's 'TAR file smart CR/LF conversion'
is too clever for its own good. Disable this option.
The correct size for sample3.ref is 120,244. If it
is 150,251, WinZip has messed it up.
fc sample1.bz2 sample1.rb2
Comparing files sample1.bz2 and sample1.rb2
FC: no differences encountered
fc sample2.bz2 sample2.rb2
Comparing files sample2.bz2 and sample2.rb2
FC: no differences encountered
fc sample3.bz2 sample3.rb2
Comparing files sample3.bz2 and sample3.rb2
** sample3.bz2
BZh31AY&SYºÍ3É
·ïuU©´`Û2 [EMAIL PROTECTED]
¾àý£^1 ˯ðú£¦Çº)ëô·alèDh3H¯Ú\mIL´hiiÈB°Ró
** sample3.rb2
BZh31AY&SYîÜ>
ò# óAJ3ù²ªÔ©zÉ êè7UÎ{ýÍC2
l
}ÛÀ
**
fc sample1.tst sample1.ref
Comparing files sample1.tst and sample1.ref
FC: no differences encountered
fc sample2.tst sample2.ref
Comparing files sample2.tst and sample2.ref
FC: no
[ python-Bugs-1235646 ] codecs.StreamRecoder.next doesn't encode
Bugs item #1235646, was opened at 2005-07-10 18:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&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: Unicode Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sebastian Wangnick (wangnick) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.StreamRecoder.next doesn't encode Initial Comment: Codecs.StreamRecode.next does't encode the data it gets from self.reader.next. This breaks the "for line in codecs.EncodedFile(...)" idiom. -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-03 12:31 Message: Logged In: YES user_id=38388 If you think there's a use case, yes. Enjoy your vacation ! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-09-02 20:33 Message: Logged In: YES user_id=89016 OK, now I'm beginning to understand the docstring. Nevertheless I think having a class that uses stateful codecs at both ends would be useful. If you want, I can give this a try (after I'm back from vactation in four weeks). Closing the report as fixed. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-09-01 20:28 Message: Logged In: YES user_id=38388 Thanks, Walter. StreamRecorder is not broken: it works as advertised (see the .__init__() doc-string and interface) and yes, this means that only stateless encodings can be used, such as e.g. UTF-16-LE, simply because the encode and decode functions are defined as being stateless. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-09-01 14:22 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.48/1.35.2.10 I'll try to add tests for StreamRecoder tomorrow. StreamRecoder is broken in its current form, as it uses the stateless codec for the frontend encoding. Recoding from e.g. latin-1 to utf-16 will return a BOM for every call to read() which is clearly wrong. What gets read from the backend stream should be pushed through a *stateful* encoder. BTW, a feed style API would help here ;) -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-08-31 22:58 Message: Logged In: YES user_id=38388 Looks good, Walter. Please check it in. Thanks. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-08-31 18:11 Message: Logged In: YES user_id=89016 Here's a simple patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281291 ] Erroneous \url command in python.sty
Bugs item #1281291, was opened at 2005-09-03 17:18 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=1281291&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rory Yorke (ryorke) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous \url command in python.sty Initial Comment: The \url and \ulink commands in texinputs/python.sty produce erroneous PDF files. This can be fairly easily tested using GhostScript (see the attached log file for an example). The current Python 2.4.1 PDF docs (as downloadable from www.python.org) have this error. Although the error does not prevent correct rendering in viewers such as gv, xpdf or acroread, the link is absent. The attached patch partially addresses this, by changing the arguments to the \pdfstart command used. The changes are taken straight from texmf/tex/latex/hyperref/hpdftex.def; that file has the following version header: %% File: hyperref.dtx Copyright 1995-2001 Sebastian Rahtz, %% RCS: $Id: hyperref.dtx 6.71 2000/10/04 rahtz Exp rahtz $ I don't pretend to understand the TeX code, but it does fix some of the problem. Some URLs, like http://sourceforge.net/bugs/?group_id=5470, are not linked to correctly. That particular URL becomes http://sourceforge.net/bugs/[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@skip%20id=5470 -- I guess that has something to do with the underscore. The diff was generated relative to Python CVS head of 3 Sept 2005; the python.sty file had version 1.113. The python executable used was 2.4.1, not CVS. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281291&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-1281053 ] non-sequence map() arguments for optimization
Feature Requests item #1281053, was opened at 2005-09-02 18:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&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: Closed Resolution: Invalid Priority: 5 Submitted By: Ecnassianer of the Green Storm (ecnassianer) Assigned to: Nobody/Anonymous (nobody) Summary: non-sequence map() arguments for optimization Initial Comment: I'm trying to optimize some code thats similiar to this: anObject = someConstructor() # This isn't a sequence myList = myListMaker() # This IS a sequence for items in myList: function(items, anObject) I'd like to be able to do this: map(function, myList, anObject) But the map function takes two lists, so I have to do somethign like this: list2 = [] for x in range(len(myList)): list2.append(anObject) map(function, myList, list2) But intializing list2 kind of defeats the purpose of optimization. I was looking for some way to convince anObject that it was really a list containing a lots of entries of itself, but couldn't find anything in the API. What I'd love to have is a version of the map function which takes a function, a sequence, and an object as arguments and calls the function with the first argument as an element in the sequence, and the second element as the object for as many times as their are items in the sequence. (Note: Currently the API says if you pass sequences of unequal lenghths to map, it uses None to fill up the rest of the calls) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 11:26 Message: Logged In: YES user_id=80475 from itertools import imap, repeat list(imap(function, myList, repeat(anObject))) -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 01:43 Message: Logged In: YES user_id=1188172 Use a list comprehension: [function(item, anObject) for item in myList] or, if you must use map, map(lambda item: function(item, anObject), myList) And please direct such questions to comp.lang.python in the future. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&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-1281053 ] non-sequence map() arguments for optimization
Feature Requests item #1281053, was opened at 2005-09-02 18:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&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: Closed Resolution: Invalid Priority: 5 Submitted By: Ecnassianer of the Green Storm (ecnassianer) Assigned to: Nobody/Anonymous (nobody) Summary: non-sequence map() arguments for optimization Initial Comment: I'm trying to optimize some code thats similiar to this: anObject = someConstructor() # This isn't a sequence myList = myListMaker() # This IS a sequence for items in myList: function(items, anObject) I'd like to be able to do this: map(function, myList, anObject) But the map function takes two lists, so I have to do somethign like this: list2 = [] for x in range(len(myList)): list2.append(anObject) map(function, myList, list2) But intializing list2 kind of defeats the purpose of optimization. I was looking for some way to convince anObject that it was really a list containing a lots of entries of itself, but couldn't find anything in the API. What I'd love to have is a version of the map function which takes a function, a sequence, and an object as arguments and calls the function with the first argument as an element in the sequence, and the second element as the object for as many times as their are items in the sequence. (Note: Currently the API says if you pass sequences of unequal lenghths to map, it uses None to fill up the rest of the calls) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 11:36 Message: Logged In: YES user_id=80475 Or just: map(function, myList, repeat(anObject, len(myList))) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-03 11:26 Message: Logged In: YES user_id=80475 from itertools import imap, repeat list(imap(function, myList, repeat(anObject))) -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-03 01:43 Message: Logged In: YES user_id=1188172 Use a list comprehension: [function(item, anObject) for item in myList] or, if you must use map, map(lambda item: function(item, anObject), myList) And please direct such questions to comp.lang.python in the future. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1281053&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1275719 ] discrepancy between str.__cmp__ and unicode.__cmp__
Bugs item #1275719, was opened at 2005-08-29 09:54
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Antoine Pitrou (pitrou)
Assigned to: Nobody/Anonymous (nobody)
Summary: discrepancy between str.__cmp__ and unicode.__cmp__
Initial Comment:
I had the surprise, while wanted to use str.__cmp__ as
the cmp argument to list.sort(), that it seems buggy
compared to unicode.__cmp__, and that these methods
seem implemented quite differently (they have a
different type):
$ python
Python 2.4.1 (#2, Aug 25 2005, 18:20:57)
[GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release
2006.0)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> unicode.__cmp__
>>> str.__cmp__
>>> u'a'.__cmp__(u'b')
-1
>>> 'a'.__cmp__('b')
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: 'str' object has no attribute '__cmp__'
>>> unicode.__cmp__(u'a', u'b')
-1
>>> str.__cmp__('a', 'b')
Traceback (most recent call last):
File "", line 1, in ?
TypeError: expected 1 arguments, got 2
Am I missing something ?
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-03 12:01
Message:
Logged In: YES
user_id=80475
In the absence of a defined __cmp__ method for string
objects, str.__cmp__ inherits type.__cmp__ which is used for
comparing types. That is why you can sort a list of types:
>>> sorted([int, complex, float, str, dict, list, tuple])
[, , , , , , ]
--
Comment By: Antoine Pitrou (pitrou)
Date: 2005-08-29 10:35
Message:
Logged In: YES
user_id=133955
You are right, I also forgot there is a builtin cmp()
function that works like expected. Still str.__cmp__'s
behaviour is a bit puzzling to me...
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-29 10:16
Message:
Logged In: YES
user_id=1188172
String comparison is done with rich compare methods, namely
__lt__, __le__, __gt__, __ge__ and __eq__, __ne__.
Why str.__cmp__ exists and 'a'.__cmp__ does not, I cannot say.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1275719&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1066546 ] test_pwd fails on 64bit system (Opteron)
Bugs item #1066546, was opened at 2004-11-15 10:34
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1066546&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: Miki Tebeka (tebeka)
>Assigned to: Martin v. Löwis (loewis)
Summary: test_pwd fails on 64bit system (Opteron)
Initial Comment:
test test_pwd failed -- Traceback (most recent call last):
File "/tmp/miki/Python-2.4b2/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
$ cat /proc/version
Linux version 2.4.21-20.ELsmp
([EMAIL PROTECTED]) (gcc version 3.2.3
20030502 (Red Hat Linux 3.2.3-42)) #1 SMP Wed Aug 18
20:34:58 EDT 2004
Processor is AMD Opteron 2.4MHz
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-03 20:17
Message:
Logged In: YES
user_id=1188172
Is the patch safe to apply? I think so, I haven't seen a
negative uid/gid yet.
--
Comment By: Clark Mobarry (cmobarry)
Date: 2005-09-01 14:57
Message:
Logged In: YES
user_id=1035073
The suggested patch by heffler worked brilliantly for my 64
bit environment. Thanks. My bug submission was on
2005-08-03 14:40.
--
Comment By: Marvin Heffler (heffler)
Date: 2005-08-11 20:19
Message:
Logged In: YES
user_id=298758
I think I figued out the problem with python handling uids and
gids greater than 2147483647 when using the grp.getgrgid
and pwd.getpwuid functions. Both of the functions call
PyArg_ParseTuple with a type of "i", thus indicating the
argument is a signed integer. Instead they should be
using "I" (upper-case i) for an unsigned integer. The fix is
fairly simple. Here are the two patches necessary to the
python source:
diff -Naur Python-2.4.orig/Modules/grpmodule.c Python-
2.4/Modules/grpmodule.c
--- Python-2.4.orig/Modules/grpmodule.c 2004-01-20
16:06:00.0 -0500
+++ Python-2.4/Modules/grpmodule.c 2005-08-11
13:36:48.0 -0400
@@ -87,7 +87,7 @@
{
int gid;
struct group *p;
-if (!PyArg_ParseTuple(args, "i:getgrgid", &gid))
+if (!PyArg_ParseTuple(args, "I:getgrgid", &gid))
return NULL;
if ((p = getgrgid(gid)) == NULL) {
PyErr_Format(PyExc_KeyError, "getgrgid(): gid not
found: %d", gid);
diff -Naur Python-2.4.orig/Modules/pwdmodule.c Python-
2.4/Modules/pwdmodule.c
--- Python-2.4.orig/Modules/pwdmodule.c 2004-01-20
16:07:23.0 -0500
+++ Python-2.4/Modules/pwdmodule.c 2005-08-11
13:36:27.0 -0400
@@ -104,7 +104,7 @@
{
int uid;
struct passwd *p;
- if (!PyArg_ParseTuple(args, "i:getpwuid", &uid))
+ if (!PyArg_ParseTuple(args, "I:getpwuid", &uid))
return NULL;
if ((p = getpwuid(uid)) == NULL) {
PyErr_Format(PyExc_KeyError,
Hopefully, someone from the python project can verify my
patch and get it incorporated into a future release.
--
Comment By: Clark Mobarry (cmobarry)
Date: 2005-08-03 20:40
Message:
Logged In: YES
user_id=1035073
The same error occurs for an Intel P4-521 processor running
RedHat Enterprise Linux WS v4 Intel EM64T 64bit.
$ cat /proc/version
Linux version 2.6.9-5.ELsmp ([EMAIL PROTECTED])
(gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP
Wed Jan 5 19:29:47 EST 2005
test test_grp failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_grp.py",
line 29, in test_values
e2 = grp.getgrgid(e.gr_gid)
OverflowError: signed integer is greater than maximum
test test_pwd failed -- Traceback (most recent call last):
File
"/home/cmobarry/downloads/Python-2.4.1/Lib/test/test_pwd.py",
line 42, in test_values
self.assert_(pwd.getpwuid(e.pw_uid) in
entriesbyuid[e.pw_uid])
OverflowError: signed integer is greater than maximum
--
Comment By: Miki Tebeka (tebeka)
Date: 2005-03-17 10:20
Message:
Logged In: YES
user_id=358087
I've tried the patch - no luck :-(
I'm stealing time on these machines since they belong to
another group.
However I see that SF's compile farm
(http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
have an AMD64 host (amd64-linux1)
Maybe you can shorten the loop ...
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-14 23:17
Message:
Logged In: YES
use
[ python-Bugs-1281383 ] array.arrays are not unpickleable
Bugs item #1281383, was opened at 2005-09-03 22:16
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=1281383&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: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Reinhold Birkenfeld (birkenfeld)
Assigned to: Raymond Hettinger (rhettinger)
Summary: array.arrays are not unpickleable
Initial Comment:
Credits to John Machin for discovering this.
"""
Googling for "pickle array" in comp.lang.python yields
old messages that
show a PickleError -- plus one message where Alex
Martelli writes "I am
but an egg" :O)
Looks like arrays are NOW (2.4.1) pickleable but not
unpickleable -- see
below.
I appreciate that arrays are inherently not pickleable
because of the
type code.
However:
(1) Anyone know why/when the world changed?
(2) If we had alternative constructors like
array.iarray(contents) in
parallel to array.array('i', contents), those objects
could be
pickled/unpickled -- yes/no?
Cheers,
John
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import pickle, array
>>> class Foo(object):
...pass
...
>>> foo = Foo()
>>> foo.ia = array.array('i', [3,2,1])
>>> foo.ia
array('i', [3, 2, 1])
>>> s = pickle.dumps(foo, -1)
>>> bar = pickle.loads(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\pickle.py", line 1394, in loads
return Unpickler(file).load()
File "C:\Python24\lib\pickle.py", line 872, in load
dispatch[key](self)
File "C:\Python24\lib\pickle.py", line 1097, in
load_newobj
obj = cls.__new__(cls, *args)
TypeError: array() takes at least 1 argument (0 given)
===
"""
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values
Bugs item #1281408, was opened at 2005-09-04 01:12
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=1281408&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: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_BuildValue k format units don't work with big values
Initial Comment:
Python 2.4 on Windows XP SP2
Consider this code:
unsigned long x = 0xaabbccdd;
PyObject* v = Py_BuildValue("k", x);
unsigned long y = PyLong_AsUnsignedLong(v);
y will be equal with -1 because PyLong_AsUnsignedLong
will raise an OverflowError since Py_BuildValue doesn't
create a long for the "k" format unit, but an int which
will be interpreted as a negative number.
The K format seems to have the same error,
PyLong_FromLongLong is used instead of
PyLong_FromUnsignedLongLong.
The do_mkvalue function from mod_support.c must be
fixed to use PyLong_FromUnsignedLong instead of
PyInt_FromLong for "k".
Also, the BHLkK format units for Py_BuildValue should
be documented. In my Python 2.4 manual they do not appear.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281383 ] array.arrays are not unpickleable
Bugs item #1281383, was opened at 2005-09-03 15:16
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&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: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 6
Submitted By: Reinhold Birkenfeld (birkenfeld)
Assigned to: Raymond Hettinger (rhettinger)
Summary: array.arrays are not unpickleable
Initial Comment:
Credits to John Machin for discovering this.
"""
Googling for "pickle array" in comp.lang.python yields
old messages that
show a PickleError -- plus one message where Alex
Martelli writes "I am
but an egg" :O)
Looks like arrays are NOW (2.4.1) pickleable but not
unpickleable -- see
below.
I appreciate that arrays are inherently not pickleable
because of the
type code.
However:
(1) Anyone know why/when the world changed?
(2) If we had alternative constructors like
array.iarray(contents) in
parallel to array.array('i', contents), those objects
could be
pickled/unpickled -- yes/no?
Cheers,
John
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310
32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import pickle, array
>>> class Foo(object):
...pass
...
>>> foo = Foo()
>>> foo.ia = array.array('i', [3,2,1])
>>> foo.ia
array('i', [3, 2, 1])
>>> s = pickle.dumps(foo, -1)
>>> bar = pickle.loads(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\pickle.py", line 1394, in loads
return Unpickler(file).load()
File "C:\Python24\lib\pickle.py", line 872, in load
dispatch[key](self)
File "C:\Python24\lib\pickle.py", line 1097, in
load_newobj
obj = cls.__new__(cls, *args)
TypeError: array() takes at least 1 argument (0 given)
===
"""
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-03 18:20
Message:
Logged In: YES
user_id=80475
In Py2.4, array's became copyable, weak-referencable, and
got support for iterator arguments. Real pickle support
wasn't added until Py2.5. The above code fragment is a
by-product of pickle making an incorrect guess at how to
pickle arrays before real pickel support was added. It is
not really a bug; rather, it begs for a feature that wasn't
added to later.
If it weren't a new feature, I would just backport the 2.5
pickle support.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281383&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-687747 ] _iscommand() in webbrowser module
Bugs item #687747, was opened at 2003-02-17 07:17
Message generated for change (Comment added) made by ekid
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&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: Matthew Cowles (mdcowles)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: _iscommand() in webbrowser module
Initial Comment:
[From a post to python-help]
Under KDE under Mandrake Linux the BROWSER environment
variable is set to
kfmclient openProfile webbrowsing
The problem is that _iscommand() in the webbrowser
module doesn't realize that only the first thing there
is the name of the executable. It looks for an
executable with that whole thing as its name and
doesn't find one. Since the module doesn't use any
browser it has found if BROWSER is set, it raises an
error rather than opening the page.
The possible fixes that are obvious to me all have
potential disadvantages:
One solution would be to assume that the name of the
executable ran only up to the first space. But
executables can have spaces in their names, especially
on a Macintosh, I think.
Another possibility would be not to call _iscommand()
on anything in BROWSER. That would have the additional
advantage of not requiring that the executable
specified there be in a directory that's in the user's
PATH. The problem with doing things this way is that it
would be impossible to tell which of the browsers
specified in BROWSER should be used until the user
called open().
I'm prepared to work on a fix if given some guidance
about the best way to go.
--
Comment By: Dmitry Vukolov (ekid)
Date: 2005-09-04 04:36
Message:
Logged In: YES
user_id=1000960
The problem still exists in Python 2.4.1
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-05-30 23:37
Message:
Logged In: YES
user_id=752496
richard seems to reproduced it on Py2.3, changing the group
to it.
--
Comment By: Richard Jones (richard)
Date: 2005-01-17 01:01
Message:
Logged In: YES
user_id=6405
This is still an issue.
python -c 'import
webbrowser;webbrowser.open("http://www.google.com/";)'
on a system using KDE will exhibit the break.
I posted a patch to fix the behaviour in my last message. I just
noticed that I invoked diff the wrong way around (though the
explanation still stands) - a correct invocation:
--- /tmp/webbrowser.py 2005-01-17 08:59:50.697657208
+1100
+++ /usr/lib/python2.3/webbrowser.py2005-01-17
08:59:58.269989095 +1100
@@ -354,7 +354,7 @@
if "BROWSER" in os.environ:
# It's the user's responsibility to register handlers for any
unknown
# browser referenced by this value, before calling open().
-_tryorder = os.environ["BROWSER"].split(os.pathsep)
+_tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep)
for cmd in _tryorder:
if not cmd.lower() in _browsers:
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-15 15:26
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: Richard Jones (richard)
Date: 2003-08-20 04:29
Message:
Logged In: YES
user_id=6405
This is still an issue... has there been any movement on it outside of this
bug report?
I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is
finding the BROWSER env var as described above, and thus not finding a
usable browser.
As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but
just prepended with its value. Sure, that means that the KDE BROWSER
value will be ignored, but it'll still find konqueror. This approach works for
me, and I'm sure it'll work for others who have "valid" BROWSER
values
:)
Simple patch against python2.3 (sorry, sf will mangle this, but it's short):
--- webbrowser.py 2003-08-20 10:28:07.0 +1000
+++ /usr/lib/python2.3/webbrowser.py2003-08-04
10:18:17.0 +1000
@@ -354,7 +354,7 @@
if "BROWSER" in os.environ:
# It's the user's responsibility to register handlers for any unknown
# browser referenced by this value, before calling open().
-_tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep)
+_tryorder = os.envi
