[ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme
Bugs item #745097, was opened at 2003-05-28 19:54
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&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: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 doesn't handle urls without scheme
Initial Comment:
urllib2.urlopen does not handle URLs without a scheme, so the
following code will not work:
url = urllib.pathname2url('/etc/passwd')
urllib2.urlopen(url)
The same code does work with urllib.urlopen.
--
Comment By: John J Lee (jjlee)
Date: 2005-05-22 13:25
Message:
Logged In: YES
user_id=261020
That sounds like a feature request to me, not a bug.
I agree it's desirable to have a better pathname2url (I haven't
submitted one partly because I'm scared of getting it wrong!).
I disagree that it should be a method, since OpenerDirector has
no knowledge of base URL (and urllib2.Request or the response
class also seem like the wrong places for that method: the URLs
they have aren't always the URL you want to use as the base
URL). It would be nice to have a couple of functions
urlparse.urlfrompathname(pathname) and
urlparse.absurlfrompathname(pathname, baseurl) (better
names / places for those, anyone?).
Or you could resubmit this as a bug in urllib for allowing relative
URLs without knowing the base URL ;-)
--
Comment By: Jack Jansen (jackjansen)
Date: 2005-05-20 00:53
Message:
Logged In: YES
user_id=45365
I'm not convinced it isn't a bug. I agree that the URL '/etc/passwd' isn't
always a file: url, but I think that in that case urllib2 should get its own
pathname2url() method that returns urls with the file: prefix.
--
Comment By: John J Lee (jjlee)
Date: 2005-05-19 21:24
Message:
Logged In: YES
user_id=261020
Could somebody close this?
--
Comment By: John J Lee (jjlee)
Date: 2003-11-30 23:24
Message:
Logged In: YES
user_id=261020
Is it wise to allow this? Maybe it's unlikely to cause bugs, but
"/etc/passwd" could refer to any URI scheme, not only file:.
Since it seems reasonable to only allow absolute URLs, I think
it's a bad idea to guess the scheme is file: when given a
relative URL.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1206537 ] weakref cannot handle bound methods (in contrast to docu)
Bugs item #1206537, was opened at 2005-05-22 14:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raik Gruenberg (graik) Assigned to: Nobody/Anonymous (nobody) Summary: weakref cannot handle bound methods (in contrast to docu) Initial Comment: According to the documentation of the weakref module, weakreferences can be applied to "...class instances, functions written in Python (but not in C), methods (both bound and unbound)..." In reality, bound methods cannot be referenced (see bug 813299): import weakref ## this works: def testF( event ):pass r = weakref.ref( testF ) ## this doesnt: class EventListener: def handleEventA( self, event ): pass t = EventListener() ## gives a "dead" ref r = weakref.ref( t.handleEventA ) This behaviour is unexpected for anyone not aquainted to the inner clockwork of python and unfortunate because it, for example, prevents to keep weak references to callback methods in event handling patterns. A workaround is proposed at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253 Discussion: (minimal) Solution 1: Change the weakref documentation (preferred) Solution 2: Adapt weakref to allow references to bound methods Perhaps this bug should be converted into a documentation bug and a feature request. Python version 2.3 and 2.4 OS: Linux 2.6 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1070735 ] urllib2 authentication redirection error(?)
Bugs item #1070735, was opened at 2004-11-21 18:01 Message generated for change (Comment added) made by allanbwilson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&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: None Priority: 5 Submitted By: Allan B. Wilson (allanbwilson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 authentication redirection error(?) Initial Comment: I am trying to use urllib2 to retrieve a page from a site requiring authentication. I supply the authentication parameters, which succeed, and *a* page is returned -- but not the page I originally requested. As it turns out, the authentication is handled at a completely different URL (actually a different domain); I can confirm this by not supplying authentication data, because I see a 302 earlier in the traceback when authentication fails. What I think is happening is that the redirect happens to the authentication site, but the original URL that I wanted has been forgotten. The page I get back is the default page for the original (now authenticated) site, not the page itself, which is deeper down in the site hierarchy. Sorry, I can't supply a patch! Thanks -- >Comment By: Allan B. Wilson (allanbwilson) Date: 2005-05-22 11:39 Message: Logged In: YES user_id=725330 Yes, that makes sense. Unfortunately the site is a financial site so I won't be able to supply a demo script. Let's do close it out on that basis. Thanks -- Comment By: John J Lee (jjlee) Date: 2005-05-19 12:48 Message: Logged In: YES user_id=261020 Allan, unfortunately there's no way of investigating this without a running script that demonstrates the problem. Please supply one, or close the bug. Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1070735&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-944890 ] csv writer bug on windows
Bugs item #944890, was opened at 2004-04-29 16:06
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944890&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: Brian Kelley (wc2so1)
Assigned to: Skip Montanaro (montanaro)
Summary: csv writer bug on windows
Initial Comment:
The excel dialect is set up to be
class excel(Dialect):
delimiter = ','
quotechar = '"'
doublequote = True
skipinitialspace = False
lineterminator = '\r\n'
quoting = QUOTE_MINIMAL
register_dialect("excel", excel)
However, on the windows platform, the lineterminator
should be simply "\n"
My suggested fix is:
class excel(Dialect):
delimiter = ','
quotechar = '"'
doublequote = True
skipinitialspace = False
if sys.platform == "win32":
lineterminator = '\n'
else:
lineterminator = '\r\n'
quoting = QUOTE_MINIMAL
Which seems to work. It could be that I'm missing
something, but the universal readlines doesn't appear
to work for writing files. If this is a usage issue,
it probably should be a documentation fix.
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-05-22 20:32
Message:
Logged In: YES
user_id=44345
This should have been closed long ago. The documentation
states that files need to be opened in binary mode.
--
Comment By: Brian Kelley (wc2so1)
Date: 2004-06-05 15:22
Message:
Logged In: YES
user_id=424987
The example in the documentation fails...
import csv
writer = csv.writer(file("some.csv", "w"))
for row in someiterable:
writer.writerow(row)
As I suspected, the fix is a documentation issue. I will
make a documentation patch next week. It will be my first
one :)
--
Comment By: Tim Peters (tim_one)
Date: 2004-06-05 11:14
Message:
Logged In: YES
user_id=31435
Excel on Windows puts \r\n line ends in .csv files it creates (I
just tried it). Since the OP mentioned "universal readlines", I
bet he's opening the file with "U" (but it needs to be "rb").
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-06-05 11:04
Message:
Logged In: YES
user_id=44345
Can you attach an example that fails? I don't have access
to Windows. Note that you must open the file with binary
mode ("wb" or "rb").
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944890&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-813198 ] Migrate PEP material to docs
Bugs item #813198, was opened at 2003-09-26 12:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813198&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Nobody/Anonymous (nobody) Summary: Migrate PEP material to docs Initial Comment: Much of the basic information is still missing. MRO, descriptors, most of PEPs 252 and 253 are ones I can think of off the top of my head, but I'm certain there's more. -- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:35 Message: Logged In: YES user_id=44345 I'm passing this back for someone to take who's better versed in PEPs 252 and 253. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813198&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-731501 ] Importing anydbm generates exception if _bsddb unavailable
Bugs item #731501, was opened at 2003-05-02 12:56 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=731501&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: Accepted Priority: 5 Submitted By: Nick Vargish (vargish) Assigned to: Skip Montanaro (montanaro) Summary: Importing anydbm generates exception if _bsddb unavailable Initial Comment: The anydbm module attempts to import the dbhash module, which fails if there is no BSD DB module available. Relevant portion of backtrace: File "/diska/netsite-docs/cgi-bin/waisdb2.py", line 124, in _getsystemsdbm dbsrc = anydbm.open(self.dbfile) File "/usr/local/python-2.3b1/lib/python2.3/anydbm.py", line 82, in open mod = __import__(result) File "/usr/local/python-2.3b1/lib/python2.3/dbhash.py", line 5, in ? import bsddb File "/usr/local/python-2.3b1/lib/python2.3/bsddb/__init__.py", line 40, in ? import _bsddb ImportError: No module named _bsddb Tests that explicitly use "import dbm" rather than anydbm are successful on this system. -- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:38 Message: Logged In: YES user_id=44345 ancient history i just never closed -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-06-24 01:09 Message: Logged In: YES user_id=3066 The doc changes look mostly fine to me (and I've changed what didn't; a small cosmetic nit). I'm just amazed we're still spending time tweaking BSD DB; I don't think that's ever "just worked" for me without digging around for a version of the underlying library that worked with Python. -- Comment By: Skip Montanaro (montanaro) Date: 2003-05-06 15:54 Message: Logged In: YES user_id=44345 Assigned to Fred for doc review - I added a couple notes to libbsddb.tex and libundoc.tex in lieu of actually creating a separate bsddb185 section which I felt would have given people the mistaken idea that the module is available for general use. Still, I thought there should be some mention in the docs. Library detection probably needs a little tweakage as well. -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 16:55 Message: Logged In: YES user_id=21627 Actually, you probably need to check whether /usr/lib/libdb.* is present, and link with that as well if it is. If you are uncertain whether this is the right library, I see no way except to run a test program, at configure time, that creates a database and determines whether this really is a DB 1.85 database. Alternatively, the test program might try to invoke db_version. If the function is available, it is DB x, x>=2 (DB1 apparently has no version indication function). -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-05 15:34 Message: Logged In: YES user_id=21627 I can't actually test the patch, but it looks good to me. Please apply! -- Comment By: Skip Montanaro (montanaro) Date: 2003-05-05 09:27 Message: Logged In: YES user_id=44345 I believe the attached patch does what's necessary to get this to work again. It does a few things: * setup.py builds the bsddb185 under the right (restrictive) circumstances. /usr/include/db.h must exist and HASHVERSION must be 2. In this case the bsddb185 module will be built without any extra includes, libraries or #defines, forcing whatever is present in /usr/include/db.h and libc to be used to build the module. * whichdb.py detects the older hash file format and returns "bsddb185". * bsddbmodule.c grows an extra undocumented attribute, "open". The last two changes avoid having to change dbhash.py in complicated ways to distinguish between new and old file versions. The format- detecting mess remains isolated to whichdb.py. Using this setup I was successfully able to open /etc/pwd.db on my system using anydbm.open(), which I was unable to do previously. I can also still open a more recent hash file created with anydbm.open. Finally, new files created with anydbm.open are in the later format. Please give it a try. -- Comment By: Martin v. Löwis (loewis) Date: 2003-05-03 04:02 Message: Logged In: YES user_id=21627 I think this is not a bug. open() has determined that this is a bsddb file, but bsddb is not supported on the system. Or did you mean to suggest
[ python-Bugs-1082487 ] font lock keyword regular expressions
Bugs item #1082487, was opened at 2004-12-09 15:43 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&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: Open Resolution: Fixed Priority: 5 Submitted By: Robert Brown (robert-brown) >Assigned to: Raymond Hettinger (rhettinger) Summary: font lock keyword regular expressions Initial Comment: I've noticed that when I use Python mode (alpha 1) with font lock mode, "self" is highlighted in the following line: his_self() The problem appears to be a combination of using "\b" in the Python font lock regular expressions and my .emacs file, which does: (modify-syntax-entry ?\_ "_" py-mode-syntax-table) I do not experience similar problems with highlighting in C mode, but there "\<" and "\>" are used in the font lock regular expressions. Using these word delimiters instead of "\b" appears to fix the problem for me in Python mode. Please wrap keywords with "\<" and "\>" instead of with "\b" in the font lock regular expression. Thanks very much. Bob -- >Comment By: Skip Montanaro (montanaro) Date: 2005-05-22 20:41 Message: Logged In: YES user_id=44345 Passing along to Raymond. If it works for you, please close. If not, pass it back to me. -- Comment By: Skip Montanaro (montanaro) Date: 2005-05-19 21:45 Message: Logged In: YES user_id=44345 python-mode.el 4.71. Raymond, sorry for taking so long with this. Please give it a try and let me know how it works. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 21:36 Message: Logged In: YES user_id=80475 Skip, can you field this one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1082487&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-768068 ] Explicit interp reference during build fails
Bugs item #768068, was opened at 2003-07-08 16:44
Message generated for change (Settings changed) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&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: Build
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Explicit interp reference during build fails
Initial Comment:
I think this is MacPython-specific and not just a general
Python build issue. If I explicitly reference the Python
executable when building an out-of-tree extension module I
get an error building the .so file because it stripped the
dirname() of the python.exe file.
Here's a simple example. I have a directory with a single
extension module and simple setup.py. I want to build it
with
~/src/python/head/dist/src/build.pg/python.exe
Compilation works fine. Linkage bombs.
% pwd
/Users/skip/src/PyExtensions1.5/python2.2
montanaro:python2.2% ls -l
total 8
-rw-r--r--1 skip staff1318 Jan 21 2002
llopmodule.c
-rw-rw-r--1 skip staff 114 Jan 21 2002
setup.py
montanaro:python2.2% cat setup.py
from distutils.core import setup, Extension
setup(name="llop", ext_modules=[Extension("llop",
["llopmodule.c"])])
montanaro:python2.2% ~/src/python/head/dist/src/
build.pg/python.exe setup.py build
running build
running build_ext
building 'llop' extension
creating build
creating build/temp.darwin-6.6-Power_Macintosh-2.3
gcc -pg -fno-strict-aliasing -Wno-long-double -no-cpp-
precomp -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/
Users/skip/src/python/head/dist/src/Include -I/Users/skip/
src/python/head/dist/src/build.pg -c llopmodule.c -o build/
temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o
creating build/lib.darwin-6.6-Power_Macintosh-2.3
gcc -pg -bundle -bundle_loader python.exe build/
temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o -o
build/lib.darwin-6.6-Power_Macintosh-2.3/llop.so
ld: can't open: python.exe (No such file or directory,
errno = 2)
error: command 'gcc' failed with exit status 1
--
Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 09:53
Message:
Logged In: YES
user_id=45365
Skip,
I think this problem has gone away as a side-effect of the new way to
create extension modules, at least if you make sure you have
MACOSX_TARGET_PLATFORM=10.3 in your environment when configuring
and building python.
Could you try, please, and close the report if this appears to work for
you? Otherwise please reassign back to me.
--
Comment By: Jack Jansen (jackjansen)
Date: 2003-07-21 16:00
Message:
Logged In: YES
user_id=45365
This won't be fixed for 2.3, after discussion on python-dev it
seems the situation is not so common, so it can wait for 2.3.1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump)
Bugs item #1201456, was opened at 2005-05-13 08:43
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&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: Wont Fix
Priority: 5
Submitted By: Vladimir Yu. Stepanov (vys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with recursion in dict (crash with core dump)
Initial Comment:
Please see example code.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-22 21:29
Message:
Logged In: YES
user_id=341410
If your system has sufficient stack space (and/or a
reasonably sane malloc), a recursion limit of 1000 should be
fine. My windows systems print tracebacks properly for up
to a recursion limit of around 5750 levels (after which I
get MemoryErrors with tracebacks, not cores).
Place a sys.setrecursionlimit() call in your site.py.
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-18 06:05
Message:
Logged In: YES
user_id=384980
sys.getrecursionlimit() returns 1000.
I set sys.setrecursionlimit() to 500 and problem was resolved :)
Thank you very much !
PS. Is it possible to add some checks in Py_SetRecursionLimit
to reject overflow values ?
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-18 05:15
Message:
Logged In: YES
user_id=1038590
What does sys.getrecursionlimit() return?
Does the buggy code generate the expected exception if you
use sys.setrecursionlimit() to make the value smaller (e.g.
500)?
FreeBSD has a history of not playing well with CPython's
ability to detect inifinite recursion. . .
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-13 09:06
Message:
Logged In: YES
user_id=384980
This is output from `uname -a`:
FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE
#1: Fri Apr 15 10:38:49 MSD 2005
[EMAIL PROTECTED]:/M/safedir/src/sys/i386/compile/FOX i386
I get some others with this code:
Python 2.4.1 (#2, Apr 26 2005, 14:16:31)
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> d = {}
>>>
>>> class test:
... def __hash__(self):
... d[self] = None
...
>>> d[test()] = None
Bus error (core dumped)
fox:vys!~ > gdb python python.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no
debugging symbols found)...
Core was generated by `python'.
Program terminated with signal 10, Bus error.
(gdb) where
#0 0x2828b3b1 in ldexp () from /lib/libc.so.5
#1 0x2828b618 in malloc () from /lib/libc.so.5
#2 0x080bdca1 in _PyObject_GC_Malloc ()
#3 0x080bdd4a in _PyObject_GC_New ()
#4 0x0805f556 in PyMethod_New ()
#5 0x0805c1a6 in PyInstance_NewRaw ()
#6 0x0805c66a in PyInstance_New ()
#7 0x0805cca1 in _PyInstance_Lookup ()
#8 0x080703e6 in PyDict_SetItem ()
#9 0x0809bb0e in PyEval_EvalFrame ()
#10 0x0809fc20 in PyEval_EvalCodeEx ()
#11 0x080d4d66 in PyFunction_SetClosure ()
#12 0x0805a38c in PyObject_Call ()
#13 0x0805fbe2 in PyMethod_New ()
#14 0x0805a38c in PyObject_Call ()
#15 0x08099f1b in PyEval_CallObjectWithKeywords ()
#16 0x0805ccb9 in _PyInstance_Lookup ()
#17 0x080703e6 in PyDict_SetItem ()
#18 0x0809bb0e in PyEval_EvalFrame ()
#19 0x0809fc20 in PyEval_EvalCodeEx ()
#20 0x080d4d66 in PyFunction_SetClosure ()
#21 0x0805a38c in PyObject_Call ()
#22 0x0805fbe2 in PyMethod_New ()
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-13 08:55
Message:
Logged In: YES
user_id=80475
I get the expected behavior:
RuntimeError: maximum recursion depth exceeded
--
Comment By: Michael Hudson (mwh)
Date: 2005-05-13 08:55
Message:
Logged In: YES
user_id=6656
I get an infinite recursion runtime error. What platform
are you on?
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-13 08:46
Message:
Logged In: YES
user_id=384980
d = {}
class test:
def __hash__(self):
[ python-Bugs-1201456 ] Problem with recursion in dict (crash with core dump)
Bugs item #1201456, was opened at 2005-05-13 10:43
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1201456&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: Wont Fix
Priority: 5
Submitted By: Vladimir Yu. Stepanov (vys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with recursion in dict (crash with core dump)
Initial Comment:
Please see example code.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-22 23:46
Message:
Logged In: YES
user_id=80475
FWIW, the OP's original situation may have tickled a
genuine bug where one of the recursed into routines makes a
malloc request but fails to check for, report, or gracefully
exit from a memory error.
His gdb trace may show the way, but I didn't see the bug.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-22 23:29
Message:
Logged In: YES
user_id=341410
If your system has sufficient stack space (and/or a
reasonably sane malloc), a recursion limit of 1000 should be
fine. My windows systems print tracebacks properly for up
to a recursion limit of around 5750 levels (after which I
get MemoryErrors with tracebacks, not cores).
Place a sys.setrecursionlimit() call in your site.py.
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-18 08:05
Message:
Logged In: YES
user_id=384980
sys.getrecursionlimit() returns 1000.
I set sys.setrecursionlimit() to 500 and problem was resolved :)
Thank you very much !
PS. Is it possible to add some checks in Py_SetRecursionLimit
to reject overflow values ?
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2005-05-18 07:15
Message:
Logged In: YES
user_id=1038590
What does sys.getrecursionlimit() return?
Does the buggy code generate the expected exception if you
use sys.setrecursionlimit() to make the value smaller (e.g.
500)?
FreeBSD has a history of not playing well with CPython's
ability to detect inifinite recursion. . .
--
Comment By: Vladimir Yu. Stepanov (vys)
Date: 2005-05-13 11:06
Message:
Logged In: YES
user_id=384980
This is output from `uname -a`:
FreeBSD fox.renet.ru 5.3-RELEASE FreeBSD 5.3-RELEASE
#1: Fri Apr 15 10:38:49 MSD 2005
[EMAIL PROTECTED]:/M/safedir/src/sys/i386/compile/FOX i386
I get some others with this code:
Python 2.4.1 (#2, Apr 26 2005, 14:16:31)
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>> d = {}
>>>
>>> class test:
... def __hash__(self):
... d[self] = None
...
>>> d[test()] = None
Bus error (core dumped)
fox:vys!~ > gdb python python.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no
debugging symbols found)...
Core was generated by `python'.
Program terminated with signal 10, Bus error.
(gdb) where
#0 0x2828b3b1 in ldexp () from /lib/libc.so.5
#1 0x2828b618 in malloc () from /lib/libc.so.5
#2 0x080bdca1 in _PyObject_GC_Malloc ()
#3 0x080bdd4a in _PyObject_GC_New ()
#4 0x0805f556 in PyMethod_New ()
#5 0x0805c1a6 in PyInstance_NewRaw ()
#6 0x0805c66a in PyInstance_New ()
#7 0x0805cca1 in _PyInstance_Lookup ()
#8 0x080703e6 in PyDict_SetItem ()
#9 0x0809bb0e in PyEval_EvalFrame ()
#10 0x0809fc20 in PyEval_EvalCodeEx ()
#11 0x080d4d66 in PyFunction_SetClosure ()
#12 0x0805a38c in PyObject_Call ()
#13 0x0805fbe2 in PyMethod_New ()
#14 0x0805a38c in PyObject_Call ()
#15 0x08099f1b in PyEval_CallObjectWithKeywords ()
#16 0x0805ccb9 in _PyInstance_Lookup ()
#17 0x080703e6 in PyDict_SetItem ()
#18 0x0809bb0e in PyEval_EvalFrame ()
#19 0x0809fc20 in PyEval_EvalCodeEx ()
#20 0x080d4d66 in PyFunction_SetClosure ()
#21 0x0805a38c in PyObject_Call ()
#22 0x0805fbe2 in PyMethod_New ()
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-05-13 10:55
Message:
Logged In: YES
user_id=80475
I get the expected behavior:
RuntimeError: maximum recursion depth exceeded
---
[ python-Bugs-1206537 ] weakref cannot handle bound methods (in contrast to docu)
Bugs item #1206537, was opened at 2005-05-22 09:37 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raik Gruenberg (graik) >Assigned to: Raymond Hettinger (rhettinger) Summary: weakref cannot handle bound methods (in contrast to docu) Initial Comment: According to the documentation of the weakref module, weakreferences can be applied to "...class instances, functions written in Python (but not in C), methods (both bound and unbound)..." In reality, bound methods cannot be referenced (see bug 813299): import weakref ## this works: def testF( event ):pass r = weakref.ref( testF ) ## this doesnt: class EventListener: def handleEventA( self, event ): pass t = EventListener() ## gives a "dead" ref r = weakref.ref( t.handleEventA ) This behaviour is unexpected for anyone not aquainted to the inner clockwork of python and unfortunate because it, for example, prevents to keep weak references to callback methods in event handling patterns. A workaround is proposed at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81253 Discussion: (minimal) Solution 1: Change the weakref documentation (preferred) Solution 2: Adapt weakref to allow references to bound methods Perhaps this bug should be converted into a documentation bug and a feature request. Python version 2.3 and 2.4 OS: Linux 2.6 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1206537&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars
Bugs item #1193180, was opened at 2005-05-01 01:13
Message generated for change (Comment added) made by grubert
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniele Varrazzo (dvarrazzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange os.path.exists() results with invalid chars
Initial Comment:
Hi,
when there are invalid chars in a filename, os.path.exists
() behaves oddly, returning True.
The bug appears on win32 system, not on unix ones.
Thus is probably related to some weird windows api call
and doesn't maybe worth fixing.
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import os
>>> f = file("a_b", "w")
>>> f.close()
>>> os.listdir(".")
['a_b']
>>> os.path.exists("a>> os.path.exists("a>b")
True
And, even more strange...
>>> os.path.exists("a<")
True
>>> os.path.exists("a>")
False
Better answers would have been:
* False
* raise ValueError
--
Comment By: engelbert gruber (grubert)
Date: 2005-05-23 08:52
Message:
Logged In: YES
user_id=147070
testing with perl: print -e "a<"; returns True/1 too
--
Comment By: Jarek Zgoda (zgoda)
Date: 2005-05-02 14:04
Message:
Logged In: YES
user_id=9
Same for Python 2.3.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
