[issue3300] urllib.quote and unquote - Unicode issues

[Matt Giuca]

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('Debug: %s' % repr(title))
if title is None:
print("No article selected")
else:
print('Information about %s.' % 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('Debug: %s.' % repr(title))
if title is None:
print("No article selected.")
else:
printu8('Information about %s.' % 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('Debug: %s.' % ascii(title))
if title is None:
print("No article selected.")
else:
printu8('Information about %s.' % 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 dr

[issue2275] urllib2 header capitalization

[Hans-Peter Jansen]

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]>

___
___
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]

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]>

___
___
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

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Amaury, as Alan is fine with these changes, feel free to apply them.

--
assignee: loewis -> amaury.forgeotdarc
resolution:  -> accepted

___
Python tracker <[EMAIL PROTECTED]>

___
___
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

[Henk Punt]

New submission from Henk Punt <[EMAIL PROTECTED]>:

Class LockType always seems to be returning None if waitflag is not
specified.

If you look up the documentation for the non dummy lock in lib ref
15.3.1 , none of the possible
results should be ‘None’, in fact it would always return True, except
when non-block is specified
And another thread is already holding the lock then it would return False

From the docs on acquire():

Acquire a lock, blocking or non-blocking. 
When invoked without arguments, block until the lock is unlocked, then
set it to locked, and return true. 
When invoked with the blocking argument set to true, do the same thing
as when called without arguments, and return true. 
When invoked with the blocking argument set to false, do not block. If a
call without an argument would block, return false immediately;
otherwise, do the same thing as when called without arguments, and
return true.

--
components: Library (Lib)
messages: 69539
nosy: toymachine
severity: normal
status: open
title: dummy_thread LockType.acquire() always returns None, should be True or 
False
type: behavior
versions: Python 2.5

___
Python tracker <[EMAIL PROTECTED]>

___
___
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

[Andrii V. Mishkovskyi]

Andrii V. Mishkovskyi <[EMAIL PROTECTED]> added the comment:

Seems like inconsistency to me, this simple patch should fix it.

--
keywords: +patch
nosy: +mishok13
Added file: http://bugs.python.org/file10875/issue3339.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1519638] Unmatched Group issue - workaround

[Gerard]

Gerard <[EMAIL PROTECTED]> added the comment:

Hi All,

I found a workaround for the re.sub method so it does not raise an
exception but returns and empty string when backref-ing an empty group.

This is the nutshell:

When doing a search and replace with sub, replace the group represented
as optional for a group represented as an alternation with one empty
subexpression. So instead of this “(.+?)?” use this “(|.+?)” (without
the double quotes).

If there’s nothing matched by this group the empty subexpression
matches. Then an empty string is returned instead of a None and the sub
method is executed normally instead of raising the “unmatched group” error.

A complete description is in my post:
http://www.gp-net.nl/2008/07/11/solved-python-regex-raising-exception-unmatched-group/


Regards,

Gerard.

--
nosy: +gerardjp
title: Unmatched Group issue -> Unmatched Group issue - workaround

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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]>

___
___
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

[anatoly techtonik]

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]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3341] "Suggest a change" link

[anatoly techtonik]

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]>

___
___
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]

anatoly techtonik <[EMAIL PROTECTED]> added the comment:

Filed a proposal for online documentation editing tool.
http://bugs.python.org/issue3341

___
Python tracker <[EMAIL PROTECTED]>

___
___
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

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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 "", line 1, in 
  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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
assignee:  -> brett.cannon
nosy: +brett.cannon

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
nosy: +brett.cannon

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

I really hate how touchy the indentation output is for warnings/tracebacks.

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
assignee:  -> brett.cannon

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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]>

___
___
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

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
assignee: georg.brandl -> rhettinger
nosy: +rhettinger

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Committed as 64880.

--
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

Kuba Fast <[EMAIL PROTECTED]> added the comment:

I get no problem in 3.0b1. Should this be closed?

>>> parser.suite('"\u1234"')


--
nosy: +kfast

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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]>

___
___
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]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Corrected as r64881.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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]>
> 
> ___
>

___
Python tracker <[EMAIL PROTECTED]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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(), ...)

[Tal Einat]

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]>

___
___
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]

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]>

___
___
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

[Miki Tebeka]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
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]

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]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com