[ python-Bugs-1353504 ] Python drops core when stdin is bogus
Bugs item #1353504, was opened at 2005-11-10 22:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1353504group_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: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 stdin, item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, stdin, r, NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-18 08:22 Message: Logged In: YES user_id=849994 Closing then. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-09 06:03 Message: Logged In: YES user_id=33168 I just changed this to print an error message and exit in 2.5. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 00:16 Message: Logged In: YES user_id=33168 Ok, I understand that part. But if you can't accept input from the user, what can you do? If all you are suggesting is to change Py_FatalError() to raising a SystemError and still exiting, I'm fine with that if it can work. I agree this would probably be nicer too. Or am I still missing your point? Do you want to work on a patch? I'm fine with any improvement, I'm just not sure how much can be done. If you want to improve the error message, that would be good too. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 23:57 Message: Logged In: YES user_id=44345 No, we're still discussing stdin. My only point is that what you do might be predicated on whether or not you think you can communicate with the user on stderr. My thought was that if stderr is valid you can raise an exception that prints a traceback. If not, Py_FatalError is your only recourse. Your code checks for the directori-ness of stdin as the first thing, then bails if it is. If it checked to see if stderr was valid first, it could decide to raise SystemError instead of calling Py_FatalError. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 22:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. -- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 22:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError.
[ python-Bugs-1416477 ] Inconsistency between StringIO and cStringIO
Bugs item #1416477, was opened at 2006-01-27 14:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1416477group_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: Python 2.4 Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Michael Kerrin (mkerrin) Assigned to: Raymond Hettinger (rhettinger) Summary: Inconsistency between StringIO and cStringIO Initial Comment: The readline method for StringIO defalt argument for the size arguement is None while for all other file-like objects it is -1. So if we pass in -1 to the StringIO readline method, all lines are returned, again inconsistent with the other file-like objects, and if we pass in None to any other file-like object we get a TypeError, int required. The attached python script is a very simple example of what I mean. Note that this is causing me a lot of grief in trying to get tests to pass for a simple fix to an open source project. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-18 08:24 Message: Logged In: YES user_id=849994 Closing then. -- Comment By: Kent Hsu (cphsu) Date: 2006-03-06 05:16 Message: Logged In: YES user_id=1468643 Sorry, it seems the bug has been fixed in 2.4. import cStringIO as c sio = c.StringIO() sio.write(a) sio.truncate(0) print sio.getvalue() sio.write(b) print sio.getvalue() ab which I get in StringIO module is b. -- Comment By: Kent Hsu (cphsu) Date: 2006-03-06 05:04 Message: Logged In: YES user_id=1468643 BTW, another inconsistency between StringIO and cStringIO :-) import cStringIO as c sio = c.StringIO() sio.write(a) sio.truncate(0) print sio.getvalue() sio.write(b) print sio.getvalue() ab which I get in StringIO module is b. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1416477group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Bugs item #1427552, was opened at 2006-02-08 14:13 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1427552group_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: Pending Resolution: None Priority: 7 Submitted By: Chris86 (chris86) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.open bug / corrupt data Initial Comment: Hi! I want to create a bz2 compressed tar file. Here is my code: full=/home/test/test.sql tar = tarfile.open(test.tar.bz2, w:bz2) tarinfo = tar.gettarinfo(full,blubb.sql) tar.addfile(tarinfo,file(full)) tar.close() i think this should work, but the sql file is corrupt: - the created sql file in the compressed tar has only 4745 Lines, the original file has 4753 Regards, Chris -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-12 06:21 Message: Logged In: YES user_id=33168 Chris can you attach your sql file (or a small test case) so we can reproduce the problem? -- Comment By: Lars Gustäbel (gustaebel) Date: 2006-02-08 15:13 Message: Logged In: YES user_id=642936 Just to identify whether this is a tarfile or bz2 module related issue: - Do you have the same problem without compression or with gzip compression? - Have you tried compressing your sql file directly with the bz2 module? -- Comment By: Chris86 (chris86) Date: 2006-02-08 14:17 Message: Logged In: YES user_id=1133569 same error with Python 2.3.5 (#2, Aug 30 2005, 15:50:26) [GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2 -- Comment By: Chris86 (chris86) Date: 2006-02-08 14:15 Message: Logged In: YES user_id=1133569 I'm using Python 2.4.2 (#2, Nov 20 2005, 17:04:48) [GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on linux2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1427552group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432838 ] optparse docs double-dash confusion
Bugs item #1432838, was opened at 2006-02-16 12:28
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1432838group_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
Submitted By: John Veness (pelago)
Assigned to: Greg Ward (gward)
Summary: optparse docs double-dash confusion
Initial Comment:
Page
http://docs.python.org/lib/optparse-terminology.html says:
The GNU project introduced - followed by a series of
hyphen-separated words, e.g. -file or -dry-run.
but should say:
The GNU project introduced -- followed by a series of
hyphen-separated words, e.g. --file or --dry-run.
Also at the bottom of that page:
-v and -report are both options.
should be:
-v and --report are both options.
It looks in general that there is a documentation
rendering problem when double-dash appears in quotes.
Other double-dash items on that page are ok, when not
in quotes.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:26
Message:
Logged In: YES
user_id=849994
Now fixed in SVN.
--
Comment By: splitscreen (splitscreen)
Date: 2006-02-18 11:24
Message:
Logged In: YES
user_id=1126061
Yeah, that's all that the patch that I provided does.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 09:05
Message:
Logged In: YES
user_id=1188172
A suggested fix is to replace -{}- by {--} for long
options. Greg?
--
Comment By: splitscreen (splitscreen)
Date: 2006-02-16 20:59
Message:
Logged In: YES
user_id=1126061
Patch provided: #1433148
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1432838group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448042 ] Defining a class with __dict__ brakes attributes assignment
Bugs item #1448042, was opened at 2006-03-11 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1448042group_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: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment
Initial Comment:
When defining a class with __dict__ attribute, its
instances can't rebind their __dict__ attributes.
--
class C(object): __dict__ = {}
obj = C()
obj.a = object()
import gc
gc.get_referrers(obj.a) # = [{'a': object object at
0x811d5b0}]
obj.__dict__ = {} # doesn't really bind new __dict__
vars(obj) # = {}
object.__getattribute__(obj, '__dict__') # = {}
object.__getattribute__(C, '__dict__') # = {..., but
without a}
obj.a # = object object at 0x811d5b0 (no exception
!)
gc.get_referrers(obj.a) # = [{'a': object object at
0x811d5b0, '__dict__': {}}]
--
Although neither class nor object has an attribute a,
it's still accessible. It's also not possible to rebind
__dict__ in that object, as it gets inside real object
attributes dictionary.
This behaviour has been tested on Python 2.2, 2.3 and
2.4, but may as well affect earlier versions.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:29
Message:
Logged In: YES
user_id=849994
Agreed with Terry.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 03:21
Message:
Logged In: YES
user_id=593130
To me, this falls under the category of 'don't do that'.
http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers
__*__
System-defined names. These names are defined by the
interpreter and its implementation ...
To me, this means to use them in the manner specified or
you get what you get.
http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'. There is, as
far as I know, no specified usage for rebinding '__dict__'.
So unless someone has a better idea that won't slow down
proper usage, I would close this as 'invalid' or 'wont
fix'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1448042group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1437699 ] allow unicode arguments for robotparser.can_fetch
Feature Requests item #1437699, was opened at 2006-02-23 21:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=355470aid=1437699group_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: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: allow unicode arguments for robotparser.can_fetch
Initial Comment:
One-line summary: If the robotparser module encounters
a robots.txt file that contains non-ASCII characters
AND I pass a Unicode user agent string to can_fetch(),
that function crashes with a TypeError under Python
2.4. Under Python 2.3, the error is a UnicodeDecodeError.
More detail:
When one calls can_fetch(MyUserAgent, url), the
robotparser module compares the UserAgent to each user
agent described in the robots.txt file. If
isinstance(MyUserAgent, str) == True then the
comparison does not raise an error regardless of the
contents of robots.txt. However, if
isinstance(MyUserAgent, unicode) == True, then Python
implicitly tries to convert the contents of the
robots.txt file to Unicode before comparing it to
MyUserAgent. By default, Python assumes a US-ASCII
encoding when converting, so if the contents of
robots.txt aren't ASCII, the conversion fails. In other
words, this works:
MyRobotParser.can_fetch('foobot', url)
but this fails:
MyRobotParser.can_fetch(u'foobot', url)
I recreated this with Python 2.4.1 on FreeBSD 6 and
Python 2.3 under Darwin/OS X. I'll attach examples from
both. The URLs that I use in the attachments are from
my Web site and will remain live. They reference
robots.txt files which contain an umlaut-ed 'a' (0xe4
in iso-8859-1). They're served up using a special
.htaccess file that adds a Content-Type header which
correctly identifies the encoding used for each file.
Here's the contents of the .htaccess file:
AddCharset iso-8859-1 .iso8859-1
AddCharset utf-8 .utf8
A suggested solution:
AFAICT, the construction of robots.txt is still defined
by a consensus on 30 June 1994 on the robots mailing
list [http://www.robotstxt.org/wc/norobots.html] and a
1996 draft proposal
[http://www.robotstxt.org/wc/norobots-rfc.html] that
has never evolved into a formal standard. Neither of
these mention character sets or encodings which is no
surprise considering that they date back to the days
when the Internet was poor but happy and we considered
even ASCII a luxury and we were grateful to have it.
(ASCII? We used to dream of having ASCII. We only had
one bit, and it was a zero. We lived in a shoebox in
the middle of the road... etc.) A backwards-compatible
yet forward-looking solution would be to have the
robotparser module respect the Content-Type header sent
with robots.txt. If no such header is present,
robotparser should try to decode it using iso-8859-1
per section 3.7.1 of the HTTP 1.1 spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1)
which says, 'When no explicit charset parameter is
provided by the sender, media subtypes of the text
type are defined to have a default charset value of
ISO-8859-1 when received via HTTP. Data in character
sets other than ISO-8859-1 or its subsets MUST be
labeled with an appropriate charset value.' Section
3.6.1 of the HTTP 1.0 spec says the same. Since
ISO-8859-1 is a superset of US-ASCII, robots.txt files
that are pure ASCII won't be affected by the change.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 10:17
Message:
Logged In: YES
user_id=849994
Turning into a Feature Request.
--
Comment By: osvenskan (osvenskan)
Date: 2006-03-07 16:32
Message:
Logged In: YES
user_id=1119995
Thanks for looking at this. I have some followup comments.
The list at robotstxt.org is many years stale (note that
Google's bot is present only as Backrub which was still a
server at Stanford at the time:
http://www.robotstxt.org/wc/active/html/backrub.html) but
nevertheless AFAICT it is the most current bot list on the
Web. If you look carefully, the list *does* contain a
non-ASCII entry (#76 --easy to miss in that long list). That
Finnish bot is gone but it has left a legacy in the form of
many robots.txt files that were created by automated tools
based on the robotstxt.org list. Google helps us here:
http://www.google.com/search?q=allintext%3AH%C3%A4m%C3%A4h%C3%A4kki+disallow+filetype%3Atxt
And by Googling for some common non-ASCII words and letters
I can find more like this one (look at the end of the
alphabetical list):
http://paranormal.se/robots.txt
Robots.txt files that contain non-ASCII are few and far
between, it seems, but they're out there.
Which leads me to a nitpicky (but
[ python-Bugs-1353433 ] Http redirection error in urllib2.py
Bugs item #1353433, was opened at 2005-11-10 20:25
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1353433group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Thomas Dehn (dehn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Http redirection error in urllib2.py
Initial Comment:
A url request returns a redirect that contains a space ' '
character. Python urllib2.py does not replace this
character with '%20' and fails.
Entering a line after line 507 of:
newurl=re.sub(' ','%20',newurl)
Corrects my problem.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 11:35
Message:
Logged In: YES
user_id=849994
Added a fix in rev. 43132.
--
Comment By: John J Lee (jjlee)
Date: 2006-02-01 20:28
Message:
Logged In: YES
user_id=261020
The problem is more general, so perhaps:
URLQUOTE_SAFE_URL_CHARS = !*'();:@=+$,/?%#[]~
newurl = urllib.quote(url, URLQUOTE_SAFE_URL_CHARS)
Caveat: I still haven't read RFCs 3986/3987...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1353433group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1453145 ] Unexpected module reloading
Bugs item #1453145, was opened at 2006-03-18 16:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1453145group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ali Gholami Rudi (aligrudi) Assigned to: Nobody/Anonymous (nobody) Summary: Unexpected module reloading Initial Comment: I'll demonstrate the problem: Consider the following package hierarchy: p/ __all__.py m1.py m2.py The contents of m1 and m2 modules are: -m1.py import m2 import p.m2 -- -m2.py print 'Loading m2 module' -- Running the m1 module would yield the output Loading m2 module Loading m2 module . As it is obvious from the output the module m2 is loaded twice. The problem arrises when you want to do things such as implementing a singleton class: -Alternate m2.py- class Singleton(object): _instance = None @staticmethod def getInstance(): if Singleton._instance is None: Singleton._instance = Singleton() return _instace - -Alternate m1.py- import m2 import p.m2 print m2.Singleton.getInstance() print p.m2.Singleton.getInstance() - If you run m1 module, the output shows that the two instaces are not the same objects. That is m2.Singleton and p.m2.Singleton are not the same classes. I think this is a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1453145group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448042 ] Defining a class with __dict__ brakes attributes assignment
Bugs item #1448042, was opened at 2006-03-11 22:49
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1448042group_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: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment
Initial Comment:
When defining a class with __dict__ attribute, its
instances can't rebind their __dict__ attributes.
--
class C(object): __dict__ = {}
obj = C()
obj.a = object()
import gc
gc.get_referrers(obj.a) # = [{'a': object object at
0x811d5b0}]
obj.__dict__ = {} # doesn't really bind new __dict__
vars(obj) # = {}
object.__getattribute__(obj, '__dict__') # = {}
object.__getattribute__(C, '__dict__') # = {..., but
without a}
obj.a # = object object at 0x811d5b0 (no exception
!)
gc.get_referrers(obj.a) # = [{'a': object object at
0x811d5b0, '__dict__': {}}]
--
Although neither class nor object has an attribute a,
it's still accessible. It's also not possible to rebind
__dict__ in that object, as it gets inside real object
attributes dictionary.
This behaviour has been tested on Python 2.2, 2.3 and
2.4, but may as well affect earlier versions.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 17:57
Message:
Logged In: YES
user_id=849994
Reopening. This is a bug, confirmed by Alex Martelli.
--
Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 13:01
Message:
Logged In: YES
user_id=1310227
To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
It's Alex Martelli implementation of Borg design pattern.
If rebinding __dict__ is forbidden, it should be clearly
noted in the documetation. Either way, it's a bug.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 08:29
Message:
Logged In: YES
user_id=849994
Agreed with Terry.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 03:21
Message:
Logged In: YES
user_id=593130
To me, this falls under the category of 'don't do that'.
http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers
__*__
System-defined names. These names are defined by the
interpreter and its implementation ...
To me, this means to use them in the manner specified or
you get what you get.
http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'. There is, as
far as I know, no specified usage for rebinding '__dict__'.
So unless someone has a better idea that won't slow down
proper usage, I would close this as 'invalid' or 'wont
fix'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1448042group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1453341 ] sys.setatomicexecution - for critical sections
Feature Requests item #1453341, was opened at 2006-03-18 20:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=355470aid=1453341group_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: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: sys.setatomicexecution - for critical sections Initial Comment: In order to maintain threaded code uncomplicated (VHL) and in order to avoid massive use of locks, when introducing few critical non-atomic sections, it should be possible to put out that practical hammer .. try: last_ci=sys.setcheckinterval(sys.maxint) critical_function() # now runs atomically finally: sys.setcheckinterval(last_ci) #(sys.setcheckinterval assumed to return the last value) ..by an official function/class (in sys or thread): Maybe: == atomic = sys.setatomicexecution(mode) try: print Executing critical section finally: sys.setatomicexecution(atomic) there should be different modes/levels for blocking : * 0=None * 1=block only python execution in other threads * 2=block signals * 4/5/7/15=block threads at OS level (if OS supports) * 8=(reserved: block future sub-/stackless switching inside current thread..) see: http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200 compare: http://www.stackless.com/wiki/Tasklets#critical-sections --- Also Python could define officially its time atoms beyond CPU atoms in the docs (That also defines the VHL usability of the language). Thus thinks like single-element changes ... obj.var=x , d[key]=x , l.append(x) .pop() should be guaranteed to work atomic/correct FOR EVER. l[slice], d.keys() .items(), .. questionable? If not guaranteed for the future, offer duplicates for speed critical key building blocks like: l.slice_atomic(slice), d.keys_atomic() ,... in order to make code compatible for the future. --- Extra fun for blowing up python libs for poeple who don't want to learn that try..finally all the time: copy/deepcopy/dump maybe could be enriched by copy_atomic , deepcopy_atomic, dump_atomic - or just RuntimeError tolerant versions, deepcopy_save (no use of .iterxxx) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=355470aid=1453341group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1453341 ] sys.setatomicexecution - for critical sections
Feature Requests item #1453341, was opened at 2006-03-18 20:52 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=355470aid=1453341group_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: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: sys.setatomicexecution - for critical sections Initial Comment: In order to maintain threaded code uncomplicated (VHL) and in order to avoid massive use of locks, when introducing few critical non-atomic sections, it should be possible to put out that practical hammer .. try: last_ci=sys.setcheckinterval(sys.maxint) critical_function() # now runs atomically finally: sys.setcheckinterval(last_ci) #(sys.setcheckinterval assumed to return the last value) ..by an official function/class (in sys or thread): Maybe: == atomic = sys.setatomicexecution(mode) try: print Executing critical section finally: sys.setatomicexecution(atomic) there should be different modes/levels for blocking : * 0=None * 1=block only python execution in other threads * 2=block signals * 4/5/7/15=block threads at OS level (if OS supports) * 8=(reserved: block future sub-/stackless switching inside current thread..) see: http://groups.google.de/group/comp.lang.python/browse_frm/thread/bf5461507803975e/3bd7dfa9422a1200 compare: http://www.stackless.com/wiki/Tasklets#critical-sections --- Also Python could define officially its time atoms beyond CPU atoms in the docs (That also defines the VHL usability of the language). Thus thinks like single-element changes ... obj.var=x , d[key]=x , l.append(x) .pop() should be guaranteed to work atomic/correct FOR EVER. l[slice], d.keys() .items(), .. questionable? If not guaranteed for the future, offer duplicates for speed critical key building blocks like: l.slice_atomic(slice), d.keys_atomic() ,... in order to make code compatible for the future. --- Extra fun for blowing up python libs for poeple who don't want to learn that try..finally all the time: copy/deepcopy/dump maybe could be enriched by copy_atomic , deepcopy_atomic, dump_atomic - or just RuntimeError tolerant versions, deepcopy_save (no use of .iterxxx) -- Comment By: kxroberto (kxroberto) Date: 2006-03-18 22:54 Message: Logged In: YES user_id=972995 or: atomic = sys.acquireatomicexecution(mode) try: ... print 'critical section' ... finally: ... atomic.release() with sys.acquireatomicexecution(mode): ... print 'critical section' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=355470aid=1453341group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat
Bugs item #1295808, was opened at 2005-09-19 21:44 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1295808group_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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Martin v. Löwis (loewis) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) -- pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with PyExpat_. This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. -- Comment By: Trent Mick (tmick) Date: 2006-03-18 23:58 Message: Logged In: YES user_id=34892 Attempted summary to get this patch into Python 2.5: As Neal points out this is a duplicate of http://python.org/sf/1075984. The patch on *that* bug fixes the specific issue, but does not solve the general problem (as 'mwh' pointed out in the comments there). I think we should 1. apply this patch 2. then perhaps update our expat version (see http://python.org/sf/1433435, http://mail.python.org/pipermail/python-dev/2006-March/062287.html), 3. then update Modules/expat/pyexpatns.h (that this patch adds) for any new symbols in the new version of Expat. Neal, Martin, Michael, what do you think? -- Comment By: Trent Mick (tmick) Date: 2006-01-24 23:34 Message: Logged In: YES user_id=34892 This seems to be a duplicate of bug #1075984. You are right. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? Yes. I do not think this patch can be applied to 2.4. That's fine. Getting this into Python =2.5 would be good enough. Martin, Have you had a chance to review this? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 06:01 Message: Logged In: YES user_id=33168 This seems to be a duplicate of bug #1075984. I like this patch better, but perhaps both patches (the one here and the other bug report) should be implemented? I think Martin helps maintain pyexpat. Maybe he has some ideas about either or both of these bugs/patches. Martin, do you think these are safe to apply? I can apply the patch(es) if you think it's safe. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? I do not think this patch can be applied to 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1295808group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat
Bugs item #1295808, was opened at 2005-09-19 21:44 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1295808group_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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Trent Mick (tmick) Assigned to: Martin v. Löwis (loewis) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) -- pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with PyExpat_. This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. -- Comment By: Trent Mick (tmick) Date: 2006-03-19 00:25 Message: Logged In: YES user_id=34892 As well, *possibly* the same should be done for Python's bz2.so, although the only relevant exported symbol is Util_UnivNewlineRead nm bz2.so \ | grep -v [a-zBUA] \ | grep -v _fini\|_init\|initbz2 -- Comment By: Trent Mick (tmick) Date: 2006-03-18 23:58 Message: Logged In: YES user_id=34892 Attempted summary to get this patch into Python 2.5: As Neal points out this is a duplicate of http://python.org/sf/1075984. The patch on *that* bug fixes the specific issue, but does not solve the general problem (as 'mwh' pointed out in the comments there). I think we should 1. apply this patch 2. then perhaps update our expat version (see http://python.org/sf/1433435, http://mail.python.org/pipermail/python-dev/2006-March/062287.html), 3. then update Modules/expat/pyexpatns.h (that this patch adds) for any new symbols in the new version of Expat. Neal, Martin, Michael, what do you think? -- Comment By: Trent Mick (tmick) Date: 2006-01-24 23:34 Message: Logged In: YES user_id=34892 This seems to be a duplicate of bug #1075984. You are right. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? Yes. I do not think this patch can be applied to 2.4. That's fine. Getting this into Python =2.5 would be good enough. Martin, Have you had a chance to review this? -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 06:01 Message: Logged In: YES user_id=33168 This seems to be a duplicate of bug #1075984. I like this patch better, but perhaps both patches (the one here and the other bug report) should be implemented? I think Martin helps maintain pyexpat. Maybe he has some ideas about either or both of these bugs/patches. Martin, do you think these are safe to apply? I can apply the patch(es) if you think it's safe. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? I do not think this patch can be applied to 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1295808group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1452697 ] broken string on mbcs
Bugs item #1452697, was opened at 2006-03-18 05:07 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1452697group_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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: ocean-city (ocean-city) Assigned to: M.-A. Lemburg (lemburg) Summary: broken string on mbcs Initial Comment: Hello. I noticed unicode conversion from mbcs was sometimes broken. This happened when I used codecs.open(foo, r, mbcs) as iterator. # It's OK if I use shift_jis or cp932. I'll attach the script and text file to reproduce the problem. I'm using Win2000SP4(Japanese). Thank you. -- Comment By: ocean-city (ocean-city) Date: 2006-03-19 11:08 Message: Logged In: YES user_id=1200846 I updated the patch. Compared to version1... * [bug] consumed should be 0 if the length of string is 0 * [enhancement] use IsDBCSLeadByte to detect incomplete buffer termination instead of trying MultiByteToWideChar with MB_ERR_INVALID_CHARS. This could cause performance hit if string contains invalid chars in early part. -- Comment By: ocean-city (ocean-city) Date: 2006-03-18 13:17 Message: Logged In: YES user_id=1200846 Probably this patch will fix the problem. (for release24-maint) Cause: MultiByteToWideChar returns non zero value for incomplete multibyte character. (ex: if buffer terminates with leading byte, MultiByteToWideChar returns 1 (not 0) for it. It should return 0, otherwise result will be broken. Solution: Set flag MB_ERR_INVALID_CHARS to avoid incorrect handling of trailing incomplete multibyte part. If error occurs, removes the trailing byte and tries again. Caution: I have not tested this so intensibly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1452697group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1453570 ] try-except-finally in the tutorial
Bugs item #1453570, was opened at 2006-03-19 13:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1453570group_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.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: try-except-finally in the tutorial Initial Comment: Doc/tut/tut.tex describes finally statement as :: A try statement must either have one or more except clauses or one finally clause, but not both ... But now that PEP 341[*] has been accepted and merged, this part needs a rewrite. Adding a new section or an example using try-except- (else-)finally will be required. * http://www.python.org/peps/pep-0341.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1453570group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1453579 ] conditional expression documentation missing/incorrect
Bugs item #1453579, was opened at 2006-03-19 00:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1453579group_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.5 Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: conditional expression documentation missing/incorrect Initial Comment: PEP 308 http://www.python.org/doc/peps/pep-0308/ says Python 2.5 will add a conditional expression. The Programming FAQ is as a result now wrong: http://www.python.org/doc/faq/programming/#is-there-an-equivalent-of-c-s-ternary-operator Also I do not see mention of this on the What's New page, especially http://www.python.org/dev/doc/devel/whatsnew/node5.html where it seems naturally to belong. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1453579group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
