\nLe contenu de cette page (Thomas-Robert Bugeaud) est un minuscule extrait de l\'encyclopi\xc3\xa9die gratuite en ligne WIKIPEDIA\nle webmaster de ce site n\'est pas l\'auteur de cet article (Thomas-Robert Bugeaud). Vous pouvez retrouver l\'original de cet article (Thomas-Robert Bugeaud) à cette adresse et la liste des auteurs ici\nVous pouvez modifier ou compl\xc3\xa9ter cet article mais \xc3\xa9galement discuter de son contenu (Thomas-Robert Bugeaud) sur le site de WIKIPEDIA France - Contenu (Thomas-' >>> ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Dec 26 17:49:23 2007 From: report at bugs.python.org (Senthil) Date: Wed, 26 Dec 2007 16:49:23 -0000 Subject: [issue1205] urllib fail to read URL contents, urllib2 crash Python In-Reply-To: <20071226165735.GA4111@gmail.com> Message-ID: <20071226170025.GB4111@gmail.com> Senthil added the comment: > > Senthil added the comment: > > Irrespective of the patch, this issue is reproducable with the code in the > trunk for Python 2.6. Should we close this then? > __________________________________ Sorry, I meant to say "NOT Reproducable". __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Dec 26 18:24:55 2007 From: report at bugs.python.org (Senthil) Date: Wed, 26 Dec 2007 17:24:55 -0000 Subject: [issue1698] urlparse and usernames containing @ In-Reply-To: <1198687104.0.0.161207960419.issue1698@psf.upfronthosting.co.za> Message-ID: <20071226173554.GC4111@gmail.com> Senthil added the comment: > Olivier Croquette added the comment: > > > The problem right now is that urlparse parses silently an URL which is > not compliant, but does the wrong thing with it (since usernames can > contain @, and hostname can not, it's a more logical thing to parse from > the right using rsplit instead of split). > > I see two possibilities to address that: > > 1. return a parse error if the URL contains two raw @ > This way users and app developers will notice the problem rapidly > > 2. still accept this malformed URLs, but do what the user expects > > Both solutions seem to me better than the current behaviour, so I would > say a change is necessary anyways. I am inclined towards the option 2, wherein even if the non-conformant URL is given, which has "@" in the user name, the urlparse should be able atleast recognize the hostname correctly. In this case, using rsplit instead of split does the trick. Attached is the patch against the trunk, which adds this. I notice duplicity project also retorting to the same. Unless anyone has an objection, we should commit this change. Added file: http://bugs.python.org/file9030/urlparse_issue1698.patch __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: urlparse_issue1698.patch Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071226/98f107b2/attachment.txt From report at bugs.python.org Wed Dec 26 18:29:46 2007 From: report at bugs.python.org (Senthil) Date: Wed, 26 Dec 2007 17:29:46 -0000 Subject: [issue1698] urlparse and usernames containing @ In-Reply-To: <1198687500.46.0.44079184842.issue1698@psf.upfronthosting.co.za> Message-ID: <20071226174046.GD4111@gmail.com> Senthil added the comment: > > Olivier Croquette added the comment: > > And about the decoding, sorry, it's clear from your snippets that > urlparse doesn't do it: > >>> print q.username > user%40xyz > > Maybe it should do it, I am not sure. What do you think? It would save > work for the module user. No, urlparse does not have any method for encoding/decoding. It has been left to urllib2 in urlencode, urldecode, quote, unquote etc. Strangely though, user should use urllib2 for that purpose. And yeah, there is been an effort to merge the urlparse and urllib2 functionality and I am slowly upto it. :) Before more requests come this way, I guess I have to show some progress. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Dec 26 18:40:53 2007 From: report at bugs.python.org (hjmjohnson) Date: Wed, 26 Dec 2007 17:40:53 -0000 Subject: [issue1701] svn checkout does not work Message-ID: <1198690853.59.0.588527632506.issue1701@psf.upfronthosting.co.za> New submission from hjmjohnson: =========== ping svn.python.org PING svn.python.org (82.94.237.220): 56 data bytes 64 bytes from 82.94.237.220: icmp_seq=0 ttl=49 time=107.208 ms ======== svn co http://svn.python.org/projects/python/trunk python-svn svn: PROPFIND request failed on '/projects/python/trunk' svn: PROPFIND of '/projects/python/trunk': could not connect to server (http://svn.python.org) ========== It appears that the apache access to the svn repository is down. ---------- components: Build messages: 59003 nosy: hjmjohnson severity: critical status: open title: svn checkout does not work type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Dec 26 20:53:04 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Wed, 26 Dec 2007 19:53:04 -0000 Subject: [issue1701] svn checkout does not work Message-ID: <1198698784.8.0.584098535941.issue1701@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Fixed. ---------- nosy: +loewis resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Dec 26 21:36:56 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Wed, 26 Dec 2007 20:36:56 -0000 Subject: [issue1350] IDLE - CallTips enhancement - show full doc-string in new window Message-ID: <1198701416.24.0.981462433549.issue1350@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: I deleted the extra files. You aren't making this easy! I was expecting a relatively small update to the original patch. Did you backport my 3.0 revision of CallTips.py or did you come up with your own version which uses inspect.py? Right now, the patch includes two unrelated developments, which (following our normal procedures) wouldn't be combined as you have done. __________________________________ Tracker __________________________________ From report at bugs.python.org Wed Dec 26 23:59:10 2007 From: report at bugs.python.org (Paul Smedley) Date: Wed, 26 Dec 2007 22:59:10 -0000 Subject: [issue1745108] 2.5.1 curses panel segfault in new_panel on aix 5.3 Message-ID: <1198709950.71.0.526742981216.issue1745108@psf.upfronthosting.co.za> Paul Smedley added the comment: I see similar problems here on OS/2 with Python 2.5.1 and Ncurses 5.6. Problem is causes as win->win is uninitialised when passed to new_panel. Initialising win->win to a value makes the new_panel call work. Not sure why this works on other platforms but fails on OS/2 and AIX. ---------- nosy: +psmedley _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Dec 27 05:28:40 2007 From: report at bugs.python.org (Devin Jeanpierre) Date: Thu, 27 Dec 2007 04:28:40 -0000 Subject: [issue1702] Word "alias" used in confusing way to compare open() and file() Message-ID: <1198729720.38.0.104417938854.issue1702@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: I was slightly misled by the wording of part of the docs (http://docs.python.org/lib/bltin-file-objects.html): "file() is new in Python 2.2. The older built-in open() is an alias for file()." I actually thought it meant that open was an alias of file, so that 'open is file'. However, >>> open is file False I feel that "alias" is the wrong word to use here, though I don't know a suitable replacement. ---------- components: Documentation messages: 59007 nosy: Devin Jeanpierre severity: minor status: open title: Word "alias" used in confusing way to compare open() and file() type: rfe __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Dec 27 05:31:55 2007 From: report at bugs.python.org (Richard Cohen) Date: Thu, 27 Dec 2007 04:31:55 -0000 Subject: [issue1702] Word "alias" used in confusing way to compare open() and file() Message-ID: <1198729915.25.0.911162571586.issue1702@psf.upfronthosting.co.za> Changes by Richard Cohen: ---------- nosy: +vmlinuz __________________________________ Tracker __________________________________ From report at bugs.python.org Thu Dec 27 11:50:14 2007 From: report at bugs.python.org (Armin Rigo) Date: Thu, 27 Dec 2007 10:50:14 -0000 Subject: [issue1754489] Non-portable address length calculation for AF_UNIX sockets Message-ID: <1198752614.28.0.0782190530024.issue1754489@psf.upfronthosting.co.za> Armin Rigo added the comment: The patch looks ok on 2.6, I recommend checking it there. (Due to line number changes in socketmodule.c, the patch gives a warning, but it is still otherwise up-to-date.) ---------- nosy: +arigo _____________________________________ Tracker _____________________________________ From report at bugs.python.org Thu Dec 27 13:54:32 2007 From: report at bugs.python.org (Tal Einat) Date: Thu, 27 Dec 2007 12:54:32 -0000 Subject: [issue1350] IDLE - CallTips enhancement - show full doc-string in new window Message-ID: <1198760072.59.0.544654721392.issue1350@psf.upfronthosting.co.za> Tal Einat added the comment: I had a working version which also used inspect before I saw your 3.0 version, but they both use inspect similarly, very straightforward. I seem to recall only one of the version used inspect to get the doc string, but I don't remember which one... Depending on how you divide things, this patch includes more than just two different developments. But they are interrelated to some extent. And one of the developments is more rigorous testing, which this version passes with flying colors. If you wish, I can try to get another developer or two to test and review this patch, if that will help somehow. Or anything else that will help... __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 01:04:04 2007 From: report at bugs.python.org (Senthil) Date: Fri, 28 Dec 2007 00:04:04 -0000 Subject: [issue1702] Word "alias" used in confusing way to compare open() and file() In-Reply-To: <1198729720.38.0.104417938854.issue1702@psf.upfronthosting.co.za> Message-ID: <20071228001440.GA3519@gmail.com> Senthil added the comment: > I feel that "alias" is the wrong word to use here, though I don't know > a suitable replacement. Should we say, "The older built-in open() serves the same purpose as file." ---------- nosy: +orsenthil __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 01:14:34 2007 From: report at bugs.python.org (Philip Jenvey) Date: Fri, 28 Dec 2007 00:14:34 -0000 Subject: [issue1703] getpass broken in Py3k: must flush() Message-ID: <1198800874.65.0.655232075234.issue1703@psf.upfronthosting.co.za> New submission from Philip Jenvey: getpass (in particular _raw_input, used by unix_getpass and default_getpass) prints out a password prompt to a stream (by default stdout) but doesn't flush that stream. It assumes calling sys.stdin.readline() to read the password causes stdout to be flushed (probably a libc file buffering behavior) This is a problem in Py3k where file buffering is done by Python; getpass needs to manually flush the stream it prints the prompt to. Otherwise the prompt isn't printed until after the password is entered e.g.: Python 3.0a2 (py3k:59601, Dec 27 2007, 14:28:14) [GCC 4.1.3 20071209 (prerelease) (Debian 4.1.2-18)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import getpass >>> getpass.getpass() Password: 'foo' >>> Windows doesn't use _raw_input so it wouldn't see this issue. Attached is a patch to flush the stream. There's no getpass tests so I didn't get around to creating one for this issue. Ideally we'd test getpass via spawning a python subprocess and ensuring its I/O looked correct. This was noticed on Jython as its file object is now based off Py3k's ---------- components: Library (Lib) files: getpass_flush-r59601.diff messages: 59011 nosy: pjenvey severity: normal status: open title: getpass broken in Py3k: must flush() versions: Python 3.0 Added file: http://bugs.python.org/file9031/getpass_flush-r59601.diff __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: getpass_flush-r59601.diff Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071228/0670dc4c/attachment.txt From report at bugs.python.org Fri Dec 28 04:58:45 2007 From: report at bugs.python.org (Rich Marinaccio) Date: Fri, 28 Dec 2007 03:58:45 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1198814325.03.0.53847270276.issue1704@psf.upfronthosting.co.za> New submission from Rich Marinaccio: I have been using python for Civilization IV map scripting, and I believe I have found a small problem with the randint function. Once in a blue moon, randint(a,b) returns b + 1, rather than a >= N <= b. I have seen this behavior a few times. Here is the code I used to determine this. randIndex = PWRand.randint(0,len(preshuffle)-1)#PWRand calls randint directly with these parameters if randIndex < 0 or randIndex >= len(preshuffle): raise ValueError, " bad index shuffling plot list randIndex=%(r)d listLength=%(l)d, mapSize=%(s)d" % {"r":randIndex,"l":len (preshuffle),"s":hm.mapWidth*hm.mapHeight} #output is ValueError: bad index shuffling plot list randIndex=1453 listLength=1453, mapSize=13824 according to the docs, the max randIndex should be listLength - 1 ---------- components: None messages: 59012 nosy: cephalo severity: normal status: open title: possible bug in randint type: behavior versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 04:59:12 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 03:59:12 -0000 Subject: [issue1650] IDLE: help() displays output on the wrong shell Message-ID: <1198814351.87.0.399303575813.issue1650@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Fixed by overriding pydoc.py:pager to be plainpager. r59603 ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 05:00:00 2007 From: report at bugs.python.org (Rich Marinaccio) Date: Fri, 28 Dec 2007 04:00:00 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1198814400.28.0.841693724669.issue1704@psf.upfronthosting.co.za> Rich Marinaccio added the comment: I have been using python for Civilization IV map scripting, and I believe I have found a small problem with the randint function. Once in a blue moon, randint(a,b) returns b + 1, rather than a <= N <= b. I have seen this behavior a few times. Here is the code I used to determine this. randIndex = PWRand.randint(0,len(preshuffle)-1)#PWRand calls randint directly with these parameters if randIndex < 0 or randIndex >= len(preshuffle): raise ValueError, " bad index shuffling plot list randIndex=%(r)d listLength=%(l)d, mapSize=%(s)d" % {"r":randIndex,"l":len (preshuffle),"s":hm.mapWidth*hm.mapHeight} #output is ValueError: bad index shuffling plot list randIndex=1453 listLength=1453, mapSize=13824 according to the docs, the max randIndex should be listLength - 1 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 05:03:21 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 04:03:21 -0000 Subject: [issue1607] Patch for TCL 8.5 support Message-ID: <1198814601.23.0.182744021024.issue1607@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: This patch doesn't seem like the right way to fix the 8.5 issue...Close it? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 05:18:51 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 04:18:51 -0000 Subject: [issue1457] IDLE - configDialog - new layout for key config Message-ID: <1198815531.33.0.0967604504935.issue1457@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: r59604 Thanks for the Patch! ---------- resolution: -> accepted status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 05:45:10 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 04:45:10 -0000 Subject: [issue1563981] IDLE invokes completion even when running code Message-ID: <1198817110.52.0.727073288566.issue1563981@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Hard to fix since IDLE doesn't know that the interpreter went into input state. However, control-tab appears to do what you want. ---------- resolution: -> wont fix status: open -> closed _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Dec 28 05:47:08 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 04:47:08 -0000 Subject: [issue404444] [IDLE] auto indent/parentheses Message-ID: <1198817228.63.0.0471039134017.issue404444@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- nosy: +kbk ____________________________________ Tracker ____________________________________ From report at bugs.python.org Fri Dec 28 05:58:35 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 04:58:35 -0000 Subject: [issue1599] IDLE hangs if os.spwanv command is given Message-ID: <1198817915.6.0.119772685048.issue1599@psf.upfronthosting.co.za> New submission from Kurt B. Kaiser: Worked for me on Arch GNU/Linux using IDLE 2.6a0. What OS and Version are you running? Does it fail for foo.py: def foo(): pass >>> import os >>> os.spawnv(os.P_NOWAIT, 'foo.py', '') 5026 >>> ---------- assignee: -> kbk nosy: +kbk priority: -> normal resolution: -> works for me __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 06:13:31 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 05:13:31 -0000 Subject: [issue1601] IDLE not working correctly on Windows (Py30a2/IDLE30a1) Message-ID: <1198818811.24.0.0341286527978.issue1601@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Assigning to tiran since I'm not building Python on XP. Changing to Tkinter, also. Is the file open bug fixed also by the suggested change? ---------- assignee: kbk -> tiran components: +Tkinter -IDLE __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 06:55:47 2007 From: report at bugs.python.org (Pooja) Date: Fri, 28 Dec 2007 05:55:47 -0000 Subject: [issue1599] IDLE hangs if os.spwanv command is given In-Reply-To: <1198817915.6.0.119772685048.issue1599@psf.upfronthosting.co.za> Message-ID: <825531.71053.qm@web61011.mail.yahoo.com> Pooja added the comment: Hi Kurt I have mentioned in my issue 1599 that i was working on IDLE 2.5 and Win 32. Regards Pooja "Kurt B. Kaiser" wrote: New submission from Kurt B. Kaiser: Worked for me on Arch GNU/Linux using IDLE 2.6a0. What OS and Version are you running? Does it fail for foo.py: def foo(): pass 'foo.py', '') 5026 >>> ---------- assignee: -> kbk nosy: +kbk priority: -> normal resolution: -> works for me __________________________________ Tracker __________________________________ --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. Added file: http://bugs.python.org/file9032/unnamed __________________________________ Tracker __________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unnamed Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20071228/7afe85b2/attachment.txt From report at bugs.python.org Fri Dec 28 11:47:26 2007 From: report at bugs.python.org (Wummel) Date: Fri, 28 Dec 2007 10:47:26 -0000 Subject: [issue1705] trace module does not annotate global statement Message-ID: <1198838846.15.0.754612008579.issue1705@psf.upfronthosting.co.za> New submission from Wummel: Hi, the trace module does not properly count the global statement. So coverage tests of functions that use the global statement always file. To reproduce write a simple function using the global statement and store it in "mytest.py" (which is attached). Then run "python -m trace -c mytest.py". You'll see that the global statement line will not be covered (ie. there is no "1:" at the beginning of the line). I tested with Python 2.5 and 2.4. ---------- components: Extension Modules files: mytest.py messages: 59021 nosy: calvin severity: normal status: open title: trace module does not annotate global statement type: behavior Added file: http://bugs.python.org/file9033/mytest.py __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: mytest.py Type: text/x-python Size: 155 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071228/63b6dea8/attachment.py From report at bugs.python.org Fri Dec 28 14:22:02 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 28 Dec 2007 13:22:02 -0000 Subject: [issue1706] Force WINVER 0x0500 (Windows 2000) Message-ID: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za> New submission from Christian Heimes: Do you think it's a good idea to force Win2k compatibility by defining WINVER 0x0500 in PC/pyconfig.h? It fixed the problem with Tcl/Tk, #1601. http://msdn2.microsoft.com/en-us/library/aa383745.aspx #define WINVER 0x0500 #define _WIN32_WINNT 0x0500 ---------- assignee: loewis components: Windows messages: 59022 nosy: loewis, tiran severity: normal status: open title: Force WINVER 0x0500 (Windows 2000) versions: Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 14:35:41 2007 From: report at bugs.python.org (Tal Einat) Date: Fri, 28 Dec 2007 13:35:41 -0000 Subject: [issue1607] Patch for TCL 8.5 support Message-ID: <1198848941.06.0.685027748662.issue1607@psf.upfronthosting.co.za> Tal Einat added the comment: I say close it, but start a discussion on switching to Tcl/Tk8.5 on the appropriate list(s). __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 14:53:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Fri, 28 Dec 2007 13:53:29 -0000 Subject: [issue1607] Patch for TCL 8.5 support Message-ID: <1198850009.89.0.513931543613.issue1607@psf.upfronthosting.co.za> Christian Heimes added the comment: Can you start a discussion on python-dev please? Tcl/Tk support should be added to Python trunk (2.6) and ported to 3.0. Is it possible to keep compatibility with Tcl/Tk 8.4, too? ---------- resolution: -> rejected status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 15:07:23 2007 From: report at bugs.python.org (Aristotelis Mikropoulos) Date: Fri, 28 Dec 2007 14:07:23 -0000 Subject: [issue1778443] robotparser.py fixes Message-ID: <1198850843.3.0.0993655966171.issue1778443@psf.upfronthosting.co.za> Aristotelis Mikropoulos added the comment: Also, I would like to tell you that my new account name is "Indy", and not "indy90" anymore (I changed since this issue tracker moved from SourceForge to here). So, thanks again and I hope this patch will be helpful. _____________________________________ Tracker _____________________________________ From report at bugs.python.org Fri Dec 28 16:36:33 2007 From: report at bugs.python.org (Rich Marinaccio) Date: Fri, 28 Dec 2007 15:36:33 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1198856193.24.0.569891310389.issue1704@psf.upfronthosting.co.za> Rich Marinaccio added the comment: I've done some more testing and I can't get this to repeat with randint alone. It must be an issue with combination of the len() function used as a parameter to randint. The above code is in a loop that further down will del preshuffle[randIndex]. Could this be a threading issue where len(preshuffle) takes time to update when the list is shortened? __________________________________ Tracker __________________________________ From report at bugs.python.org Fri Dec 28 19:28:15 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Fri, 28 Dec 2007 18:28:15 -0000 Subject: [issue1061803] Source code encoding in IDLE console Message-ID: <1198866495.81.0.603680146791.issue1061803@psf.upfronthosting.co.za> Kurt B. Kaiser added the comment: Can this be closed? Is it still an issue in 3.0? ---------- nosy: +kbk _____________________________________ Tracker _____________________________________ From report at bugs.python.org Sat Dec 29 02:14:54 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Dec 2007 01:14:54 -0000 Subject: [issue1706] Force WINVER 0x0500 (Windows 2000) Message-ID: <1198890894.46.0.429154519746.issue1706@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's definitely not good to define it unconditionally in PC/pyconfig.h, as that would affect any extensions compiled for Python. I'm -0 on defining it conditionally for the compilation of Python itself. I dislike having to constrain Python to Windows 2000; IMO, windows version dependencies should be resolved at runtime. However, that option is probably still available with WINVER set. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 04:58:11 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Dec 2007 03:58:11 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1198900691.68.0.357680383555.issue1704@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Threading is the likely source of your problems. If you concur, please close this as invalid. ---------- nosy: +rhettinger __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 05:10:25 2007 From: report at bugs.python.org (Andre Roberge) Date: Sat, 29 Dec 2007 04:10:25 -0000 Subject: [issue1707] probable bug in code.py with Python 3.0a2 Message-ID: <1198901425.7.0.747577606442.issue1707@psf.upfronthosting.co.za> New submission from Andre Roberge: There appears to be a bug in code.py in Python 3.0a2/a1. I believe that the body of InteractiveConsole().raw_input() should be changed from sys.stdout.write(prompt) sys.stdout.flush() return sys.stdin.readline() to return input(prompt) Here's a sample session. Python 3.0a1 (py3k, Nov 27 2007, 07:40:26) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import code >>> console = code.InteractiveConsole() >>> console.interact() Python 3.0a1 (py3k, Nov 27 2007, 07:40:26) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> for i in range(3): ... print(i) 0 1 2 >>> # Notice how I could only enter one line inside the loop. >>> # Let's try again, with a different definition of raw_input() >>> import code >>> console = code.InteractiveConsole() >>> console.raw_input = input >>> console.interact() Python 3.0a1 (py3k, Nov 27 2007, 07:40:26) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> for i in range(3): ... print(i) ... 0 1 2 >>> # Notice how I had to enter an empty line to end the loop - as it should be. The same problem affects function definitions - it is impossible to define a function body with more than one line when running code.interact() ---------- components: Library (Lib) messages: 59030 nosy: aroberge severity: normal status: open title: probable bug in code.py with Python 3.0a2 versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 05:14:09 2007 From: report at bugs.python.org (PyScripter) Date: Sat, 29 Dec 2007 04:14:09 -0000 Subject: [issue1685] linecache .updatecache fails on utf8 encoded files Message-ID: <1198901649.45.0.213510982443.issue1685@psf.upfronthosting.co.za> PyScripter added the comment: To reproduce the error: a) Save the following file in utf-8 format as c:\temp\module1.py # -*- coding: utf-8 -*- print("?") b) Run the following script: import pdb d = pdb.Pdb() filename = r"c:\Temp\module1.py" print(d.set_break(filename,1)) Expected result None Actual Result Line c:\temp\module1.py:1 does not exist __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 05:36:00 2007 From: report at bugs.python.org (PyScripter) Date: Sat, 29 Dec 2007 04:36:00 -0000 Subject: [issue1685] linecache .updatecache fails on utf8 encoded files Message-ID: <1198902960.92.0.814821375271.issue1685@psf.upfronthosting.co.za> PyScripter added the comment: Patch file attached Added file: http://bugs.python.org/file9034/linecache.py.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: linecache.py.patch Type: application/octet-stream Size: 516 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071229/5d68306d/attachment.obj From report at bugs.python.org Sat Dec 29 15:21:13 2007 From: report at bugs.python.org (Christian Heimes) Date: Sat, 29 Dec 2007 14:21:13 -0000 Subject: [issue1706] Force WINVER 0x0500 (Windows 2000) Message-ID: <1198938073.01.0.453916550286.issue1706@psf.upfronthosting.co.za> Christian Heimes added the comment: The macros don't restrain us to Win2k but they prevent us from using APIs which are not compatible with Windows 2000. It's a compile time option to conditionally exclude new features from the header files. #ifndef NTDDI_VERSION #define NTDDI_VERSION NTDDI_WIN2KSP4 #endif #ifndef WINVER #define WINVER 0x0500 #endif #ifndef _WIN32_WINNT #define _WIN32_WINNT WINVER #endif __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 17:16:03 2007 From: report at bugs.python.org (Rich Marinaccio) Date: Sat, 29 Dec 2007 16:16:03 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1198944963.92.0.885546975153.issue1704@psf.upfronthosting.co.za> Rich Marinaccio added the comment: To be clear, I am not using multi-threading in my particular module. I can't explain this behavior with my code alone. The issue is complicated by the fact that my module is called by Civ IV, and I have no idea what the game is doing behind the scenes. I also don't know exactly what happens when 'del myList[index]' is called. You would think that len(preshuffle) would have the same value for the randint call that it does for the print statement. I have an idea for another test I would like to try. This is my first issue that I've reported in Python. Would it help for me to attach the whole file? __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 17:56:41 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Dec 2007 16:56:41 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1198947401.25.0.822528126211.issue1704@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching the whole file isn't a step in the right direction. The preferred approach is to isolate the problem as tightly as possible. This report is dubious because, I can't get the following to fail: from random import seed, randint seed('mystart') while 1: assert 0 <= randint(0, 1452) <= 1452 There is also no failure with: preshuffle = [None] * 1453 while 1: assert 0 <= randint(0, len(preshuffle)-1) <= 1452 Make sure that PWRand.randint() really does call randint() and not randrange() and that it doesn't adjust the range of inputs. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 18:40:46 2007 From: report at bugs.python.org (Rich Marinaccio) Date: Sat, 29 Dec 2007 17:40:46 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1198950046.7.0.163279301658.issue1704@psf.upfronthosting.co.za> Rich Marinaccio added the comment: What was happening before was I was getting an index out of range error every so often, so then I put in the ValueError catch to see what was going on. I was surprised to see that randIndex was the same as len (preshuffle). I have some further catches in place now that might tell me more. It must have to do with deleting items from the list in the loop and not getting the right length from len immediately after, but then again I use this algorithm in several places in my module with no trouble, though with smaller lists. Go ahead and close this, and when I have more information I can open it some other time. This bug I'm seeing is extremely intermittant. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 18:56:49 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Dec 2007 17:56:49 -0000 Subject: [issue1706] Force WINVER 0x0500 (Windows 2000) Message-ID: <1198951009.49.0.707097644201.issue1706@psf.upfronthosting.co.za> Martin v. L?wis added the comment: "The macros don't restrain us to Win2k but they prevent us from using APIs which are not compatible with Windows 2000." --- That's what I meant by "constrain"/restrain: we can't use API that was added in XP directly. For functions, that is a good thing, because the binary wouldn't work on W2k. For enumeration values and structure definition, it's a bad thing, as we would need to duplicate them if we wanted to call the functions dyanmically that take such values. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 19:50:09 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 29 Dec 2007 18:50:09 -0000 Subject: [issue1699] unconditional definiton of _BSD_SOURCE breaks builds with g++-4.3 Message-ID: <1198954209.75.0.181835805268.issue1699@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I opted for conditionalizing it to OpenBSD; it was wrong on Linux, anyway, as _BSD_SOURCE has a different meaning there. Fixed in r59610 and r59611. ---------- resolution: -> fixed status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 20:53:16 2007 From: report at bugs.python.org (Vlastimil Brom) Date: Sat, 29 Dec 2007 19:53:16 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 Message-ID: <1198957996.69.0.738845169176.issue1688@psf.upfronthosting.co.za> Vlastimil Brom added the comment: First sorry about a delayed response, but moreover, I fear, preparing a patch would be far beyond my programming competence; sorry about that. __________________________________ Tracker __________________________________ From report at bugs.python.org Sat Dec 29 21:36:40 2007 From: report at bugs.python.org (Senthil) Date: Sat, 29 Dec 2007 20:36:40 -0000 Subject: [issue1432] Strange behavior of urlparse.urljoin Message-ID: <1198960600.77.0.592385746641.issue1432@psf.upfronthosting.co.za> Senthil added the comment: If we observe carefully in the urlparse.py and test_urlparse.py, over the releases from Python 2.3 to Python 2.6, the changes required for supporting RFC2396 has been implemented. (RFC2396 replaced 1808 in URL Specification.) But the header of urlparse.py still says it is according to RFC1808 only. *This needs to be changed.* In the test_urlparse.py we find test cases for RFC2396 compliance as well. In this specific bug report, we are upon a case where the later Specification is not compatible with older one. As per RFC1808 Base: Relative URL resolution: ?y = ;x = As per RFC2396 Base: http://a/b/c/d;p?q Relative URLS: ?y = http://a/b/c/?y ;x = http://a/b/c/;x Do you see the difference? urlparse.py has been made RFC2396 compliance, so that above incompatible test has been removed as well. Now, even RFC2396 is obsolete and has been superseded by RFC3986 which advertises thus: Base: http://a/b/c/d;p?q Relative URL: "?y" = "http://a/b/c/d;p?y" ";x" = "http://a/b/c/;x" this is crazy, the first ?y goes for older RFC1808 result and second ;x is in the later RFC2396. For the just this issue my take would be: 1) Make the current urlparse.py compliant with RFC2396. Remove the claim that it is compliant with 1808 only. Which is a documentation fix (patch attached) Overall and the best solution will be RFC3986 compliance, which is a separate effort. Added file: http://bugs.python.org/file9035/urlparse.patch __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: urlparse.patch Type: text/x-diff Size: 1375 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071229/792f2bdd/attachment.patch From report at bugs.python.org Sun Dec 30 11:42:00 2007 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 30 Dec 2007 10:42:00 -0000 Subject: [issue1704] possible bug in randint Message-ID: <1199011320.05.0.620576321587.issue1704@psf.upfronthosting.co.za> Changes by Raymond Hettinger: ---------- resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 15:18:38 2007 From: report at bugs.python.org (umaxx) Date: Sun, 30 Dec 2007 14:18:38 -0000 Subject: [issue1708] improvements for linecache Message-ID: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za> New submission from umaxx: here comes a simple patch for linecache core module, which does the following: - remove double comment - instead of adding all lines with readlines() to the cache, just add seek points for every line - return lines from cached seek-points instead directly from dict-cache advantages of this patch: - reading lines from very big files (>1GB) is no problem anymore - linecache can handle a large number of large files now - updatecache() is faster now because "for line in fp:" is faster than readlines() disadvantages: - reading a single line from cache will be a little bit slower, then before because of extra open() call to the file summary: - this diff presents a different caching approach which is able to handle a lot of large files too __future__-work: - the code is ugly and unstructured, someone needs to beautify it - an extra function: get_list_of_lines_from_list_of_linenumbers() would be nice to have - test-cases for cache-consistence would be nice to have ---------- components: Library (Lib) files: linecache.py.diff messages: 59041 nosy: umaxx severity: minor status: open title: improvements for linecache type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9036/linecache.py.diff __________________________________ Tracker __________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: linecache.py.diff Type: application/octet-stream Size: 1888 bytes Desc: not available Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20071230/461362b8/attachment.obj From report at bugs.python.org Sun Dec 30 15:31:23 2007 From: report at bugs.python.org (umaxx) Date: Sun, 30 Dec 2007 14:31:23 -0000 Subject: [issue1709] logging: log actual function name Message-ID: <1199025083.33.0.488402629269.issue1709@psf.upfronthosting.co.za> New submission from umaxx: logging does not have a (formatter) option for logging the actual function name Logger class detects function name with findCaller() - *but* does not pass it to the makeRecord()-call in _log() - why? would be nice to see this feature implemented, no patch for now :( ---------- components: Library (Lib) messages: 59042 nosy: umaxx severity: minor status: open title: logging: log actual function name type: behavior versions: Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 17:23:04 2007 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 30 Dec 2007 16:23:04 -0000 Subject: [issue1710] Pypi's "score" column is not explained Message-ID: <1199031784.56.0.599845472549.issue1710@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': The meaning of the "score" column shown when a search is done on the pypi database is not clear. Example: http://pypi.python.org/pypi?%3Aaction=search&term=http&submit=search To understand its meaning I had to find this document: http://pycheesecake.org/#algorithm-for-computing-the-cheesecake-index IMHO, it would be better putting a note somewhere in the pypi... something which explains what the "score" value stands for. ---------- messages: 59043 nosy: giampaolo.rodola severity: normal status: open title: Pypi's "score" column is not explained __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 17:27:21 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 30 Dec 2007 16:27:21 -0000 Subject: [issue1702] Word "alias" used in confusing way to compare open() and file() Message-ID: <1199032041.47.0.565068796306.issue1702@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Notice that file *was* open up to Python 2.4; this was changed with #1479181 - so "open" is newer than file, in a sense. Assigning to Neal, who committed the original change. ---------- assignee: -> nnorwitz nosy: +loewis, nnorwitz __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 17:32:48 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sun, 30 Dec 2007 16:32:48 -0000 Subject: [issue1710] Pypi's "score" column is not explained Message-ID: <1199032368.0.0.713704809563.issue1710@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Please report this issue to http://sourceforge.net/projects/pypi This tracker is for Python itself only. ---------- nosy: +loewis resolution: -> invalid status: open -> closed __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 18:52:39 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Dec 2007 17:52:39 -0000 Subject: [issue1702] Word "alias" used in confusing way to compare open() and file() Message-ID: <1199037159.47.0.0105794974517.issue1702@psf.upfronthosting.co.za> Christian Heimes added the comment: open() is preferred over file(), too. In Python 2.5 open() returns a file instance but in 3.0 file is removed. ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 22:30:45 2007 From: report at bugs.python.org (Maarten Thibaut) Date: Sun, 30 Dec 2007 21:30:45 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199050245.75.0.972014457431.issue1711@psf.upfronthosting.co.za> New submission from Maarten Thibaut: Socket library functions such as ntohs() return uint16_t, but inside Python these return values show up as negative numbers. One possible fix is to convert these return values using pack: struct.unpack('H', struct.pack('h', ntohs(number)))[0] & 0xffff ---------- components: Library (Lib) messages: 59047 nosy: mthibaut severity: normal status: open title: socket functions that should return unsigned int return signed int __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 22:35:14 2007 From: report at bugs.python.org (Ori Avtalion) Date: Sun, 30 Dec 2007 21:35:14 -0000 Subject: [issue1712] Small errors in new-style classes doc Message-ID: <1199050514.05.0.343214107383.issue1712@psf.upfronthosting.co.za> New submission from Ori Avtalion: These refer to the "New-style and classic classes" section in Doc/reference/datamodel.rst. 1) The URL should be instead of . 2) The last line: "new-style classic old-style"; seems out of place. Maybe it was once used for indexing, but is pointless now. ---------- components: Documentation messages: 59048 nosy: salty-horse severity: minor status: open title: Small errors in new-style classes doc versions: Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 22:45:53 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Dec 2007 21:45:53 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199051153.04.0.998400558526.issue1711@psf.upfronthosting.co.za> Christian Heimes added the comment: Which number shows up as a negative number on your system? ---------- nosy: +tiran __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 22:46:29 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Dec 2007 21:46:29 -0000 Subject: [issue1712] Small errors in new-style classes doc Message-ID: <1199051189.67.0.160835380016.issue1712@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> georg.brandl nosy: +georg.brandl __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 22:51:45 2007 From: report at bugs.python.org (Maarten Thibaut) Date: Sun, 30 Dec 2007 21:51:45 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199051505.3.0.570194564284.issue1711@psf.upfronthosting.co.za> Maarten Thibaut added the comment: Numbers returned from ntohs() turn up as negative. But ntohs() is typed as uint16_t, so they shouldn't be. This is on solaris. __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 22:53:33 2007 From: report at bugs.python.org (Christian Heimes) Date: Sun, 30 Dec 2007 21:53:33 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199051613.88.0.515634432199.issue1711@psf.upfronthosting.co.za> Christian Heimes added the comment: Please provide an example number __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 23:01:11 2007 From: report at bugs.python.org (Maarten Thibaut) Date: Sun, 30 Dec 2007 22:01:11 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199052071.92.0.687306915506.issue1711@psf.upfronthosting.co.za> Maarten Thibaut added the comment: Try this on Linux and Solaris: ----------------------- from socket import ntohs, htons print ntohs(htons(55000)) ----------------------- On Linux: 55000 On Solaris: -10536 __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 23:19:08 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 30 Dec 2007 22:19:08 -0000 Subject: [issue1580] Use shorter float repr when possible Message-ID: <1199053148.38.0.121861920582.issue1580@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > If someone has a more recent version of MS's compiler, > I'd be interested to know what this does: Visual Studio 2008 Express Edition gives the same results: ['1024', '1024', '1024', '1024', '1024', '1024', '1024.000000000001'] (Tested release and debug builds, with trunk version and py3k branch) ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 23:24:01 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 30 Dec 2007 22:24:01 -0000 Subject: [issue1688] Incorrectly displayed non ascii characters in prompt using "input()" - Python 3.0a2 Message-ID: <1199053441.22.0.397054934659.issue1688@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc: ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Sun Dec 30 23:26:50 2007 From: report at bugs.python.org (Tim Peters) Date: Sun, 30 Dec 2007 22:26:50 -0000 Subject: [issue1580] Use shorter float repr when possible Message-ID: <1199053610.54.0.186363882075.issue1580@psf.upfronthosting.co.za> Tim Peters added the comment: Thanks, Amaury! That settles an issue raised earlier: MS's string<->double routines still don't do correct rounding, and "aren't even close" (the specific incorrect rounding showed here isn't a hard almost-exactly-half-way case). __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 00:11:27 2007 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 30 Dec 2007 23:11:27 -0000 Subject: [issue1711] socket functions that should return unsigned int return signed int Message-ID: <1199056287.92.0.0828101965088.issue1711@psf.upfronthosting.co.za> Changes by Giampaolo Rodola': ---------- nosy: +giampaolo.rodola __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 00:18:27 2007 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 30 Dec 2007 23:18:27 -0000 Subject: [issue1705] trace module does not annotate global statement Message-ID: <1199056707.8.0.482535341871.issue1705@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: But 'global' is a directive to the compiler, and won't generate any bytecode itself. There is no code at this line. ---------- nosy: +amaury.forgeotdarc __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 03:24:03 2007 From: report at bugs.python.org (Carl Drougge) Date: Mon, 31 Dec 2007 02:24:03 -0000 Subject: [issue1713] posixpath.ismount() claims symlink to .. is mountpoint. Message-ID: <1199067842.94.0.942613449084.issue1713@psf.upfronthosting.co.za> Changes by Carl Drougge: ---------- components: Library (Lib) nosy: drougge severity: minor status: open title: posixpath.ismount() claims symlink to .. is mountpoint. type: behavior versions: Python 2.4, Python 2.5 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 03:35:38 2007 From: report at bugs.python.org (Carl Drougge) Date: Mon, 31 Dec 2007 02:35:38 -0000 Subject: [issue1713] posixpath.ismount() claims symlink to a mountpoint is a mountpoint. Message-ID: <1199068538.17.0.165236464711.issue1713@psf.upfronthosting.co.za> New submission from Carl Drougge: Sorry, this happened to me in /tmp, where it's actually true, except I don't expect symlinks to be considered mountpoints, so I still consider it a bug. Should have tested more though. ---------- title: posixpath.ismount() claims symlink to .. is mountpoint. -> posixpath.ismount() claims symlink to a mountpoint is a mountpoint. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 03:37:12 2007 From: report at bugs.python.org (Joseph Armbruster) Date: Mon, 31 Dec 2007 02:37:12 -0000 Subject: [issue1690] Crash on cancellation of windows install Message-ID: <1199068632.17.0.76791371685.issue1690@psf.upfronthosting.co.za> Joseph Armbruster added the comment: This issue has already been reported. http://bugs.python.org/issue1458 ---------- nosy: +JosephArmbruster __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 11:22:30 2007 From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Mon, 31 Dec 2007 10:22:30 -0000 Subject: [issue1455] VS2008, quick hack for distutils.msvccompiler Message-ID: <1199096550.66.0.911951800831.issue1455@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This issue is closed, and didn't really deal with VS 2005 at all, so we should avoid tracking any further changes in it. I personally don't care about the PCbuild8 folder at all. It can be removed, updated, replaced with that script - whatever people like most. You might want to ask Kristjan Jonsson (who created it originally) about its fate. __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 14:11:30 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 31 Dec 2007 13:11:30 -0000 Subject: [issue1458] installer crashes on attempted cancellation Message-ID: <1199106690.95.0.931940256575.issue1458@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- assignee: -> loewis nosy: +loewis priority: -> normal __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 14:11:37 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 31 Dec 2007 13:11:37 -0000 Subject: [issue1690] Crash on cancellation of windows install Message-ID: <1199106697.45.0.717522221199.issue1690@psf.upfronthosting.co.za> Changes by Christian Heimes: ---------- resolution: -> duplicate status: open -> closed superseder: -> installer crashes on attempted cancellation __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 14:26:06 2007 From: report at bugs.python.org (Christian Heimes) Date: Mon, 31 Dec 2007 13:26:06 -0000 Subject: [issue1713] posixpath.ismount() claims symlink to a mountpoint is a mountpoint. Message-ID: <1199107566.25.0.420363359364.issue1713@psf.upfronthosting.co.za> Christian Heimes added the comment: A fix for the problem is easy. One has to replace os.stat() with os.lstat(): def ismount(path): """Test whether a path is a mount point""" try: s1 = os.stat(path) s2 = os.stat(join(path, '..')) except os.error: return False # It doesn't exist -- so not a mount point :-) dev1 = s1.st_dev dev2 = s2.st_dev if dev1 != dev2: return True # path/.. on a different device as path ino1 = s1.st_ino ino2 = s2.st_ino if ino1 == ino2: return True # path/.. is the same i-node as path return False ---------- nosy: +tiran priority: -> low versions: +Python 2.6, Python 3.0 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 16:30:02 2007 From: report at bugs.python.org (Miroslav Suchy) Date: Mon, 31 Dec 2007 15:30:02 -0000 Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space in values. Message-ID: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za> New submission from Miroslav Suchy: I have some configuration params with leading space. And program (getmail4) which use ConfigParser.py. ConfigParser strip all leading (and trailing) spaces from values. This is very often the most wanted result. But if I want value with leading space I have no option to put it there. Therefore I suggest to optionaly write string value as key = "value" This patch will solve it (it is against my OS, sorry no chance to checkout svn). --- /usr/lib/python2.4/ConfigParser.py.orig 2007-12-31 16:04:32.000000000 +0100 +++ /usr/lib/python2.4/ConfigParser.py 2007-12-31 16:06:50.000000000 +0100 @@ -472,6 +472,7 @@ if pos != -1 and optval[pos-1].isspace(): optval = optval[:pos] optval = optval.strip() + optval = optval.strip('"') # allow empty values if optval == '""': optval = '' ---------- components: Extension Modules messages: 59060 nosy: msuchy severity: normal status: open title: ConfigParser.py do not allow leading (and trailing) space in values. type: behavior versions: Python 2.4 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 20:15:17 2007 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 31 Dec 2007 19:15:17 -0000 Subject: [issue1694] floating point number round failures under Linux Message-ID: <1199128517.18.0.407345328139.issue1694@psf.upfronthosting.co.za> Mark Dickinson added the comment: Is there anything in the Python documentation that implies that '%.1f' % 2.25 should be the string '2.3'? I know that the documentation for the builtin round function implies that round(2.25, 1) should be (the closest representable float to) 2.3, but that's a separate issue. As far as I can tell, the float formatting of Python derives its behaviour fairly directly from that of the C library. And the C language specification seems to be pretty much silent on the exact rounding behaviour of the %e, %f and %g conversion specifiers, so it's not clear that either the Linux result or the Windows result is wrong. I'm actually more surprised by the Windows result: I'd expect %f to do round-to-nearest, with halfway results like this one rounded to the string with even last digit. Incidentally, on OS X 10.4.11/Intel, I get the same as on Linux: Python 2.5.1 (r251:54863, Dec 18 2007, 11:48:56) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> print '%.1f' % 2.25 2.2 ---------- nosy: +marketdickinson __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 22:35:40 2007 From: report at bugs.python.org (Tim Peters) Date: Mon, 31 Dec 2007 21:35:40 -0000 Subject: [issue1694] floating point number round failures under Linux Message-ID: <1199136940.09.0.450649160016.issue1694@psf.upfronthosting.co.za> Tim Peters added the comment: Right, Unix-derived C libraries generally do IEEE-754 "round to nearest/even" rounding, while Microsoft's do "add a half and chop" rounding. The Python reference manual says nothing about this, and neither does the C standard (well, C89 doesn't; unsure about C99). Python's round() function is independent of the platform C string<->float conversions, and intentionally does (as documented) "add a half and chop" rounding. ---------- nosy: +tim_one __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 23:19:37 2007 From: report at bugs.python.org (Kurt B. Kaiser) Date: Mon, 31 Dec 2007 22:19:37 -0000 Subject: [issue1692] Syntax Error exception dosen't print string; not informative Message-ID: <1199139577.84.0.015011695714.issue1692@psf.upfronthosting.co.za> Changes by Kurt B. Kaiser: ---------- nosy: +kbk __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 23:30:54 2007 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 31 Dec 2007 22:30:54 -0000 Subject: [issue1694] floating point number round failures under Linux Message-ID: <1199140254.1.0.730542269035.issue1694@psf.upfronthosting.co.za> Mark Dickinson added the comment: It's worth noting that Python's round function doesn't quite work as advertised, either: Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> round(562949953421312.5, 1) 562949953421312.62 __________________________________ Tracker __________________________________ From report at bugs.python.org Mon Dec 31 23:39:36 2007 From: report at bugs.python.org (Mattie) Date: Mon, 31 Dec 2007 22:39:36 -0000 Subject: [issue1507224] sys.path issue if sys.prefix contains a colon Message-ID: <1199140776.06.0.0388455796398.issue1507224@psf.upfronthosting.co.za> Mattie added the comment: This is also proving to be a problem in various places for applications embedding Python 2.5 on Linux. For example, my EventScripts plugin embeds Python into Counter-Strike: Source game servers. It's not uncommon at all for these servers to use a colon in their path names, as rental companies will often assign the directories as myuser/IPADDRESS:PORT/cstrike. For embedding Python we have some tricks that allow us to bypass this sometimes, but it is rather inconvenient. In addition to sys.path, I haven't looked into it deeply, but I believe the codecs search path also seems to get confused when the local directory has a colon somewhere in it. Please consider revitalizing this bug, if possible. Thanks for considering it. ---------- nosy: +Mattie _____________________________________ Tracker _____________________________________ From report at bugs.python.org Mon Dec 31 23:56:53 2007 From: report at bugs.python.org (Tim Peters) Date: Mon, 31 Dec 2007 22:56:53 -0000 Subject: [issue1694] floating point number round failures under Linux Message-ID: <1199141813.19.0.127166448497.issue1694@psf.upfronthosting.co.za> Tim Peters added the comment: Nice example! Yes, the round() implementation is numerically naive, in this particular case ignoring that x+0.5 isn't necessarily representable (it multiplies the input by 10.0, adds 0.5, takes the floor, then divides by 10.0, and in this specific case adding 0.5 loses information to rounding: >>> 5629499534213125 + 0.5 5629499534213126.0 ). __________________________________ Tracker __________________________________