[ python-Bugs-687747 ] _iscommand() in webbrowser module
Bugs item #687747, was opened at 2003-02-17 05:17
Message generated for change (Comment added) made by birkenfeld
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: Closed
>Resolution: Fixed
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: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-15 09:51
Message:
Logged In: YES
user_id=1188172
Corrected in webbrowser.py r1.37.4.1. For the 2.5 branch, a
new patch will be checked in which corrects this too.
--
Comment By: Dmitry Vukolov (ekid)
Date: 2005-09-04 02: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 21: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-16 23: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 13: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 02: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
[ python-Bugs-1114929 ] webbrowser doesn't start default Gnome browser by default
Bugs item #1114929, was opened at 2005-02-02 19:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114929&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jeremy Sanders (jeremysanders) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser doesn't start default Gnome browser by default Initial Comment: I've written a patch to try to access the default Gnome web browser under Unix (if Gnome is available). This is likely to be a good choice of web browser under modern systems. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 09:56 Message: Logged In: YES user_id=1188172 Subsumed by big 2.5 webbrowser patch #754022. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1114929&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-844336 ] urllib2 fails its builtin test
Bugs item #844336, was opened at 2003-11-18 13:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:11 Message: Logged In: YES user_id=1188172 Closing as requested. -- Comment By: John J Lee (jjlee) Date: 2005-05-19 22:22 Message: Logged In: YES user_id=261020 This should be closed: this issue was resolved by patch 852995. -- Comment By: John J Lee (jjlee) Date: 2003-12-08 01:17 Message: Logged In: YES user_id=261020 Sorry, last comment not very useful. I think this should be closed. Two real problems: 1. urllib2.urlopen incorrectly raises OSError instead of URLError. This is already detected by my unit tests (852995), and I'll file a separate bug for this later (when/if 852995 is resolved). 2. Would be nice if urllib2's functional tests used PyUnit (so it is clear which tests are passing or failing), and worked on Windows. Again, I'll submit a separate patch. To the bug poster: 0. ftplib is not urllib2, please report bugs separately. 1. You're not invoking ftplib's test program correctly. It seems to work, at least partially: python ftplib.py ftp.python.org /pub/www.python.org/index.html 2. It seems you're using Windows, so you shouldn't expect opening /etc/password to work (though the test shouldn't crash as it does, of course, and it should work on Windows, and it should give an indication of pass/fail). -- Comment By: John J Lee (jjlee) Date: 2003-12-03 20:40 Message: Logged In: YES user_id=261020 It is broken. I'd like to know where functional tests officially live before fixing it. I'll ask on python-dev... -- Comment By: Colin J. Williams (cjwhrh) Date: 2003-11-18 23:04 Message: Logged In: YES user_id=285587 This is a response to quiver. Thanks for pointing out the correct usage of ftlib, I am slowly sorting out how to use ftplib from a script. Unfortunately my report did not make it clear that there is a problem with the operation of the test function. Usually, a test function gives some assurance that the main code of the module is functional. In this case, the test fails. That, I suggest, indicates a bug. The bug could be in test function or the module being exercised. You are probably right that a host needs to be specified. I suggest that the test function should be responsible for this. Incidentally, it would be very helpful to the potential user if the documentation made the names and roles of the various cmds's clearer. -- Comment By: George Yoshida (quiver) Date: 2003-11-18 16:48 Message: Logged In: YES user_id=671362 For the first one, you need to specify a host to run the test. For expample, >python ftplib.py ftp.python.org -l This gives drwxrwxr-x 5 webmaster webmaster 512 Jan 25 2003 pub There is a usage on the test in the script: '''Test program. Usage: ftp [-d] [-r[file]] host [-l[dir]] [-d[dir]] [-p] [file] ...''' I think this is not a bug. For the second one, catching OSError along with IOError might be needed. ---
[ python-Bugs-1291662 ] Installation of waste by MacPython installer
Bugs item #1291662, was opened at 2005-09-15 08:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291662&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: Macintosh Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Freek Dijkstra (macfreek) Assigned to: Jack Jansen (jackjansen) Summary: Installation of waste by MacPython installer Initial Comment: Hi, I just installed MacPython 2.3 (on my Mac with Tiger 10.4), and found that the IDE did not launch with this error in the console.log: Traceback (most recent call last): File "/Applications/MacPython/PythonIDE.app/ Contents/Resources/PythonIDE.py", line 58, in ? import PythonIDEMain as _PythonIDEMain File "/Applications/MacPython/PythonIDE.app/ Contents/Resources/PythonIDEMain.py", line 7, in ? import W File "/System/Library/Frameworks/Python.framework/ Versions/2.3/Mac/Tools/IDE/W.py", line 7, in ? from Wtext import * File "/System/Library/Frameworks/Python.framework/ Versions/2.3/Mac/Tools/IDE/Wtext.py", line 6, in ? import waste ImportError: No module named waste (included line-breaks for readability). The problem was solved relatively easy: I noticed that /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages points to /Library/Python/2.3/site- packages/ but that waste.so was installed (apparently by the MacPython 2.3) installer in /Library/Python/2.3/. mv /Library/Python/2.3/waste.so /Library/Python/2.3/site- packages/ did solve the problem, and PythonIDE did launch. Is this a bug in the installer? Perhaps the aforementioned symbolic link changed from /Library/Python/2.3/ to /Library/Python/2.3/site-packages/ since the release of 10.4. Kind regards, Freek Dijkstra -- >Comment By: Jack Jansen (jackjansen) Date: 2005-09-15 12:20 Message: Logged In: YES user_id=45365 This is a known problem with 2.3. It is fixed with MacPython 2.3.5, which you can find on the "pre-production builds" of the MacPython homepage. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1291662&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: Closed
>Resolution: Fixed
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-15 12:26
Message:
Logged In: YES
user_id=1188172
Closing as requested.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2005-09-14 20:17
Message:
Logged In: YES
user_id=6380
Martin, IMO you can close this now that I've checked in the
AIX patch which should address this with the i->I change
suggested in a comment below. (patch 1284289)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-07 23:16
Message:
Logged In: YES
user_id=33168
See this patch which looks like it may fix the same problem
(among others).
https://sourceforge.net/tracker/index.php?func=detail&aid=1284289&group_id=5470&atid=305470
--
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
[ python-Bugs-868706 ] Calling builtin function 'eval' from C causes seg fault.
Bugs item #868706, was opened at 2004-01-01 04:41 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&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: 5 Submitted By: Zac Evans (karadoc) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Calling builtin function 'eval' from C causes seg fault. Initial Comment: Using C to get the eval function from builtins then call it causes a Seg-Fault. I've tried calling it using PyObject_CallObject, "_CallFunction, "_CallFunctionObjArg s. All cause the same problem. Other builtin functions seem to work correctly. and eval seems to work correctly from python (obviously). It's just calling eval from C which causes the crash. Attached is some sample code which demonstrates the problem. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:47 Message: Logged In: YES user_id=1188172 I fixed this; eval() now raises a TypeError when called from C without globals/locals. Committed in Python/bltinmodule.c r2.325, r2.318.2.3. -- Comment By: Zac Evans (karadoc) Date: 2004-01-02 04:04 Message: Logged In: YES user_id=117625 In my opinion, the 'bug' isn't really a big problem. If it is nicer for the internals of Python if the bug isn't fixed, than that would be fine. Although, it would be a good thing to document somewhere. Ideally, the call should raise an expection saying what the problem is. That's always nicer than a seg-fault. Also, on an almost unrelated note, why are PyEval_EvalCode() and a whole lot of other PyEval_* functions missing from the Python/C API index in the docs (http://www.python.org/doc/current/api/genindex.html)? And that's about all I have to say about that. Thank you for you time and quick reponse. -- Comment By: Neal Norwitz (nnorwitz) Date: 2004-01-01 22:52 Message: Logged In: YES user_id=33168 The attached patch fixes the problem, but I'm not sure this should be applied. Partially because I'm not sure it's the best solution. I'm also not sure if your use should be considered correct. I'm not sure if this is documented. Perhaps that should be changed? I understand your complaint, however, you can fix the problem my passing a dictionary for globals. You can also call PyEval_EvalCode or PyEval_EvalCodeEx. But in both of those cases you will need to supply globals. I believe the reason for the segfault is that globals is NULL since there is no frame. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868706&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1069092 ] segfault on printing nested sequences of None/Ellipsis
Bugs item #1069092, was opened at 2004-11-19 00:31 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069092&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Jonas Kölker (jonaskoelker) Assigned to: Nobody/Anonymous (nobody) Summary: segfault on printing nested sequences of None/Ellipsis Initial Comment: ## bug1.py loop = None, while True: loop = loop, None bash$ python -i bug1.py (I press C-c) >>> print loop ( (segfault bash$ bash$ python -i bug1.py (I press C-c) >>> str(loop) segfault bash$ bash$ python -i bug1.py (I press C-c) >>> repr(loop) segfault bash$ --- --- the results are the same for bug2.py, bug3.py and bug.py4 which have the same contents, except that loop is a list, None is replaced by Ellipsis or both. The behavior (i.e. segfaulting) is the same. also, when pressing C-c, python's memory usage remains constant. gc.garbage is empty; gc.collect() returns 0 and doesn't free memory. my python and uname: bash$ python Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 bash$ uname --all Linux koelker 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 GNU/Linux I have also reproduced it on Python 2.3.3 (#1, May 7 2004, 10:31:40) [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2 bash$ uname --all Linux horse09 2.6.8-1.521smp #1 SMP Man Aug 16 09:25:06 EDT 2004 i686 i686 i386 GNU/Linux and on Python 2.4a3 (#1, Oct 3 2004, 12:05:12) [GCC 3.3.2] on linux2 (on the same machine) it didn't reproduce on Python 1.5.2 (#1, Mar 9 2000, 17:40:34) [GCC 2.95.2 19991024 (release)] on hp-uxB bash$ uname -a HP-UX aragorn B.11.11 U 9000/782 2006786478 unlimited-user license but it did on Python 1.5.2 (#1, Jul 5 2001, 03:02:19) [GCC 2.96 2731] (Red Hat Linux 7.1 2 on linux-i386 bash$ uname Linux legolas 2.4.20-20.7smp #1 SMP Mon Aug 18 14:46:14 EDT 2003 i686 unknown -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-15 12:56 Message: Logged In: YES user_id=1188172 I can reproduce this here on Linux with 10x None. Will try to investigate. -- Comment By: Terry J. Reedy (tjreedy) Date: 2004-11-24 08:43 Message: Logged In: YES user_id=593130 On <<>> I got (interactive mode, about 5 sec before ^C) appropriate output: (( Traceback (most recent call last): File "", line 1, in ? MemoryError: stack overflow The nested depth was >>> i=0 >>> while loop: loop,i = loop[0], i+1 ... >>> i 50695 Note: a test case would need a finite loop such as: for i in range(10) instead of while True (until ^C pressed). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069092&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289118 ] timedelta multiply and divide by floating point
Bugs item #1289118, was opened at 2005-09-12 17:41 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&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: Daniel Stutzbach (agthorr) Assigned to: Tim Peters (tim_one) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' -- >Comment By: Michael Chermside (mcherm) Date: 2005-09-15 12:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 00:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289118 ] timedelta multiply and divide by floating point
Bugs item #1289118, was opened at 2005-09-12 17:41 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&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: Daniel Stutzbach (agthorr) >Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' -- >Comment By: Tim Peters (tim_one) Date: 2005-09-15 17:04 Message: Logged In: YES user_id=31435 timedelta arithmetic is 100% portable now, and wholly explainable in terms of universally understood integer arithmetic. Throw floats into it, and that's lost. That said, I don't have a strong objection to complicating the implementation if there _are_ strong use cases. The OP's example isn't "a use case": it's not worth anything to let someone multiply a timedelta by 0.5 instead of dividing by 2. I don't have a use case to offer in its place (never felt a need here). If someone wants to work on it, note that a timedelta can contain more than 53 bits of information, so, e.g., trying to represent a timedelta as an IEEE double-precision number of microseconds can lose information. This makes a high- qualty "computed as if to infinite precision with one rounding at the end" implementation of mixed datetime/float arithmetic tricky to do right. -- Comment By: Michael Chermside (mcherm) Date: 2005-09-15 12:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-13 00:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1289118 ] timedelta multiply and divide by floating point
Bugs item #1289118, was opened at 2005-09-12 14:41 Message generated for change (Comment added) made by agthorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&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: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: timedelta multiply and divide by floating point Initial Comment: In python 2.4.1, the datetime.timedelta type allows for the multiplication and division by integers. However, it raises a TypeError for multiplication or division by floating point numbers. This is a counterintutive restriction and I can't think of any good reason for it. For example: >>> import datetime >>> datetime.timedelta(minutes=5)/2 datetime.timedelta(0, 150) >>> datetime.timedelta(minutes=5)*0.5 Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for *: 'datetime.timedelta' and 'float' -- >Comment By: Daniel Stutzbach (agthorr) Date: 2005-09-15 15:00 Message: Logged In: YES user_id=6324 Let me elaborate on the use-case where I originally ran into this. I'm conducting a series of observation experiments where I measure the duration of an event. I then want to do various statistical analysis such as computing the mean, median, etc. Originally, I tried using standard functions such as lmean from the stats.py package. However, these sorts of functions divide by a float at the end, causing them to fail on timedelta objects. Thus, I have to either write my own special functions, or convert the timedelta objects to integers first (then convert them back afterwards). Basically, I want timedelta objects to look and act like fixed-point arithmetic objects so that I can reuse other functions on them that were originally developed to operate on floats. More importantly, I'd rather not have to maintain two different versions of the functions to deal with different types. For implementation, why not multiply the float times .day, .seconds, and .microseconds separately, then propagate and fraction parts into the next smallest group (e.g., 0.5 days becomes 24*60*60*0.5 seconds). I agree it'd be possible to lose information with the wrong sequence of operations, but that's always the case when using floating point numbers. In other words, that, too, is what I would expect from the timedelta implementation. -- Comment By: Tim Peters (tim_one) Date: 2005-09-15 14:04 Message: Logged In: YES user_id=31435 timedelta arithmetic is 100% portable now, and wholly explainable in terms of universally understood integer arithmetic. Throw floats into it, and that's lost. That said, I don't have a strong objection to complicating the implementation if there _are_ strong use cases. The OP's example isn't "a use case": it's not worth anything to let someone multiply a timedelta by 0.5 instead of dividing by 2. I don't have a use case to offer in its place (never felt a need here). If someone wants to work on it, note that a timedelta can contain more than 53 bits of information, so, e.g., trying to represent a timedelta as an IEEE double-precision number of microseconds can lose information. This makes a high- qualty "computed as if to infinite precision with one rounding at the end" implementation of mixed datetime/float arithmetic tricky to do right. -- Comment By: Michael Chermside (mcherm) Date: 2005-09-15 09:03 Message: Logged In: YES user_id=99874 I, too, would like to know what Tim thinks, but for what it's worth (not much) I find Daniel's point fairly convincing... multiplication by floats is an operation that makes sense, has only one possible obvious meaning, and is not particularly likely to cause errors (the way multiplying Decimal's with floats does). So IF it's easy to implement, I say go for it. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-12 21:11 Message: Logged In: YES user_id=80475 Tim, do you prefer the current behavior? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289118&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1118729 ] Error in representation of complex numbers(again)
Bugs item #1118729, was opened at 2005-02-09 01:26
Message generated for change (Comment added) made by quiver
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&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: George Yoshida (quiver)
Assigned to: Martin v. Löwis (loewis)
Summary: Error in representation of complex numbers(again)
Initial Comment:
>>> -(1+0j)
(-1+-0j)
I encountered this while I was calculating conjugate of
complex numbers(e.g. z.conjugate()).
Related bug
* http://www.python.org/sf/1013908
One thing to note is that -(0j) can return 0j or -0j
dependeing on OSes.
Confirmed on SuSE 9.1 & cygwin.
--
>Comment By: George Yoshida (quiver)
Date: 2005-09-16 14:02
Message:
Logged In: YES
user_id=671362
Can anyone else review this patch before the new 2.4 gets
released?
The patch is ready to be commited.
--
Comment By: George Yoshida (quiver)
Date: 2005-05-15 21:22
Message:
Logged In: YES
user_id=671362
The fix seems reasonable to me and it passed the test
suites.
Please apply it.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-15 16:57
Message:
Logged In: YES
user_id=21627
What do you think about the patch attached?
--
Comment By: George Yoshida (quiver)
Date: 2005-03-20 02:11
Message:
Logged In: YES
user_id=671362
Martin, what's your take on this?
The representation of '-(1+0j)' has changed since Revision 2.71
(complexobject.c) and you applied the patch.
# original patch
making Python LC_NUMERIC agnostic
http://www.python.org/sf/774665
--
Comment By: George Yoshida (quiver)
Date: 2005-02-10 09:02
Message:
Logged In: YES
user_id=671362
Hi, Björn.
Sorry, not to be clear about what my complaint is. I'm not
talking about if -(0j) should be 0j or -0j. It's been that way
for a long time, so changing it would break old codes.
My point is the signature of imaginary part. As you can see,
it's represented as '+-'. Before the commit of patch #774665,
it was represented as '-1-0j'. But after that, '-1+-0j'.
If you test it with Python <= 2.3, you'll get (-1-0j) and I think
this is how -(1+0j) should be represented on machines where -
(0j) is represented as -0j.
--
Comment By: Björn Lindqvist (sonderblade)
Date: 2005-02-10 03:54
Message:
Logged In: YES
user_id=51702
What you are seeing is negative zero (-0.0). It is distinct
from positive zero (0.0) but 0.0 == -0.0 is always true. On
some machines you can also see it by typing:
>>> -0.0
-0.0
On other machines you will see "0.0" instead. You can also try
printf("%f\n", -0.0); and you will notice the same thing. So
I'm not sure it is a bug per se. However, it can be worked
around by adding "if (v->cval.imag == 0.) v->cval.imag =
0.0;" to complexobject.c, assuming ofcourse it is OK to
change negative zeros to positive ones.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1118729 ] Error in representation of complex numbers(again)
Bugs item #1118729, was opened at 2005-02-08 17:26
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&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: Accepted
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Martin v. Löwis (loewis)
Summary: Error in representation of complex numbers(again)
Initial Comment:
>>> -(1+0j)
(-1+-0j)
I encountered this while I was calculating conjugate of
complex numbers(e.g. z.conjugate()).
Related bug
* http://www.python.org/sf/1013908
One thing to note is that -(0j) can return 0j or -0j
dependeing on OSes.
Confirmed on SuSE 9.1 & cygwin.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-16 08:43
Message:
Logged In: YES
user_id=1188172
Reviewed and applied in Objects/complexobject.c r2.74, 2.72.2.2.
--
Comment By: George Yoshida (quiver)
Date: 2005-09-16 07:02
Message:
Logged In: YES
user_id=671362
Can anyone else review this patch before the new 2.4 gets
released?
The patch is ready to be commited.
--
Comment By: George Yoshida (quiver)
Date: 2005-05-15 14:22
Message:
Logged In: YES
user_id=671362
The fix seems reasonable to me and it passed the test
suites.
Please apply it.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-15 09:57
Message:
Logged In: YES
user_id=21627
What do you think about the patch attached?
--
Comment By: George Yoshida (quiver)
Date: 2005-03-19 18:11
Message:
Logged In: YES
user_id=671362
Martin, what's your take on this?
The representation of '-(1+0j)' has changed since Revision 2.71
(complexobject.c) and you applied the patch.
# original patch
making Python LC_NUMERIC agnostic
http://www.python.org/sf/774665
--
Comment By: George Yoshida (quiver)
Date: 2005-02-10 01:02
Message:
Logged In: YES
user_id=671362
Hi, Björn.
Sorry, not to be clear about what my complaint is. I'm not
talking about if -(0j) should be 0j or -0j. It's been that way
for a long time, so changing it would break old codes.
My point is the signature of imaginary part. As you can see,
it's represented as '+-'. Before the commit of patch #774665,
it was represented as '-1-0j'. But after that, '-1+-0j'.
If you test it with Python <= 2.3, you'll get (-1-0j) and I think
this is how -(1+0j) should be represented on machines where -
(0j) is represented as -0j.
--
Comment By: Björn Lindqvist (sonderblade)
Date: 2005-02-09 19:54
Message:
Logged In: YES
user_id=51702
What you are seeing is negative zero (-0.0). It is distinct
from positive zero (0.0) but 0.0 == -0.0 is always true. On
some machines you can also see it by typing:
>>> -0.0
-0.0
On other machines you will see "0.0" instead. You can also try
printf("%f\n", -0.0); and you will notice the same thing. So
I'm not sure it is a bug per se. However, it can be worked
around by adding "if (v->cval.imag == 0.) v->cval.imag =
0.0;" to complexobject.c, assuming ofcourse it is OK to
change negative zeros to positive ones.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1118729&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
