[issue3338] cPickle segfault with deep recursion
Martin v. Löwis [EMAIL PROTECTED] added the comment: Can you try this for a newer version? For 2.4, such problems will not be fixed anymore. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3338 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment:
3.0b1 has been released, so no new features can be added to 3.0.
While my proposal is no doubt going to cause a lot of code breakage, I
hardly consider it a new feature. This is very definitely a bug. As I
understand it, the point of a code freeze is to stop the addition of
features which could be added to a later version. Realistically, there
is no way this issue can be fixed after 3.0 is released, as it
necessarily involves changing the behaviour of this function.
Perhaps I should explain further why this is a regression from Python
2.x and not a feature request. In Python 2.x, with byte strings, the
encoding is not an issue. quote and unquote simply encode bytes, and if
you want to use Unicode you have complete control. In Python 3.0, with
Unicode strings, if functions manipulate string objects, you don't have
control over the encoding unless the functions give you explicit
control. So Python 3.0's native Unicode strings have broken the library.
I give two examples.
Firstly, I believe that unquote(quote(x)) should always be true for all
strings x. In Python 2.x, this is always trivially true (for non-Unicode
strings), because they simply encode and decode the octets. In Python
3.0, the two functions are inconsistent, and break out of the range(0, 256).
urllib.parse.unquote(urllib.parse.quote('ÿ')) # '\u00ff'
'ÿ'
# Works, because both functions work with ISO-8859-1 in this range.
urllib.parse.unquote(urllib.parse.quote('Ā')) # '\u0100'
'Ä\x80'
# Fails, because quote uses UTF-8 and unquote uses ISO-8859-1.
My patch succeeds for all characters.
urllib.parse.unquote(urllib.parse.quote('Ā')) # '\u0100'
'Ā'
Secondly, a bigger example, but I want to demonstrate how this bug
affects web applications, even very simple ones.
Consider this simple (beginnings of a) wiki system in Python 2.5, as a
CGI app:
#---
import cgi
fields = cgi.FieldStorage()
title = fields.getfirst('title')
print(Content-Type: text/html; charset=utf-8)
print()
print('pDebug: %s/p' % repr(title))
if title is None:
print(No article selected)
else:
print('pInformation about %s./p' % cgi.escape(title))
#---
(Place this in cgi-bin, navigate to it, and add the query string
?title=Page Title). I'll use the page titled Mátt as a test case.
If you navigate to ?title=Mátt, it displays the text Debug:
'M\xc3\xa1tt'. Information about Mátt.. The browser (at least Firefox,
Safari and IE I have tested) encodes this as ?title=M%C3%A1tt. So this
is trivial, as it's just being unquoted into a raw byte string
'M\xc3\xa1tt', then written out again as a byte string.
Now consider that you want to manipulate it as a Unicode string, still
in Python 2.5. You could augment the program to decode it as UTF-8 and
then re-encode it. (I wrote a simple UTF-8 printing function which takes
Unicode strings as input).
#---
import sys
import cgi
def printu8(*args):
Prints to stdout encoding as utf-8, rather than the current terminal
encoding. (Not a fully-featured print function).
sys.stdout.write(' '.join([x.encode('utf-8') for x in args]))
sys.stdout.write('\n')
fields = cgi.FieldStorage()
title = fields.getfirst('title')
if title is not None:
title = str(title).decode(utf-8, replace)
print(Content-Type: text/html; charset=utf-8)
print()
print('pDebug: %s./p' % repr(title))
if title is None:
print(No article selected.)
else:
printu8('pInformation about %s./p' % cgi.escape(title))
#---
Now given the same input (?title=Mátt), it displays Debug:
u'M\xe1tt'. Information about Mátt. Still working fine, and I can
manipulate it as Unicode because in Python 2.x I have direct control
over encoding/decoding.
Now let us upgrade this program to Python 3.0. (Note that I still can't
print Unicode characters directly out, because running through Apache
the stdout encoding is not UTF-8, so I use my printu8 function).
#---
import sys
import cgi
def printu8(*args):
Prints to stdout encoding as utf-8, rather than the current terminal
encoding. (Not a fully-featured print function).
sys.stdout.buffer.write(b' '.join([x.encode('utf-8') for x in args]))
sys.stdout.buffer.write(b'\n')
fields = cgi.FieldStorage()
title = fields.getfirst('title')
# Note: No call to decode. I have no opportunity to specify the encoding
since
# it comes straight out of FieldStorage as a Unicode string.
print(Content-Type: text/html; charset=utf-8)
print()
print('pDebug: %s./p' % ascii(title))
if title is None:
print(No article selected.)
else:
printu8('pInformation about %s./p' % cgi.escape(title))
#---
Now given the same input (?title=Mátt), it displays Debug:
'M\xc3\xa1tt'. Information about Mátt. Once again, it is erroneously
(and implicitly) decoded as ISO-8859-1, so I end up with a meaningless
Unicode string. The only possible thing I can do about this as a web
developer is call title.encode('latin-1').decode('utf-8') - a dreadful hack.
With my patch applied, the input
[issue2275] urllib2 header capitalization
Hans-Peter Jansen [EMAIL PROTECTED] added the comment: Facundo, first of all: *really* nice work, thanks a lot. While I don't fully understand the issues raised lately here, especially what broke (user code). I can see, that it completely solves my original problem, which is great. While reading the patch, I noticed, that the modifications to Doc/library/urllib2.rst contain two typos (retrive instead of retrieve). The only remaining issue left in this area is using some form of ordered dict for headers in order to control - how it comes - the order of headers ;-), but that's left for another issue to raise some day. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: Since I got a complaint that my last reply was too long, I'll summarize it. It's a bug report, not a feature request. I can't get a simple web app to be properly Unicode-aware in Python 3, which worked fine in Python 2. This cannot be put off until 3.1, as any viable solution will break existing code. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin/oct/hex show floats
Mark Dickinson [EMAIL PROTECTED] added the comment: Minor modifications to the previous patch, mostly to the docs. Setting priority to critical, since this really needs to go in before the next beta if it's going to get into 2.6/3.0. -- priority: - critical Added file: http://bugs.python.org/file10876/hex_float5.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3340] optparse print_usage(),.. methods are not documented
New submission from anatoly techtonik [EMAIL PROTECTED]: optparse API documentation is incomplete. It doesn't mention at least some useful functions such as print_usage(), get_usage(), get/print_version() present in optparse.py docstrings. -- assignee: georg.brandl components: Documentation messages: 69543 nosy: georg.brandl, techtonik severity: normal status: open title: optparse print_usage(),.. methods are not documented versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3340 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3341] Suggest a change link
New submission from anatoly techtonik [EMAIL PROTECTED]: It would be convenient to have Suggest a change link in the bottom of documentation pages to allow people propose fixes and additions. This can be a simple feedback form with an optional patch field that submits mail to a list or simply adds documentation comment. More complex approach would be construct patch right in the browser. Then add it for review into documentation queue. documentation queue is a part of documentation system to automatically submit patches after review (and optionally incrementally-recompile existing output formats). In case of page comments review status can be displayed in place together with comments and patches. The whole edit/review process may require single sign on system described in issue #2837 -- assignee: georg.brandl components: Documentation messages: 69544 nosy: georg.brandl, techtonik severity: normal status: open title: Suggest a change link ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3341 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2823] Report bug links
anatoly techtonik [EMAIL PROTECTED] added the comment: Filed a proposal for online documentation editing tool. http://bugs.python.org/issue3341 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3333] Need -3 warning for exec statement becoming a function
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3342] Tracebacks are not properly indented
New submission from Amaury Forgeot d'Arc [EMAIL PROTECTED]: r62555 has the unfortunate effect that source lines are no more indented in tracebacks, as in: Traceback (most recent call last): File string, line 1, in module File C:\python\trunk\lib\re.py, line 150, in sub return _compile(pattern, 0).sub(repl, string, count) File C:\python\trunk\lib\re.py, line 276, in filter return sre_parse.expand_template(template, match) File c:\python\trunk\lib\sre_parse.py, line 793, in expand_template raise error, unmatched group sre_constants.error: unmatched group And IMO, test_traceback.test_traceback_indentation() tests the wrong behaviour :-( I join a tentative patch to correct the problem. -- files: traceback.patch keywords: patch messages: 69546 nosy: amaury.forgeotdarc severity: normal status: open title: Tracebacks are not properly indented Added file: http://bugs.python.org/file10877/traceback.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I think there is a problem when the source file cannot be opened (a .pyc without its .py): the four spaces are printed, but not the line, and the following level is not properly indented. See issue3342 for a competing patch that corrects the indentation problem. -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3343] Py_DisplaySourceLine is not documented
New submission from Amaury Forgeot d'Arc [EMAIL PROTECTED]: This new function is not documented at all. And I find the error handling not consistent: when filename is NULL, -1 is returned, but no exception is set. IMO the return code should be as follow: - return 1 if a line was printed - return 0 if the line cannot be found - return -1 in case of error (when calling PyFile_WriteString); an exception is set. -- components: Interpreter Core messages: 69548 nosy: amaury.forgeotdarc severity: normal status: open title: Py_DisplaySourceLine is not documented type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Jesse Noller [EMAIL PROTECTED] added the comment: I can confirm that this seems to clear up the test_multiprocessing hangs on my mac, I ran make test in a loop almost all day yesterday without hangs. I would really suggest we get this in, minus the new test_threading tests for now. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I agree. My attempt to describe the behaviour of fork+threads in a platform-independent test is another issue. Just one more thing: looking at Module/posixmodule.c, os.fork1() calls PyOS_AfterFork() in both parent and child processes. Is there a if (pid == 0) test missing, just like os.fork()? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779233] PyThreadState_SetAsyncExc and the main thread
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Two things may prevent the exception from being seen: - First, the async exception is not immediate; it is checked every 100 bytecodes (=sys.getcheckinterval()). When testing from the interactive prompt, try something like for x in range(100): pass. - Then, chances are that the exceptions is actually raised, but silently swallowed somewhere by the interpreter: for example, if the exception is raised from inside a __getattr__ function of some object, when called by hasattr(). SetAsyncExc does not seem very reliable... -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1779233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Mark Dickinson [EMAIL PROTECTED] added the comment: Mildly off-topic: it seems that currently eval(repr(x)) == x isn't always true, anyway. On OS X 10.5.4/Intel, I get: x = (2**52-1)*2.**(-1074) x 2.2250738585072009e-308 y = eval(repr(x)) y 2.2250738585072014e-308 x == y False This is almost certainly an OS X bug... ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2054] add ftp-tls support to ftplib - RFC 4217
Lukasz Szybalski [EMAIL PROTECTED] added the comment: Is the ftp-tls able to use certificate to connect to ftps server? I currently need to connect to state's ftps server which requires certificate to be present when authenticating. Is that option available? What is the current status of this issue? Thanks, Lucas -- nosy: +lszyba1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Tim Peters [EMAIL PROTECTED] added the comment: About (2**52-1)*2.**(-1074): same outcome under Cygwin 2.5.1, which is presumably based on David Gay's perfect rounding code. Cool ;-) Under the native Windows 2.5.1: x = (2**52-1)*2.**(-1074) x 2.2250738585072009e-308 y = eval(repr(x)) y 0.0 Hard to say whether that's actually worse :-( About %.15g, good point! It probably would make Guido happy. It's hard to know for sure, because despite what people say about this, the real objection to the status quo is aesthetic, not technical, and there's no disputing tastes. My tastes agree that %.17g is a pain in the ass when using the interactive shell -- I rarely want to see so many digits. But %.15g, and even %.12g, would /still/ be a pain in the ass, and for the same reason. Most times I'd be happiest with plain old %g (same as %.6g). OTOH, sometimes I do want to see all the bits, and sometimes I'd like a fixed format (like %.2f), and so on. Alas, all choices suck for strong reasons (either technical or aesthetic -- and, BTW, your lots of trailing zeroes idea won't fly because of the latter). The introduction of hex formats for floats should make this starkly clear: using hex I/O for float repr would be the ideal technical choice: easy to code, extremely fast, compact representation, and highly portable. Those are supposedly repr's goals, regardless of whether the repr string is easily readable by humans. But you know without asking that using hex format for repr(float) has no chance of being adopted -- because it's ugly :-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3339] dummy_thread LockType.acquire() always returns None, should be True or False
Changes by Brett Cannon [EMAIL PROTECTED]: -- assignee: - brett.cannon nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3339 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3342] Tracebacks are not properly indented
Changes by Brett Cannon [EMAIL PROTECTED]: -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3342] Tracebacks are not properly indented
Brett Cannon [EMAIL PROTECTED] added the comment: I really hate how touchy the indentation output is for warnings/tracebacks. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3343] Py_DisplaySourceLine is not documented
Brett Cannon [EMAIL PROTECTED] added the comment: The function should be made private as it is not expected to be called by anyone else but the core. -- assignee: - brett.cannon nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3342] Tracebacks are not properly indented
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: This is why I added an explicit indent parameter to Py_DisplaySourceLine. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3342] Tracebacks are not properly indented
Changes by Brett Cannon [EMAIL PROTECTED]: -- assignee: - brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1519638] Unmatched Group issue - workaround
Brandon Mintern [EMAIL PROTECTED] added the comment: Looking at your code example, that solution seems quite obvious now, and I wouldn't even call it a workaround. Thanks for figuring this out. Now if I could only remember what code I was using that for... ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1519638 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3288] float.as_integer_ratio method is not documented
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- assignee: georg.brandl - rhettinger nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le vendredi 11 juillet 2008 à 12:12 +, Amaury Forgeot d'Arc a écrit : I think there is a problem when the source file cannot be opened (a .pyc without its .py): the four spaces are printed, but not the line, and the following level is not properly indented. See issue3342 for a competing patch that corrects the indentation problem. Great! Do you plan to commit it soon or should I include it into my patch? (and do you have other observations on the present patch?) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
John J Lee [EMAIL PROTECTED] added the comment:
There already is a test for the breakage, but the patch changes the
expected output to match the new return value of .header_items():
-[('Foo-bar', 'baz'), ('Spam-eggs', 'blah')]
+[('Foo-Bar', 'baz'), ('Spam-Eggs', 'blah')]
Code that previously worked fine, for example code that iterates through
.header_items() and does string comparisons on the header names, or does
in tests on the keys of dict(header_items), etc. will break, the
existence of .has_header() notwithstanding.
What is the purpose of this change? Can you explain how that justifies
breaking working code?
The alternative to this change is to leave the return value of
.header_items() unchanged. That could be done by performing case
normalisation at a later stage.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2275
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
John J Lee [EMAIL PROTECTED] added the comment: * The patch to the docs seems to muddy the waters even further (than the current slightly murky state) about whether and why .headers is to be preferred over the methods, or vice-versa. I think .headers should remain undocumented, for the reason stated by the doctest that failed with Hans-Peter's original patch. IIRC, Hans-Peter's comment was on the reference to .headers undocumented interface mentioned in the test_urllib2. I made no reference to Hans-Peter's comment -- only to his patch, so I don't know what you're getting at here. Could you respond to my comment, please? The best course of action is debatable, but the patch is a regression in this respect, so should not be committed as-is. My understanding in this case was to address 1) Title()-ize the headers and 2) provide a case insensitive lookup. Can you explain why you think providing case-insensitive lookup requires documenting .headers? Is this sufficient now to expose the headers method? If not, what else? If headers method should not be exposed, then will the 2 cases addressed above still do, as this issue request was opened for that? There is no method named headers. I think that the .headers attribute should never be documented, because it does not contain the unredirected headers. Changing that behaviour would break code, further confuse matters and complicate writing code that works with multiple versions of Python. A case *could* be made for changing it (by including the unredirected headers), because other code will have been broken by the introduction of .unredirected_hdrs; I prefer instead to stick with old breakage rather than swapping it for new breakage, but as I say, the best course of action is debatable. Another choice would be to start the process of deprecating .headers, and introduce a new attribute with a similar function. As long as your chosen solution isn't actually a step backwards or sharply sideways, I probably won't object very strongly. What isn't really debatable is that the patch makes things worse here: it adds a newly-documented interface which is subtly and surprisingly different from the other one (an unacceptable change in itself, IMO) without even explaining the difference between the two, why they are different, and why one would want to use or avoid one or other interface. There are other problems with the documentation patch, but there's no point in discussing those until the changes are agreed on. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
John J Lee [EMAIL PROTECTED] added the comment: Just to quickly note that by providing case-insensitive lookup I don't necessarily mean via .headers. But it's you who's providing the patch, so I'll wait for your next suggestion rather than discuss how I might change the code. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3317] duplicate lines in zipfile.py
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Committed as 64880. -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3317 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2280] parser module chokes on unusual characters
Kuba Fast [EMAIL PROTECTED] added the comment:
I get no problem in 3.0b1. Should this be closed?
parser.suite('\u1234')
parser.st object at 0xb7ceebd0
--
nosy: +kfast
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2280
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3343] Py_DisplaySourceLine is not documented
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: r64881: Py_DisplaySourceLine is renamed to _Py_DisplaySourceLine -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3342] Tracebacks are not properly indented
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Corrected as r64881. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3342] Tracebacks are not properly indented
Brett Cannon [EMAIL PROTECTED] added the comment: Thanks for fixing this and renaming the function, Amaury! On Fri, Jul 11, 2008 at 2:46 PM, Amaury Forgeot d'Arc [EMAIL PROTECTED] wrote: Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Corrected as r64881. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3342 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I committed r64881, which invalidates your patch a bit :-| BTW, I don't like your comment Can't be bothered to check all those PyFile_WriteString() calls. In general, it is not a good idea to execute python code with an exception set, this leads to subtle problems, and some XXX undetected error prints in debug mode. Chaining several calls to PyDict_SetItem for example is usually not a problem, but PyFile_WriteString does execute python code in python3.0. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue874900] threading module can deadlock after fork
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I am leaving for the whole next week, so anyone, feel free to commit (part of) my patch if it helps. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue874900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1529018] Move firewall warning to about menu
Tal Einat [EMAIL PROTECTED] added the comment: What if this message was made part of the error message which is displayed when the connection to the subprocess fails? This way only users in situations where it is likely that the warning is relevant will see it. I suggest this since the original problem for which the warning was added has become very uncommon, so bugging all of our users with such a warning (even if it has a don't show this again check-box) seems unnecessary. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1529018 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3344] IDLE - use enumerate instead of zip(count(), ...)
New submission from Tal Einat [EMAIL PROTECTED]: Just minor code cleanup. Only one instance of zip(count(), ...) in EditorWindow.py, where I also changed 'file' to 'file_name' to avoid overriding the built-in 'file' class. -- files: IDLE_EditorWindow_minor.patch keywords: patch messages: 69571 nosy: kbk, taleinat severity: normal status: open title: IDLE - use enumerate instead of zip(count(), ...) Added file: http://bugs.python.org/file10878/IDLE_EditorWindow_minor.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3344 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
Ezio Melotti [EMAIL PROTECTED] added the comment: On my Linux box sys.maxunicode == 1114111 and len(u'\U00010123') == 1, so it should be a UTF-32 build. On windows instead sys.maxunicode == 65535 and len(u'\U00010123') == 2, so it should be a UTF-16 build. The problem seems then related to UTF-32 builds. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3345] Patch for CGIHTTPServer.is_cgi function documentation
New submission from Miki Tebeka [EMAIL PROTECTED]: The current documentation is wrong and does not specify the fact that this functions sets cgi_info (maybe also rename the function?) -- assignee: georg.brandl components: Documentation files: CGIHTTPServer.py.diff keywords: patch messages: 69574 nosy: georg.brandl, tebeka severity: normal status: open title: Patch for CGIHTTPServer.is_cgi function documentation versions: Python 2.6 Added file: http://bugs.python.org/file10879/CGIHTTPServer.py.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3345 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
Adam Olsen [EMAIL PROTECTED] added the comment: Simpler way to reproduce this (on linux): $ rm unicodetest.pyc $ $ python -c 'import unicodetest' Result: False Len: 2 1 Repr: u'\ud800\udd23' u'\U00010123' $ $ python -c 'import unicodetest' Result: True Len: 1 1 Repr: u'\U00010123' u'\U00010123' Storing surrogates in UTF-32 is ill-formed[1], so the first part definitely shouldn't be failing on linux (with a UTF-32 build). The repr could go either way, as unicode doesn't cover escape sequences. We could allow u'\ud800\udd23' literals to magically become u'\U00010123' on UTF-32 builds. We already allow repr(u'\ud800\udd23') to magically become u'\U00010123' on UTF-16 builds (which is why the repr test always passes there, rather than always failing). The bigger problem is how much we prohibit ill-formed character sequences. We already prevent values above U+10, but not inappropriate surrogates. [1] Search for D90 in http://www.unicode.org/versions/Unicode5.0.0/ch03.pdf -- nosy: +Rhamphoryncus Added file: http://bugs.python.org/file10880/unicodetest.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3112] implement PEP 3134 exception reporting
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le vendredi 11 juillet 2008 à 22:18 +, Amaury Forgeot d'Arc a écrit : I committed r64881, which invalidates your patch a bit :-| Apparently you committed in trunk rather than py3k? Could you svnmerge into py3k as well? Then it should be quite easy to rework my patch around it. BTW, I don't like your comment Can't be bothered to check all those PyFile_WriteString() calls. It's not my comment, it was already there. I agree it doesn't sound very meticulous. :-) In general, it is not a good idea to execute python code with an exception set, this leads to subtle problems, and some XXX undetected error prints in debug mode. Chaining several calls to PyDict_SetItem for example is usually not a problem, but PyFile_WriteString does execute python code in python3.0. Well, as said above, I just kept the original method of doing things... If you think of a simple solution to make things better (and a test case to validate it), I'm open to integrating it in the patch. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: Just to clarify: Python can be built as UCS2 or UCS4 build (not UTF-16 vs. UTF-32). The conversions done from the literal escaped representation to the internal format are done using the unicode-escape and raw-unicode-escape codecs. PYC files are written using the marshal module, which uses UTF-8 as encoding for Unicode objects. All of these codecs know about surrogates, so there must be a bug somewhere in the Python tokenizer or compiler. I checked on Linux using a UCS2 and a UCS4 build of Python 2.5: the problem only shows up with the UCS4 build. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
Adam Olsen [EMAIL PROTECTED] added the comment: No, the configure options are wrong - we do use UTF-16 and UTF-32. Although modern UCS-4 has been restricted down to the range of UTF-32 (it used to be larger!), UCS-2 still doesn't support the supplementary planes (ie no surrogates.) If it really was UCS-2, the repr wouldn't be u'\U00010123' on windows. It'd be a pair of ill-formed code units instead. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2280] parser module chokes on unusual characters
David Binger [EMAIL PROTECTED] added the comment: On Jul 11, 2008, at 5:35 PM, Kuba Fast wrote: I get no problem in 3.0b1. Should this be closed? I think so. It looks like this has been fixed. Thanks. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
