[issue4266] Python 3.0 docs are broken.
Georg Brandl [EMAIL PROTECTED] added the comment: Actually, that the build doesn't work is almost OK, because that seealso directive was invalid markup syntax (until very recently) :) Anyway, should be fixed now after a make update. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4266 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4236] Crash when importing builtin module during interpreter shutdown
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Christian, The initial example only works in interactive mode. To make your script crash, you have to set __builtins__._ = Crasher() There are several other places where Crasher() will crash on shutdown: sys.argv.insert(0, Crasher()) sys.ps1 = Crasher() sys.last_type = Crasher() sys.path_hooks.append(Crasher()) sys.path_importer_cache[''] = Crasher() But sys.meta_path.append(Crasher()) does not crash. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4277] asynchat's handle_error inconsistency
New submission from Giampaolo Rodola' [EMAIL PROTECTED]: Suppose you have tow sockets handled by two asynchat.async_chat class instances and from class1 you want to send some data through class2: class1(asynchat.async_chat): ... def mymethod(self): class2_instance.push_with_producer(producer) Since push_with_producer automatically calls initiate_send() if an error occurs while class2 reads the first chunk of data from the producer, class1's handle_error gets called. If the error occurs when reading the next chunks of data class2's handle_error will be called instead. This is an inconsistency that should be fixed so that always class2's handle_error gets called. The patch in attachment does that. -- components: Library (Lib) files: asynchat.patch keywords: patch messages: 75601 nosy: giampaolo.rodola, josiah.carlson, josiahcarlson severity: normal status: open title: asynchat's handle_error inconsistency type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file11959/asynchat.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4277 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4273] cycle created by profile.run
Winfried Plappert [EMAIL PROTECTED] added the comment: I tested profile_cycle.txt on both Python 2.5.2 and Python 2.6. The cycle you are showing for release 2.4.1 cannot be seen on both releases. Why dont't you try and upgrade to Python 2.6? -- nosy: +wplappert ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4279] Module 'parser' fails to build
Changes by David W. Lambert [EMAIL PROTECTED]: -- nosy: +LambertDW ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4279 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2306] Update What's new in 3.0
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- priority: deferred blocker - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2306 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append
David Turner [EMAIL PROTECTED] added the comment: FWIW, I see exposing bytecodes as an anti-pattern that locks in a particular implementation in a way that makes it hard to change and hard to port to other Python implementations. The current bound method approach works fine. Don't really see enough payoff to justify the extra code and maintenance. Bytecodes aren't exposed at the language level -- just during compilation. As far as I know, other implementations don't use any of the Python compiler mechanics, so there's no portability problem. If another compiler did use the Python AST, they could just compile the Append node kind to a method call with no loss of speed or clarity. Or they could just not use this optimization, if we refactor the ast optimizer as I propose to use the strategy pattern. As for the payoff, microbenchmarks show a big win. Also, appending to a list is a fairly common pattern. Our Plone-based codebase shows tens of thousands of instances of append. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4236] Crash when importing builtin module during interpreter shutdown
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- priority: deferred blocker - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4278] optparse quirks
New submission from Keith Briggs [EMAIL PROTECTED]:
I got the message:
optparse.OptionError: invalid long option string '-T0': must start with
--, followed by non-dash
This is bad - the real error was that I gave a short option which did
not have a single letter.
Also, it seems that add_option('--height-of-plot','-h') is not allowed,
because -h can only go with --help. How do I override this?
Keith
--
components: Extension Modules
messages: 75602
nosy: kbriggs
severity: normal
status: open
title: optparse quirks
type: behavior
versions: Python 2.5.3
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4278
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2306] Update What's new in 3.0
STINNER Victor [EMAIL PROTECTED] added the comment: PEP 352: Exceptions must derive from BaseException. This is the root of the exception hierarchy. I prefer to derive from Exception to be able to use exept Exception as: ... which doesn't catch SystemExit nor KeyboardInterrupt. PEP 3134: Exception chaining. (The __context__ feature from the PEP hasn’t been implemented yet in 3.0a2.) The feature is now implemented! PEP 237: long renamed to int. (...) sys.maxint was also removed since the int type has no maximum value anymore. What about the new sys.maxsize constant? Oh, it's written at the bottom, Removed sys.maxint. Use sys.maxsize. Both paragraphs should be merged. Optimizations (...) 33% slower (...) we expect to be optimizing string and integer operations significantly before the final 3.0 release! I don't expect significant changes before the final release. I worked on some patches about the int type (use base 2^30 instead of 2^15, GMP, etc.), but all patches optimize large integer (more than 1 digit, or more than 20 digits) whereas most integers in Python are very small. About str=unicode, I also don't expect changes. On character in now 4 bytes (or 2 bytes), whereas Python2 used 1 byte. This introduce an overhead. Most functions at C level use an conversion from byte string (ASCII) to Unicode (eg. PyErr_SetString). We should directly use wide string (eg. PyErr_SetWideString?). Porting to Python 3.0 This section is very small and gives few informations. There is nothing about 2to3 (just two references in the document). I also read somewhere that someone wrote a document explaining how to port a C extension to Python3. What about a link to the What's new in Python 2.6 document? Most people are still using Python 2.4 or 2.5. And Python3 is Python 2.5 + changes in Python 2.6 + changes in Python 3.0). -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2306 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4264] Patch: optimize code to use LIST_APPEND instead of calling list.append
David Turner [EMAIL PROTECTED] added the comment: Obviously if there's another sufficiently good argument for the visitor approach, I'm all ears. But again, if we do that I think we should do it for the compiler as well. I'm not sure how much support such a change would have. The argument is that it would be possible to enable or disable individual optimizations this way. For the compiler, there's no need for this, because there's only one thing to do per node type (although I suppose we could just pass that set of things into the node walker). Another argument against is that it would be harder to combine optimizations when that's relevant. I don't think it's worth worrying about until there are a dozen or so AST-level optimizations. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4277] asynchat's handle_error inconsistency
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- versions: +Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4277 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4273] cycle created by profile.run
Benjamin Peterson [EMAIL PROTECTED] added the comment: Let's mark this as out of date then. -- nosy: +benjamin.peterson resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4273] cycle created by profile.run
darrenr [EMAIL PROTECTED] added the comment: Issue also occurs in 2.6. Note that it only shows up if gc is set to save all cycles. -- versions: +Python 2.6 Added file: http://bugs.python.org/file11961/profile_cycle_26.txt ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4273] cycle created by profile.run
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- nosy: -benjamin.peterson resolution: out of date - status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3799] Byte/string inconsistencies between different dbm modules
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- priority: deferred blocker - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1656675] Drop-Handler for Python files
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I have now added a drop handler in r67149, r67150, and r67151. However,
I chose the wsh handler ({60254CA5-953B-11CF-8C96-00AA00B8708C}) instead
of the batch file one, as the wsh handler provides long file names,
whereas the batch file handler passes 8.3 names.
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1656675
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4280] Version Checker
New submission from Colin J. Williams [EMAIL PROTECTED]: Versions 2.5, 2.6 and 3.0 contain a Version Checker in the Tools directory. This appears to no longer serve a useful purpose. Perhaps it can be dropped from the distribution. Colin W -- components: Tests files: pyversioncheck.py messages: 75611 nosy: cjw severity: normal status: open title: Version Checker type: feature request versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11962/pyversioncheck.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4275] socketserver example code not correctly ported to py3k
Brad Miller [EMAIL PROTECTED] added the comment:
I found a similar problem in the Demo/sockets/unixclient.py code.
from socket import *
FILE = 'unix-socket'
s = socket(AF_UNIX, SOCK_STREAM)
s.connect(FILE)
s.send('Hello, world')
data = s.recv(1024)
s.close()
print('Received', repr(data))
Produces the following error message:
Traceback (most recent call last):
File unixclient.py, line 9, in module
s.send('Hello, world')
TypeError: send() argument 1 must be string or buffer, not str
My question is around whether the examples are wrong and 'Hello, World'
should simply be wrapped with bytearray('Hello, World','utf8') or
whether the underlying socket implementation is wrong. Judging by the
error message above it looks like the implementation is catching just
this kind of error and the example should be changed. But, this must
break backward compatibility all over the place. And since the bug has
release blocker it makes me think the socket implementation should be
changed.
--
nosy: +bmiller
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4275
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)
New submission from Vlastimil Brom [EMAIL PROTECTED]:
While experimenting with the new unicodedata for version 5.1 (many
thanks for it!) I discovered some strange behaviour of Idle with regard
to a character not available in any font on my system, namely Latin
capital letter sharp s - U+1E9E.
Cf. the following sessions:
Python 3.0rc2 (r30rc2:67141, Nov 7 2008, 11:43:46) [MSC v.1500 32 bit
(Intel)] on win32
Type copyright, credits or license() for more information.
...
IDLE 3.0rc2
print(\N{LATIN CAPITAL LETTER SHARP S})
ẞ
print(\N{LATIN CAPITAL LETTER S WITH CEDILLA})
Ş
print(\N{PHAGS-PA LETTER KA})
ꡀ
print(\ufff0)
hex(ord(ẞ))
'0x1e9e'
hex(ord(Ş))
'0x15e'
Of course, the exact view cannot be copied, but basically I see very
similar glyphs for the first two characters, while I had expected a
square-sign or something for the first one; this is what I get with
other surely unavailable glyph as well as a non existent character. See
the attached screenshot.
However, the characters remain clearly distinguished, as can be seen
e.g. after copying them as a parameter of ord(...).
Python 2.6 behaves the same way:
===
Python 2.6 (r26:66721, Oct 2 2008, 11:35:03) [MSC v.1500 32 bit
(Intel)] on win32
Type copyright, credits or license() for more information.
...
IDLE 2.6
print u\N{LATIN CAPITAL LETTER SHARP S}
ẞ
...
==
Not that it is much important, but I found it a bit surprising. I'm
using WinXPh SP3 Czech.
--
components: IDLE, Tkinter, Unicode
files: idle-capital-sharp-s.jpg
messages: 75613
nosy: vbr
severity: normal
status: open
title: Idle - incorrectly displaying a character (Latin capital letter sharp s)
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11963/idle-capital-sharp-s.jpg
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4281
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4246] execution model - clear and complete example in documentation
Terry J. Reedy [EMAIL PROTECTED] added the comment: Your example seem too verbose and diffuse. Perhaps something more focused on what people do wrong would be more helpful. I presume you mean something like this -- with or without x=2 before the def. def f(): print (x) x = 1 f() Traceback (most recent call last): File pyshell#31, line 1, in module f() File pyshell#30, line 2, in f print (x) UnboundLocalError: local variable 'x' referenced before assignment What are the other ways people get the error. -- nosy: +tjreedy ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4246 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4249] HTTPResponse instance has no attribute 'code'
Terry J. Reedy [EMAIL PROTECTED] added the comment: You should have edited the title and added a note here instead of opening a new issue to clarify that the problem is in urllib2.py. Anyway, closing this in favor of issue 4250 -- nosy: +tjreedy resolution: - duplicate status: open - closed superseder: - urllib2.py: HTTPResponse instance has no attribute 'code' ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4249 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4250] urllib2.py: HTTPResponse instance has no attribute 'code'
Terry J. Reedy [EMAIL PROTECTED] added the comment: This appears to be a duplicate of #1507166, with essentially the same title. I found it by searching all issues for response.code HTTPResponse. That was closed because The problem came from an external module (urlgrabber) which aparently was not up to date. -- nosy: +tjreedy resolution: - duplicate status: open - pending ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4262] import and compile() do not treat trailing whitespace the same
Terry J. Reedy [EMAIL PROTECTED] added the comment:
Both differences are covered in the 2.x docs:
When compiling multi-line statements, two caveats apply: line endings
must be represented by a single newline character ('\n'), and the input
must be terminated by at least one newline character.
The \r difference is not really a difference because \r is replaced by
\n before import starts compiling. I suspect that EOF effectively gets
converted to \n also. The doc issue is that 'must be terminated...' is
not always true.
This caveat is missing in 3.0, even though the limitation is the same.
see #4118.
I thought this was discussed in a c.l.p thread.
--
nosy: +tjreedy
resolution: - invalid
status: open - pending
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4262
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4118] Built-in compile() and ast module doc issues
Terry J. Reedy [EMAIL PROTECTED] added the comment: It appears that blanks on the last line also triggers a syntax error. See #4262. So the situation seems to be that the input must *sometimes* be terminated by . So adding 'sometimes' is the only change I would make, besides restoring the warning to the 3.0 docs. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Idle seems indeed to do a hard job to find a font that can display the
character.
On my machine (WinXP sp3, French) there are many fonts, but only Myriad
Web can display \N{LATIN CAPITAL LETTER SHARP S}.
I was surprised that the Character Map application does not display
it. To find which font was used to display this character, I used
Microsoft Word: paste the character (from Idle), select the text, open
the Font chooser dialog box, and scroll through the polices until it
displays correctly in the Preview pane.
--
nosy: +amaury.forgeotdarc
resolution: - works for me
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4281
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4275] socketserver example code not correctly ported to py3k
Brad Miller [EMAIL PROTECTED] added the comment: After looking at the socket documentation pointed to from another issue it looks like the right solution is to convert to a byte array. I've attached a patch with fixes for all the examples in socketserver.rst there were several other problems that I think were unrelated to Python 3.0 that I cleaned up in the process. -- keywords: +patch Added file: http://bugs.python.org/file11964/socketserverdoc.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4280] Version Checker
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)
Martin v. Löwis [EMAIL PROTECTED] added the comment: IDLE, in itself, doesn't do anything special to render that character. It passes it on to Tk. I don't know how precisely Tk works in this case, but it might be that it doesn't do anything special with the character *either*, but passes it on to Windows. FWIW, in this bug report, Firefox/Iceweasel, on Debian, renders the character as a small sharp s. This rendition appears to be correct, as the letter is supposed to look like the small letter, in principle. I can't see why Amaury says it works for him (there is surely something odd in the OP's system), I'm fairly confident that there is no bug in Python here. In particular, the unicodedata module has nothing to do with it. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4281 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1429539] pdb: fix for 1326406 (import __main__ pdb failure)
Alexander Belopolsky [EMAIL PROTECTED] added the comment: I am not sure whether it is appropriate to comment on a closed issue, but if the tracker will take this comment, hopefully it will find the right audience. I have recently stumbled on this bug running python 2.5. While tracking the problem down, I've noticed that some of the script running logic in pdb and runpy is replicated in some aspects and slightly different in others. Thus both pdb and runpy pop sys.argv[0], but (after this patch) pdb cleans __main__.__dict__ and repopulates it by executing the script while runpy replaces sys.modules['__main__'] with a fresh module and uses that module's namespace to run the script in. Furthemore, runpy injects __loader__ in the main namespace while pdb does not. While I cannot point out any specific problems (other than inability to debug applications in zipped packages with python -m pdb app.zip), I believe pdb should use the same logic and preferably the same code as runpy. Finally a nit: why does _runscript use run(execfile(filename)) instead of runcall(execfile, filename, gloabals_, locals_)? -- nosy: +belopolsky ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1429539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4118] Built-in compile() and ast module doc issues
Raymond Hettinger [EMAIL PROTECTED] added the comment: General comment: Stylistically, the docs should mostly be stated in a positive manner, stating what a tool does, how it should be used, and what is left undefined. IMO, it is harmful to fill the docs with CAVEATS and WARNINGS. -- nosy: +rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4281] Idle - incorrectly displaying a character (Latin capital letter sharp s)
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: My mistake, I did not know that SHARP S stands for the Eszett German letter. There is a font (Myriad Web on my system) that proposes a (wrong) glyph for this code point. According to http://www.tcl.tk/software/tcltk/whatsnew.tml#i18n Tk guarantees to find a way to display any Unicode character regardless of the font you selected, as long as there is some font in the system that contains the Unicode character but Tk does not guarantee that the font will display the correct character... -- resolution: works for me - status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4281 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3073] Cookie.Morsel breaks in parsing cookie values with whitespace
Changes by Trent Mick [EMAIL PROTECTED]: -- nosy: +trentm ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3073] Cookie.Morsel breaks in parsing cookie values with whitespace
mixedpuppy [EMAIL PROTECTED] added the comment:
The problem is that spaces are not allowed in the attribute values.
Here is a work around
# hack fix of Cookie.BasicCookie
import Cookie
import re
_LegalCharsPatt = r\w\d!#%'~_`@,:/\$\*\+\-\.\^\|\)\(\?\}\{\=
_FixedCookiePattern = re.compile(
r(?x) # This is a Verbose pattern
r(?Pkey # Start of group 'key'
[+ _LegalCharsPatt +]+? # Any word of at least one letter,
nongreedy
r) # End of group 'key'
r\s*=\s*# Equal Sign
r(?Pval # Start of group 'val'
r'(?:[^\\]|\\.)*'# Any doublequoted string
r|# or
[+ _LegalCharsPatt +\ ]*# Any word or empty string
r) # End of group 'val'
r\s*;? # Probably ending in a semi-colon
)
class FixedCookie(Cookie.SimpleCookie):
def load(self, rawdata):
Load cookies from a string (presumably HTTP_COOKIE) or
from a dictionary. Loading cookies from a dictionary 'd'
is equivalent to calling:
map(Cookie.__setitem__, d.keys(), d.values())
if type(rawdata) == type():
self._BaseCookie__ParseString(rawdata, _FixedCookiePattern)
else:
self.update(rawdata)
return
--
nosy: +mixedpuppy
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3073
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4118] Built-in compile() and ast module doc issues
Terry J. Reedy [EMAIL PROTECTED] added the comment:
The 2.6 sentence that got deleted in 3.0:
I at least somewhat agree.
When compiling a string with multi-line statements, two caveats apply:
line endings must be represented by a single newline character ('\n'),
and the input must be terminated by at least one newline character.
could have two caveats apply deleted to be more positive. I would
prefer the following simpler, direct use instruction.
When compiling a string with multi-line statements, terminate all lines
with a single newline character ('\n').
This issue came up both in c.l.p discussion and again in invalid #4262
(whose author apparently missed the current sentence).
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4118
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4282] (Python3) The profile module deesn't understand the character set definition
New submission from Takafumi SHIDO [EMAIL PROTECTED]: The profile module of Python3 deesn't understand the character set of the script. When a profile is executed (like $python -m profile -o prof.dat foo.py) on a code (say foo.py) which defines its character set in the second line (like #coding:utf-8), the profile crashes with an error message like: SyntaxError: unknown encoding: utf-8 -- messages: 75627 nosy: shidot severity: normal status: open title: (Python3) The profile module deesn't understand the character set definition type: crash versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4282 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4071] ntpath.abspath fails for long str paths
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: Fixed unicode issue in r67154(trunk). I'm not sure how to handle long str, so I didn't touch it for now. -- versions: +Python 2.5.3, Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4071 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
