[ python-Bugs-1536059 ] Missing builtin help for with and as
Bugs item #1536059, was opened at 2006-08-07 17:08
Message generated for change (Comment added) made by sgala
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536059&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: Python 2.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Coghlan (ncoghlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing builtin help for with and as
Initial Comment:
The builtin help system has no results for help('with')
and help('as'). This needs to be fixed for 2.6 when the
with statement is available by default. The two new
keywords will also need to be listed under
help('keywords').
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-19 12:26
Message:
Logged In: YES
user_id=178886
patch #1542681 tries to fix it
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536059&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543303 ] tarfile in mode w|gz adds padding that annoys gunzip
Bugs item #1543303, was opened at 2006-08-19 22:48 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=1543303&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 Submitted By: alexis (asak) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile in mode w|gz adds padding that annoys gunzip Initial Comment: In mode w|gz tarfile pads the final block with NULs, until its size reaches the bufsize value passed to tarfile.open. This makes gunzip complain about "invalid compressed data" because of CRC and length errors. To reproduce it, put this fragment in a file archive.py import sys import tarfile tar = tarfile.open(mode='w|gz', fileobj=sys.stdout) tar.close() and then: $ python2.5 archive.py | gunzip -c gunzip: stdin: invalid compressed data--crc error gunzip: stdin: invalid compressed data--length error Everything works fine with python 2.3.5 and 2.4.1 on Debian sarge. The padding is added by the following lines in _Stream.close: blocks, remainder = divmod(len(self.buf), self.bufsize) if remainder > 0: self.buf += NUL * (self.bufsize - remainder) They were added in revision 38581, but I'm not sure why - at first sight, "Add tarfile open mode r|*" shouldn't have to change this write path. Removing them makes gunzip happy again, but I have no idea if it breaks something else (test_tarfile doesn't complain). A similar problem happens if you use mode w|bz2 and feed the output to bunzip - it complains about "trailing garbage after EOF ignored". Problems found while running the test suite from the Mercurial SCM. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543306 ] "from __future__ import foobar; " causes wrong SyntaxError
Bugs item #1543306, was opened at 2006-08-20 04:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&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: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: "from __future__ import foobar;" causes wrong SyntaxError Initial Comment: Instead of "SyntaxError: future feature foobar is not defined", you will get "SyntaxError: from __future__ imports must occur at the beginning of the file", if you use a semicolon at the end of the line (which is valid for existing future-imports of course). Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import foobar; File "", line 1 SyntaxError: from __future__ imports must occur at the beginning of the file >>> from __future__ import generators; >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs
Bugs item #1377858, was opened at 2005-12-10 13:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&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: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Michael Hudson (mwh) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. -- >Comment By: Brett Cannon (bcannon) Date: 2006-08-19 21:31 Message: Logged In: YES user_id=357491 After finally figuring out where *list was made NULL (and adding a comment about it where it occurs), I added a test to test_weakref.py . Didn't try to tackle classic classes. -- Comment By: Armin Rigo (arigo) Date: 2006-08-12 04:31 Message: Logged In: YES user_id=4771 The clear_weakref(*list) only clears the first weakref to the object. You need a while loop in your patch. (attached proposed fix) Now we're left with fixing the same bug in old-style classes (surprize surprize), and turning the crasher into a test. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 10:36 Message: Logged In: YES user_id=357491 So after staring at this crasher it seemed to me to be that clearing the new weakrefs w/o calling their finalizers after calling the object's finalizer was the best solution. I couldn't think of any other good way to communicate to the new weakrefs that the object they refer to was no longer viable memory without doing clear_weakref() work by hand. Attached is a patch to do this. Michael, can you have a look? -- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 11:29 Message: Logged In: YES user_id=1188172 Added to outstanding_crashes.py. -- Comment By: Michael Hudson (mwh) Date: 2006-01-09 03:58 Message: Logged In: YES user_id=6656 Hmm, maybe the referenced mayhem is more to do with clearing __dict__ than calling __del__. What breaks if we do things in this order: 1. call __del__ 2. clear weakrefs 3. clear __dict__ ? -- Comment By: Michael Hudson (mwh) Date: 2006-01-09 03:54 Message: Logged In: YES user_id=6656 Hmm, I was kind of hoping this report would get more attention. The problem is obvious if you read typeobject.c around line 660: the weakref list is cleared before __del__ is called, so any weakrefs added during the execution of __del__ are never informed of the object's death. One fix for this would be to clear the weakref list _after_ calling __del__ but that led to other mayhem in ways I haven't boethered to understand (see SF bug #742911). I guess we could just clear out any weakrefs created in __del__ without calling their callbacks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543347 ] Operator precedence inconsistent for complex literal
Bugs item #1543347, was opened at 2006-08-20 14:59 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=1543347&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: [N/A] (ymasuda) Assigned to: Nobody/Anonymous (nobody) Summary: Operator precedence inconsistent for complex literal Initial Comment: Using complex, real and imag attributes are computed collectly as follows: >>> 1+2j (1+2j) >>> z = 1+2j >>> z.real 1.0 >>> z.imag 2.0 >>> (1+2j).real 1.0 >>> (1+2j).imag 2.0 But, if there's no explicit literal boundary, it seems to break consistensy in operator precedence: >>> 1+2j.real# addition succeeds j-suffux 1.0 >>> 1+2j.imag # addition precedes (j-suffix and) attribute reference 3.0 >>> 0+1+2j.real # same as above 1.0 >>> 0+1+2j.imag 3.0 >>> 1+0+2j.imag 3.0 >>> 1+0+2j.real 1.0 >>> 1+(2j).imag# brace puts no bless 3.0 >>> 1*1+2j.imag # star fails to steer 3.0 This happens at least on Python 2.3.5 (OSX bundled), Python 2.4.2 (build from ports, FreeBSD 5.4). # Practically, of course, you always explicit (1+2j) to construct complex thus hardly troubled with this :) but it would be happy for beginners to mention it on standard tutorial or something. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543347&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
