[ python-Bugs-1681762 ] too long string causes segmentation fault
Bugs item #1681762, was opened at 2007-03-15 23:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&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: None Priority: 5 Private: No Submitted By: L (llukas11) >Assigned to: Martin v. Löwis (loewis) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [EMAIL PROTECTED] 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:30 Message: Logged In: YES user_id=849994 Originator: NO Martin, do you think the Py_ssize_t changes prevent this in Py2.5? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-925537 ] dir(mod) OK or use vars(mod).keys()?
Feature Requests item #925537, was opened at 2004-03-29 19:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&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: Rejected Priority: 4 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: dir(mod) OK or use vars(mod).keys()? Initial Comment: The documentation on dir() notes that its behavior may change across releases. Several library modules use dir(x) in ways that might break if it changed too much. Should these be changed to use vars(obj).keys() (and possibly sort()), or should the note on dir() be removed? My own preference would just be to provide some guidance, such as "The output of dir() will always include all public variables which do not have a magic meaning." I realize that the standard library itself could be updated if dir() changes in an uncomfortable way. My real concern is which spelling to use in my own code. The library examples suggest a simpler (and clearer) dir(), but the documentation still says otherwise. A quick search for modules using dir() showed possible trouble in at least cgitb, cmd, FCNTL, inspect, optparse, os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, tokenize, unittest, and urllib2. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:31 Message: Logged In: YES user_id=849994 Originator: NO Now that we have __dir__(), I think this is "rejected". -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 06:02 Message: Logged In: YES user_id=33168 Originator: NO Has anything happened? Is this still relevant? -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-21 06:05 Message: Logged In: YES user_id=80475 One possible change is in the works. Someone, suggested that dir() starting including the __name__ attribute. -- Comment By: Tim Peters (tim_one) Date: 2004-03-31 00:51 Message: Logged In: YES user_id=31435 Ya, dir() was *intended* to be a convenience for use at the interactive shell. I expect the only promise Guido wants to make about it is that it will show him stuff he finds interesting as Python changes <0.7 wink>. -- Comment By: Martin v. Löwis (loewis) Date: 2004-03-30 21:09 Message: Logged In: YES user_id=21627 Ok, marking it as a feature request then: Explicitly pointing out that behaviour may change in the future has usually been done because change in behaviour is anticipated, or has happened in the past. Giving stronger guarantees about future versions a feature that is currently not provided. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-30 15:28 Message: Logged In: YES user_id=764593 The ideal fix would be in documentation (and therefore policy). I want to do something like import_list = [x for x in dir(other_mod) if wanted(x)] It happens to work today on my machine, but the documentation says that dir(x) may return different results in different releases. This means that I can't safely use it in released code. If there were some indication that dir(module) would continue to return the same names as vars(module).keys(), then I could use it. If the differences were only in variables not intended for export, that would also be OK -- but dir does not current promise this. -- Comment By: Martin v. Löwis (loewis) Date: 2004-03-29 22:11 Message: Logged In: YES user_id=21627 I fail to see a bug. Which specific usage of dir() does not work as intended? -- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 19:58 Message: Logged In: YES user_id=764593 Correction: "The output of dir (module) will always include ..." The most common use is figuring out what to do with (import from) a module. Symmetry suggests the same for a no-argument call or a class or type object, but object instances do not use their __dict__ for their attributes; the results are already different there. -jJ -- Comment By: Jim Jewett (jimjjewett) Date: 2004-03-29 19:39 Message: Logged In: YES user_id=764593 If there concern is over attributes that are "public" but don't exist until called, then mos
[ python-Feature Requests-1670167 ] isinstance.__doc__ is somewhat irritating
Feature Requests item #1670167, was opened at 2007-02-27 17:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1670167&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: René Fleschenberg (refl) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance.__doc__ is somewhat irritating Initial Comment: "With a type as second argument, return whether that is the object's type." That sentence does not really make sense, at least not for new-style classes. After reading that, one could expect that isinstance(1, object) would return False. I think the best thing would be to just drop that sentence from the doc string. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:34 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54409, 54410 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1670167&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1527705 ] optparse should support arbitrary number of arguments
Feature Requests item #1527705, was opened at 2006-07-24 17:33
Message generated for change (Comment added) made by riteshsarraf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&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: Invalid
Priority: 5
Private: No
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Greg Ward (gward)
Summary: optparse should support arbitrary number of arguments
Initial Comment:
Currently, the number of arguments an option
can/should have, needs be defined.
This is done using "nagrs".
parser.add_option("", "--my-option", nargs=3)
The problem is that at times it isn't predictable how
many arguments you'll be receiving.
I request the implementation of this feature in
optparse, where the following could be possible.
parser.add_option("", "--my-option", nargs=*)
Thanks,
Ritesh
--
>Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2007-03-16 14:48
Message:
Logged In: YES
user_id=382018
Originator: YES
Thanks for clarifying Neal.
I've filed a bug with optik, #1681933
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-16 13:17
Message:
Logged In: YES
user_id=33168
Originator: NO
I encourage you to file a feature request with optik if it's important to
you.
While it may not be the nicest way, it's the only way we can get anything
done. I pointed you to optik so you can file the feature request if it's
important to you. What has happened in the past is that this report would
be left open forever. That is worse.
If you think this is wrong, you can fix the problem by helping us resolve
all the issues in python. Otherwise, there's no hope of us managing it.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2007-03-16 13:07
Message:
Logged In: YES
user_id=382018
Originator: YES
I don't think this is the correct way of resolving a bug. You mark it as
"Close" with a resolution "Invalid" when the bug was filed against "Python
Library", of which optparse is one. Python ships optparse as part of its
libraries.
If internally, it is a separate project, you could file one there and link
to it.
But why just plain close it ?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-03-16 12:14
Message:
Logged In: YES
user_id=33168
Originator: NO
Optik is maintained separately. Please file a feature request there:
http://sourceforge.net/projects/optik
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 19:01
Message:
Logged In: YES
user_id=849994
I share effbot's view on that, but leaving to Greg to
decide. In any case, this is a feature request.
--
Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2006-07-24 18:51
Message:
Logged In: YES
user_id=382018
Can you please go through the following link and give your
comments ?
http://groups.google.com/group/comp.lang.python/browse_thre
ad/thread/277522927334b8d8
I feel its a valid feature request.
Ritesh
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-24 18:27
Message:
Logged In: YES
user_id=849994
I don't know of any program that uses command line switches
with a variable number of args, partly because you then
cannot distinguish between option arguments and normal
arguments.
I you still need this, you can implement a custom callback,
I think.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527705&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681974 ] mkdtemp fails on Windows if username has non-ASCII character
Bugs item #1681974, was opened at 2007-03-16 12:03 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=1681974&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Niemist� (niemisto) Assigned to: Nobody/Anonymous (nobody) Summary: mkdtemp fails on Windows if username has non-ASCII character Initial Comment: mkdtemp fails miserably on Windows if Windows user name has any non-ASCII characters, like ä or ö, in it. mkdtemp throws an encoding error. This seems to be because the default temp dir in Windows is "c:\documents and settings\\local settings\temp". Now if the user name has non-ASCII characters ASCII decoder cannot handle it and creating temp directories won't work. As a work around I have used the following code: tempdir = unicode(tempfile.gettempdir(), 'mbcs') mkdtemp(suffix='foo', dir=tempdir) This applies for both Python 2.4 and Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681984 ] unittest documentation is incomplete
Bugs item #1681984, was opened at 2007-03-16 11:17 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=1681984&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 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681762 ] too long string causes segmentation fault
Bugs item #1681762, was opened at 2007-03-16 00:12 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&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: None Priority: 5 Private: No Submitted By: L (llukas11) Assigned to: Martin v. Löwis (loewis) Summary: too long string causes segmentation fault Initial Comment: consider running this on machine with 16GB of ram: line = "x" for i in range(40): line = line + line print len(line) and it's output: 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 134217728 268435456 536870912 1073741824 -2147483648 Segmentation fault [EMAIL PROTECTED] 0.1.x]$ python Python 2.4.4 (#1, Oct 23 2006, 13:58:18) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 I'll can try to chceck if it fails with python 2.5 but I need to compile one. I have stumlbed on this bug when reading line by line 3GB file and forgetting to clear string after I processed data. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-03-16 12:17 Message: Logged In: YES user_id=1326842 Originator: NO This looks like a duplicate of bug #1526585: http://www.python.org/sf/1526585 That bug was fixed in Python 2.5, but it didn't get backported to the 2.4 branch (string_concatenate() in ceval.c is still missing an overflow check). -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:30 Message: Logged In: YES user_id=849994 Originator: NO Martin, do you think the Py_ssize_t changes prevent this in Py2.5? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681674 ] subprocess.Popen fails with socket._fileobject on Windows
Bugs item #1681674, was opened at 2007-03-15 20:32 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&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 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen fails with socket._fileobject on Windows Initial Comment: When using a socket._fileobject as stdin or stdout, subprocess.Popen fails: Traceback (most recent call last): ... File "c:\Python25\lib\subprocess.py", line 586, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "c:\Python25\lib\subprocess.py", line 680, in _get_handles p2cread = msvcrt.get_osfhandle(stdin.fileno()) IOError: [Errno 9] Bad file descriptor Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback. Usage: 1) In one shell start tst_subprocess_socket.py 2) In a second shell start tst_subprocess_socket_client.py 3) On Window, the server will fail and produce the obove traceback. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-03-16 13:31 Message: Logged In: YES user_id=1326842 Originator: NO This is a known limitation of Windows; unlike UNIX like systems, it treats sockets and file descriptors as completely different entities. I don't think there is anything that Python can do to hide this difference. -- Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-15 20:33 Message: Logged In: YES user_id=376953 Originator: YES File Added: tst_subprocess_socket_client.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681674&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-950644 ] Allow any lvalue for function definitions
Feature Requests item #950644, was opened at 2004-05-08 21:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&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: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any lvalue for function definitions Initial Comment: A definition like: def M(x): return 2*x is the same as: M = lambda x: 2*x With the latter form, I can use any lvalue: A[0] = lambda x: 2*x B.f = lambda x: 2*x But with the first form, you're locked into just using a plain variable name. If this were fixed, it wouldn't break anything else but would be useful for making method definitons outside of a class definition: This came up when I was experimenting with David MacQuigg's ideas for prototype OO. I want to write something like: Account = Object.clone() Account.balance = 0 def Account.deposit(self, v): self.balance += v Unfortunately, the latter has to be written: def Account.deposit(self, v): self.balance += v Account.deposit = deposit -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 08:36 Message: Logged In: YES user_id=6380 Originator: NO I don't think so. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 02:04 Message: Logged In: YES user_id=33168 Originator: NO Pinging to check interest. -- Comment By: Guido van Rossum (gvanrossum) Date: 2004-06-28 13:43 Message: Logged In: YES user_id=6380 This is the kind of thing that needs a lot of thought going into it to decide whether it is a net improvement to the language. Right now my gut feeling is that it's not worth the complexity, and more likely to be used towards unnecessary obfuscation. The redability gain is minimal if not negative IMO. Also, I've sometimes typed "def self.foo(args):" instead of "def foo(self, args):" suggesting that there's more than one intuitive way of interpreting the proposed syntax. Another minus point. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-24 13:08 Message: Logged In: YES user_id=80475 Guido, are you open to this? If so, I would be happy to draft a patch. I wouldn't expect it to become mainstream, but it would open the door to working with namespaces more directly. AFAICT, there is no downside to allowing this capability. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-21 01:57 Message: Logged In: YES user_id=80475 I think this should be made possible. It allows for alternate coding styles wihout harming anything else. The Lua programming language has something similar. It is a lightweight, non-OO language that revolves around making the best possible use of namespaces. Direct assignments into a namespace come up in several contexts throughout the language and are key to Lua's flexibility (using one concept to meet all needs). My only concern is that "def" and "class" statements also have the side effect of binding the __name__ attribute. We would have to come up with a lambda style placeholder for the attribute. -- Comment By: Michael Chermside (mcherm) Date: 2004-05-19 20:56 Message: Logged In: YES user_id=99874 I'm highly dubious of this. I see little advantage to doing the definition and storing the value in a single line, mostly because I rarely want to do such a thing. Your example may be convincing in Prothon or some relative, but in Python the sensible way to do it is a normal method. I'd suggest that if you want this idea to go anywhere that you try posting this to c.l.py and seeing if you can drum up interest and support there. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=950644&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681984 ] unittest documentation is incomplete
Bugs item #1681984, was opened at 2007-03-16 10:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&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 Private: No Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 13:02 Message: Logged In: YES user_id=849994 Originator: NO Could you please state what exactly is missing from the documentation, in your opinion? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1666807 ] Incorrect file path reported by inspect.getabsfile()
Bugs item #1666807, was opened at 2007-02-23 08:08 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666807&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fernando P�rez (fer_perez) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect file path reported by inspect.getabsfile() Initial Comment: The following code demonstrates the problem succinctly: ### import inspect,sys print 'Version info:',sys.version_info print f1 = inspect.getabsfile(inspect) f2 = inspect.getabsfile(inspect.iscode) print 'File for `inspect` :',f1 print 'File for `inspect.iscode`:',f2 print 'Do these match?',f1==f2 if f1==f2: print 'OK' else: print 'BUG - this is a bug in this version of Python' ### EOF Running this on my system (Linux, Ubuntu Edgy) with 2.3, 2.4 and 2.5 produces: tlon[bin]> ./python2.3 ~/code/python/inspect_bug.py Version info: (2, 3, 6, 'final', 0) File for `inspect` : /home/fperez/tmp/local/lib/python2.3/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/lib/python2.3/inspect.py Do these match? True OK tlon[bin]> python2.4 ~/code/python/inspect_bug.py Version info: (2, 4, 4, 'candidate', 1) File for `inspect` : /usr/lib/python2.4/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python tlon[bin]> python2.5 ~/code/python/inspect_bug.py Version info: (2, 5, 0, 'final', 0) File for `inspect` : /usr/lib/python2.5/inspect.py File for `inspect.iscode`: /home/fperez/tmp/local/bin/inspect.py Do these match? False BUG - this is a bug in this version of Python ### The problem arises in the fact that inspect relies, for functions (at least), on the func_code.co_filename attribute to contain a complete path. This changed between 2.3 and 2.4, but the inspect module was never updated. This code: ### import inspect,sys print 'Python version info:',sys.version_info print 'File info for `inspect.iscode function`:' print ' ',inspect.iscode.func_code.co_filename print ### EOF shows the problem: tlon[bin]> ./python2.3 ~/code/python/inspect_bug_details.py Python version info: (2, 3, 6, 'final', 0) File info for `inspect.iscode function`: /home/fperez/tmp/local//lib/python2.3/inspect.py tlon[bin]> python2.5 ~/code/python/inspect_bug_details.py Python version info: (2, 5, 0, 'final', 0) File info for `inspect.iscode function`: inspect.py ### (2.4 has the same issue). Basically, if the func_code.co_filename attribute now stores only the final filename without the full path, then the logic in the inspect module needs to be changed to accomodate this so that correct paths are reported to the user like they were in the 2.3 days. -- >Comment By: Žiga Seilnacht (zseil) Date: 2007-03-16 15:06 Message: Logged In: YES user_id=1326842 Originator: NO It looks like this is a bug in Ubuntu build process. The logging package had the same problem: http://www.python.org/sf/1669498 http://www.python.org/sf/1633605 http://www.python.org/sf/1616422 -- Comment By: Fernando P�rez (fer_perez) Date: 2007-03-09 03:00 Message: Logged In: YES user_id=395388 Originator: YES As I mentioned, on hand-built Pythons I don't get the bug at all. So it may be a problem with how Ubuntu builds its Python, since I can reproduce the problem with both 2.4 and 2.5, but only with the default ones provided by Ubuntu Edgy. I don't know enough about their packaging system to know how to retrieve build info. There may be something odd in their build, but it would be nice if this simply couldn't happen at all. If anyone knows how to retrieve the relevant info from an ubuntu build, I'll be happy to try and provide it. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 01:04 Message: Logged In: YES user_id=1344176 Originator: NO I haven't been able to reproduce this with Python 2.3.5, 2.4.4, 2.5.0 or SVN HEAD (all hand-built on Slackware Linux). What options are you providing to ./configure? -- Comment By: Fernando P�rez (fer_perez) Date: 2007-02-24 08:22 Message: Logged In: YES user_id=395388 Originator: YES No, in my case the original tests with 2.4 and 2.5 were done with the Ubuntu-provided (Edgy) versions, unmodified from their apt-get install state. But your comments are interesting. I just rebuilt 2.5 by hand from source on the same system, and this is what I get: tlon[bin]
[ python-Bugs-1531016 ] Comma not allowed at the end of argument list for **argument
Bugs item #1531016, was opened at 2006-07-29 20:21
Message generated for change (Comment added) made by sean_gillespie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&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: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 2
Private: No
Submitted By: Roman Suzi (rnd0110)
Assigned to: Nobody/Anonymous (nobody)
Summary: Comma not allowed at the end of argument list for **argument
Initial Comment:
This tells it all:
>>> str('sdfd', **a,)
File "", line 1
str('sdfd', **a,)
^
SyntaxError: invalid syntax
>>> str('sdfd', *a,)
File "", line 1
str('sdfd', *a,)
^
SyntaxError: invalid syntax
While the docs tell otherwise:
http://docs.python.org/ref/calls.html
While having arguments after ** doesn't make sense,
comma after ANY kinds of arguments seem to be more
consistent.
--
Comment By: Sean Gillespie (sean_gillespie)
Date: 2007-03-16 14:42
Message:
Logged In: YES
user_id=1744567
Originator: NO
This behavior seems as intended. According to the docs
(http://docs.python.org/ref/calls.html):
A trailing comma may be present after the positional and keyword arguments
but does not affect the semantics.
[snip]
Formal parameters using the syntax "*identifier" or "**identifier" cannot
be used as positional argument slots or as keyword argument names.
I'm having trouble with what this actually means. However, the relevant
section in the Grammar looks like this:
arglist: (argument ',')* (argument [',']| '*' test [',' '**' test] | '**'
test )
It looks like this logic was explicitly coded.
If this is determined to be a bug, we can just add [','] after the test in
both cases.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531016&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682205 ] [PATCH] TypeError swallowing in UNPACK_SEQUENCE opcode
Bugs item #1682205, was opened at 2007-03-16 17:22
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=1682205&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Piet Delport (pjdelport)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] TypeError swallowing in UNPACK_SEQUENCE opcode
Initial Comment:
When UNPACK_SEQUENCE unpacks an iterable, it replaces any TypeError raised by
the iterator with a new, catch-all TypeError('unpack non-sequence') instance
(and empty traceback). This message is less useful than the ones it's
(presumably) intended to replace (raised by PyObject_GetIter(), via
unpack_iterable()), and obviously wrong when the TypeError originates in
unrelated user code.
The attached patch simply removes the check, which (as far as i can tell) has
no ill effects.
Examples (without the patch):
>>> a, b, c = 7
TypeError: unpack non-sequence
>>> a, b = ( int(x) for x in ['5', ()] )
TypeError: unpack non-sequence
With the patch applied, these result in:
>>> a, b, c = 7
TypeError: 'int' object is not iterable
>>> a, b = ( int(x) for x in ['5', ()] )
TypeError: int() argument must be a string or a number, not 'tuple'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682205&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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 Private: No Submitted By: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-16 16:41 Message: Logged In: YES user_id=21627 Originator: NO I believe this was fixed some time ago. cconrad, if it still doesn't work for you, please give precise instructions on how to reproduce the problem: what exact Python version are you using (it's supposed to work for 2.4.4 and 2.5.0 atleast), what path did you install Python to what does your demo script look like, where is it installed, and what is the precise error that you get when you run it. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 07:39 Message: Logged In: YES user_id=33168 Originator: NO What's the status of this? Is it a bug report? -- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 12:10 Message: Logged In: YES user_id=21338 (1) (HKCU|HKLM)\Software\Classes\Python.File\open\command really is (HKCU|HKLM)\Software\Classes\Python.File\shell\open\command (2) with python 24 a new behaviour occurs: i try to execute the script on the commandline, but a dialog boy appears with: the file "[...correct complete path to the script...]" could not be found. Again, if i prepend python.exe, everything works as expected. windows 2000 professional. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 10:14 Message: Logged In: YES user_id=1188172 Do you mean that the registry setting is ok, but the parameters are not passed correctly? -- Comment By: Christoph Conrad (cconrad) Date: 2006-02-20 09:12 Message: Logged In: YES user_id=21338 I checked the registry. It's ok. It's windows 2000. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-16 22:29 Message: Logged In: YES user_id=21627 That (arguments not passed to the script) was a bug in some versions of the Windows installer. Please verify that the registry, at (HKCU|HKLM)\Software\Classes\Python.File\open\command has the value '[path]python.exe "%1" %*'. The %* part should arrange for arguments being passed. -- Comment By: Christoph Conrad (cconrad) Date: 2006-01-16 11:59 Message: Logged In: YES user_id=21338 > On windows, you should be able to just invoke the_script.py > (i.e. without a preceding python.exe). Does this not work > for you? It works - but command line args are not given to the called script. If i prepend python.exe, command line args are transferred correctly. -- Comment By: Martin v. Löwis (loewis) Date: 2006-01-14 19:34 Message: Logged In: YES user_id=21627 On windows, you should be able to just invoke the_script.py (i.e. without a preceding python.exe). Does this not work for you? -- Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682241 ] Problems with urllib2 read()
Bugs item #1682241, was opened at 2007-03-16 17:00 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=1682241&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1682403 ] docutils clarification request for "rest"
Bugs item #1682403, was opened at 2007-03-16 19:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&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 Private: No Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: docutils clarification request for "rest" Initial Comment: >From the definition of long_description: *'long string'* Multiple lines of plain text in reStructuredText format (see http://docutils.sf.net/). in: http://docs.python.org/dist/meta-data.html I incorrectly concluded that the the bdist_wininst installer would provide visual markup for long_description specified in restructured text. According to Thomas Heller, that is not the case. I wish to suggest adding this clarification to the distutils documentation perhaps in one or both of the following documents: http://docs.python.org/dist/postinstallation-script.html http://docs.python.org/dist/meta-data.html Thanks, -- jv -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650090 ] doctest doesn't find nested functions
Bugs item #1650090, was opened at 2007-02-01 21:20
Message generated for change (Comment added) made by pjdelport
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Brown (danb37)
Assigned to: Tim Peters (tim_one)
Summary: doctest doesn't find nested functions
Initial Comment:
If a nested function has doctests, they won't be run:
{{{
def f():
'''
>>> 'a'
'a'
'''
def g():
'''
>>> 'a'
'b'
'''
pass
pass
}}}
DocTestFinder will only find f's doctest and won't recurse to find g's,
surprising the programmer when they (hopefully) discover that their inner
doctest is incorrect!
--
Comment By: Piet Delport (pjdelport)
Date: 2007-03-16 22:44
Message:
Logged In: YES
user_id=1607528
Originator: NO
DocTestFinder uses object inspection to find docstrings, which doesn't
really allow this kind of thing: g isn't created until f is actually run.
Making this possible would probably require implementing an alternate
doctest finder based on source code inspection (via the new _ast module?).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1650090 ] doctest doesn't find nested functions
Bugs item #1650090, was opened at 2007-02-01 20:20
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Daniel Brown (danb37)
Assigned to: Tim Peters (tim_one)
Summary: doctest doesn't find nested functions
Initial Comment:
If a nested function has doctests, they won't be run:
{{{
def f():
'''
>>> 'a'
'a'
'''
def g():
'''
>>> 'a'
'b'
'''
pass
pass
}}}
DocTestFinder will only find f's doctest and won't recurse to find g's,
surprising the programmer when they (hopefully) discover that their inner
doctest is incorrect!
--
>Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-17 01:37
Message:
Logged In: YES
user_id=1326842
Originator: NO
Here is a patch that implements this new functionality.
I don't know how desireable this feature is, I just
wanted to see if it could be done.
File Added: doctest_nested_functions.diff
--
Comment By: Piet Delport (pjdelport)
Date: 2007-03-16 21:44
Message:
Logged In: YES
user_id=1607528
Originator: NO
DocTestFinder uses object inspection to find docstrings, which doesn't
really allow this kind of thing: g isn't created until f is actually run.
Making this possible would probably require implementing an alternate
doctest finder based on source code inspection (via the new _ast module?).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1650090&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
