[issue24204] string.strip() documentation is misleading
New submission from Jim:
This probably applies to all versions with the strip() method, but I'm using
3.4. Section 4.7.1 of the documentation has a poorly worded description/example
for the behaviour of string.strip([chars]).
A casual reading of "The chars argument is not a prefix or suffix; rather, all
combinations of its values are stripped" lead me to believe this
>>> '0.0'.strip('.')
'0.0'
should be equivalent to the solution I found later
>>> '0.0'.replace('.', '')
'00'
The bit about [chars] requires recursive thinking ("are _stripped_") and clouds
the fact that strip() iterates from beginning and end, discarding characters
until it reaches a character that isn't in [chars].
In the example, it's not obvious (or wasn't to me) that the 'm' wasn't removed
from 'example', and the missing periods gave the impression that they had been
removed from the middle of the string instead of iterated to from the ends.
I can't think of a good way to rewrite the description, but perhaps you could
borrow an example from rstrip() and add/replace:
>>> 'mississippi'.strip('mip')
'ssiss'
The glaring existence of that 'i' in the middle, when all others have been
removed makes the limitation clear.
>>> 'hello world'.strip()
'hello world'
Makes another good example.
Just trying to save someone else 20 minutes of confusion.
--
assignee: docs@python
components: Documentation
messages: 243283
nosy: PhoenixofMT, docs@python
priority: normal
severity: normal
status: open
title: string.strip() documentation is misleading
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue24204>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24204] string.strip() documentation is misleading
Jim added the comment: Maybe, "... all combinations of its values are stripped from the beginning and end." It is rather difficult to be both clear AND concise. Heck, I'm having trouble just trying to explain it. Mark, that part is clear, but I think somehow reiterating how the method works would be helpful to someone who is only familiar with a handful of the string methods, knows strip() removes characters, sees that several characters can be specified, and assumes that all such characters will be removed. As it is, it's sort of like a puzzle that's glaringly obvious once you figure it out, but frustrating in proportion to the amount of time spent figuring. Almost more trouble to figure out how to explain it without turning it into a tutorial than it is to sort it out on your own at the console. -- ___ Python tracker <http://bugs.python.org/issue24204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
New submission from Jim Schwartz : Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not. I've enclosed sample scripts that compare the two and have returned the results. the windows 10 registry entry to extend the path names fixes this issue (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled set to 1). I've enclosed a scripts that proved this occurs and can be used for testing. I have a script that does the same thing using os_walk, but I can't attach two scripts to this Issue. -- components: IO, Tests, Windows files: test_dir_scan_dir.py messages: 408607 nosy: jschwar313, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not type: crash versions: Python 3.9 Added file: https://bugs.python.org/file50492/test_dir_scan_dir.py ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
Jim Schwartz added the comment: Here's the second file that works just fine under python 3.9 (by the way, I am using Windows 64-bit). I didn't test this on later python versions, however, nor did I test it on 32-bit versions. I see that many people on the internet have said to change the working directory as a work around. Could this possibly be why? -- Added file: https://bugs.python.org/file50493/test_os_walk.py ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
Jim Schwartz added the comment: yes, I do. C:\Users\Jim\Documents\jschw_uiowtv3_old\AppData\Local\Google\Chrome\User Data\Default\Extensions\nenlahapcbofgnanklpelkaejcehkggg\0.1.823.675_0\notifications\pages\Cashback\components\CashBackResolve\components\RewardsActivation\components\CashbackSectionSimple it's over the 260 character limit that's the default for windows 10. -- ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
Jim Schwartz added the comment: do you have this registry entry set to 1: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled set to 1. It works if you do. What version of windows do you have? I have version 21H2 (OS Build 19044.1387). I don't have windows 11 yet. -- ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
Jim Schwartz added the comment: the issue is with the scandir script, not the os_walk script. I tried to upload the scandir python script before, but I guess it didn't upload. When I was running the two scripts, I used an input of C:\\ as the input parameter. Hope that helps. -- Added file: https://bugs.python.org/file50495/test_dir_scan_dir.py ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
Jim Schwartz added the comment: when I run the following command: python "H:\Users\LindaJim\Documents\AWS Python Learning\test_dir_scan_dir.py" "C:\\" I get this output: ... Traceback (most recent call last): File "H:\Users\LindaJim\Documents\AWS Python Learning\test_dir_scan_dir.py", line 54, in main(sys.argv[0:]) File "H:\Users\LindaJim\Documents\AWS Python Learning\test_dir_scan_dir.py", line 30, in main for file in get_files_in_dir(source): File "H:\Users\LindaJim\Documents\AWS Python Learning\test_dir_scan_dir.py", line 11, in get_files_in_dir yield from get_files_in_dir(entry.path) File "H:\Users\LindaJim\Documents\AWS Python Learning\test_dir_scan_dir.py", line 11, in get_files_in_dir yield from get_files_in_dir(entry.path) File "H:\Users\LindaJim\Documents\AWS Python Learning\test_dir_scan_dir.py", line 11, in get_files_in_dir yield from get_files_in_dir(entry.path) [Previous line repeated 19 more times] File "H:\Users\LindaJim\Documents\AWS Python Learning\test_dir_scan_dir.py", line 9, in get_files_in_dir for entry in os.scandir(source): FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\Users\\Jim\\Documents\\jschw_uiowtv3_old\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Extensions\\nenlahapcbofgnanklpelkaejcehkggg\\0.1.823.675_0\\notifications\\pages\\Cashback\\components\\CashBackResolve\\components\\RewardsActivation\\components\\CashbackSectionSimple' when I run the following command: python "H:\Users\LindaJim\Documents\AWS Python Learning\test_os_walk.py" "C:\\" I get this: ... file is C:\winutils\bin\winutils.exe End time is 2021-12-15.13:11:54 Duration is 0:06:05 I don't think this should happen, right? -- ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
Jim Schwartz added the comment: my c drive and h drive are both internal drives and I run the python script from my user directory on my c drive. Not sure if that makes any difference. Just trying to think of things that might help you reproduce and fix this. -- ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46084] Python 3.9.6 scan_dir returns filenotfound on long paths, but os_walk does not
Jim Schwartz added the comment: Please let me know if you are able to reproduce this issue. -- ___ Python tracker <https://bugs.python.org/issue46084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1778443] robotparser.py fixes
Jim Jewett added the comment: On line 108 (new 104), spaces should probably be added on both sides of the comparison operator, instead of only after the ">=". The "%s" changes might end up getting changed again as part of 2to3, but this is a clear improvement over status quo, particularly with the loops. I recommend applying. -- nosy: +jimjjewett _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1778443> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1177] urllib* 20x responses not OK?
New submission from Jim Jewett : Under the http protocol, any 2xx response is OK. urllib.py and urllib2.py hardcoded only response 200 (the most common). http://bugs.python.org/issue912845 added 206 as acceptable to urllib2, but not any other 20x responses. (It also didn't fix urllib.) Suggested for 2.6, as it does change behavior. (Also see duplicate http://bugs.python.org/issue971965 which I will try to close after opening this. ) -- components: Library (Lib) messages: 56009 nosy: jimjjewett severity: normal status: open title: urllib* 20x responses not OK? type: behavior versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1177> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1177] urllib* 20x responses not OK?
Jim Jewett added the comment: Jafo: His fix is great for urllib2, but the same issue applies to the original urllib. The ticket should not be closed until a similar fix is made to lines 330 and 417 of urllib.py. That is, change "if errcode == 200:" to "if 200 <= errcode < 300:" (Or, if rejecting the change, add a comment saying that it is left that way intentionally for backwards compatibility.) -jJ __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1177> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1177] urllib* 20x responses not OK?
Jim Jewett
added the comment:
The change still missed
the httpS copy. I'm
attaching a minimal change.
I think it might be better
to just combine the
methods -- as was already
done in Py3K.
Unfortunately, the py3K
code doesn't run cleanly
in 2.5, and I haven't yet
had a chance to test a
backported equivalent.
(Hopefully tonight.)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1177>
__*** urllibhead.py
--- urllib.py
***
*** 435,441
# something went wrong with the HTTP status line
raise IOError, ('http protocol error', 0,
'got a bad status line', None)
! if errcode == 200:
return addinfourl(fp, headers, "https:" + url)
else:
if data is None:
--- 435,443
# something went wrong with the HTTP status line
raise IOError, ('http protocol error', 0,
'got a bad status line', None)
! # According to RFC 2616, "2xx" code indicates that the client's
! # request was successfully received, understood, and accepted.
! if not (200 <= errcode < 300):
return addinfourl(fp, headers, "https:" + url)
else:
if data is None:
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1209] IOError won't accept tuples longer than 3
New submission from Jim Jewett : EnvironmentError (including subclass IOError) has special treatment when constructed with a 2-tuple or 3-tuple. A four-tuple turns off this special treatment (and was used by urllib for that reason). As of 2.5, a four-tuple raises a TypeError instead of just turning off the special treatment. -- components: Extension Modules messages: 56150 nosy: jimjjewett severity: normal status: open title: IOError won't accept tuples longer than 3 type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1209> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1401] urllib2 302 POST
Jim Jewett added the comment: > But you said that #2 solution was more RFC compliant... > Could you please quote the RFC part that describes this behaviour? RFD2616 http://www.faqs.org/rfcs/rfc2616.html section 4.3 Message Body ... The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. [I couldn't actually find a quote saying that GET has no body, but ... it doesn't.] Section 10.3 Redirection 3xx says The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. In other words, changing it to GET may not be quite pure, but leaving it as POST would technically mean that the user MUST confirm that the redirect is OK. This MUST NOT becomes more explicit later, such as in 10.3.2 (301 Moved Permanently). Section 10.3.3 (302 Found) says that 307 was added specifically to insist on keeping it a POST, and even 307 says it MUST NOT automatically redirect unless it can be confirmed by the user. Which is why user agents change redirects to a GET and try that... -- components: +XML -None nosy: +jimjjewett __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1401> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1501] 0 ** 0 documentation
New submission from Jim Jewett: http://docs.python.org/lib/typesnumeric.html contains a table listing the mathematical operators. Please add a note to the final row (x ** y meaning x to the power y) indicating that Python has chosen to define 0**0==1 Note 6: Python defines 0**0 to be 1. For background, please see http:// en.wikipedia.org/wiki/Exponentiation#Zero_to_the_zero_power This doc change should have prevented issue 1461; I *think* there have been similar issues in the past. -- components: Documentation messages: 57855 nosy: jimjjewett severity: minor status: open title: 0 ** 0 documentation type: rfe versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1501> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
New submission from Jim Jewett : The implementation has a larger state.kind Clarified wording on wstr_length and surrogate pairs. Clarified that the canonical "data" format doesn't always have a data pointer. Mentioned that calling PyUnicode_READY would finalize a string, so that it couldn't be resized. Changed section head "Other macros" to "Finalization macro" and removed the non-existent PyUnicode_CONVERT_BYTES (there is a similarly named private macro). -- files: pep-0393.txt.patch keywords: patch messages: 149497 nosy: Jim.Jewett priority: normal severity: normal status: open title: update PEP 393 (match implementation) Added file: http://bugs.python.org/file23960/pep-0393.txt.patch ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
Changes by Jim Jewett : -- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.3 Added file: http://bugs.python.org/file23961/pep-0393.txt ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
Changes by Jim Jewett : Added file: http://bugs.python.org/file23968/pep-0393.txt ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
Jim Jewett added the comment: Updated to resolve most of Victor's concerns, but this meant enough changes that I'm not sure it quite counts as editorial only. A few questions that I couldn't answer: (1) Upon string creation, do we want to *promise* to discard the UTF-8 and wstr, so that the caller can memory manage? (2) PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp seemed to be there in the code I was looking at. (3) I can't justify the born-deprecated function "PyUnicode_AsUnicodeAndSize". Perhaps rename it with a leading underscore? Though I'm not sure it is really needed at all. (4) I tried to reword the "for compatibility" ... "redundant" part ... but I'm not sure I resolved it. -- ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
Jim Jewett added the comment: >> So even if a third party module uses the legagy Unicode API, the PEP >> 393 will still optimize the memory usage thanks to implicit calls to >> PyUnicode_READY() (done everywhere in Python source code). > ... unless they inspect a given Unicode string, in which case it > will use twice the memory (or 1.5x). Why is the utf-8 representation not cached when it is generated for ParseTuple et alia? It seems like these parameters are likely to either be re-used as parameters (in which case caching makes sense) or not re-used at all (in which case, the whole string can go away). > Well, I meant the resizing of strings that doesn't move the object > in memory (i.e. unicode_resize). This may easily fail because the new size can't be found at that location; wouldn't it be better to just encourage proper sizing in the first place? >> (1) Upon string creation, do we want to *promise* to discard >> the UTF-8 and wstr, so that the caller can memory manage? > I don't understand the question. Assuming "discards" means > "releases" here, then there is no API which releases memory > during creation of the string object - let alone that there is > any promise to do so. I'm also not aware of any candidate buffer > that you might want to release. When a string is created from a wchar_t array, who is responsible for releasing the original wchar_t array? As I read it now, Python doesn't release the buffer, and the caller can't because maybe Python just pointed to it as memory shared with the canonical representation. >> (2) PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp >> seemed to be there in the code I was looking at. > That's very well possible. What's the question? Victor listed them as missing. I now suspect he meant "missing from the PEP list of deprecated functions and macros", and I just misunderstood. -- Added file: http://bugs.python.org/file23970/pep-0393.txt ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
Changes by Jim Jewett : Added file: http://bugs.python.org/file23971/pep-0393v20111215.patch ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13608] remove born-deprecated PyUnicode_AsUnicodeAndSize
New submission from Jim Jewett : In reviewing issue 13604 (aligning PEP 393 with the implementation) Victor Stinner noticed that PyUnicode_AsUnicodeAndSize is new in 3.3, but that it is already deprecated (because it relies on the old PyUnicode type). This born-deprecated function is just a shortcut for PyUnicode_AsUnicode plus PyUnicode_GET_SIZE, and should be removed. -- components: Unicode messages: 149585 nosy: Jim.Jewett, ezio.melotti priority: normal severity: normal status: open title: remove born-deprecated PyUnicode_AsUnicodeAndSize versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13608> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
Jim Jewett added the comment: >> Why is the utf-8 representation not cached when it is generated for >> ParseTuple et alia? My error -- I read something backwards. >> When a string is created from a wchar_t array, who is responsible for >> releasing the original wchar_t array? > The caller. OK, I'll document that. >> As I read it now, Python >> doesn't release the buffer, and the caller can't because maybe Python >> just pointed to it as memory shared with the canonical >> representation. > But Python won't; it will always make a copy for itself. I thought I found an example each way, but it is possible that the shared version was something python had already copied. If not, I'll raise that as a separate issue to get the code changed. (Note that I may not be able to look at this again until after Christmas, so I'm likely to go silent for a while.) -- Added file: http://bugs.python.org/file23979/pep-0393.txt ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13604] update PEP 393 (match implementation)
Changes by Jim Jewett : Added file: http://bugs.python.org/file23980/pep-0393_20111216.txt.patch ___ Python tracker <http://bugs.python.org/issue13604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13677] correct docstring for builtin compile
New submission from Jim Jewett : The current docstring for compile suggests that the flags are strictly for selecting future statements. These are not the only flags. It also suggests that the source must be source code and the result will be bytecode, which isn't quite true. I suggest changing: "The flags argument, if present, controls which future statements influence the compilation of the code." to: "The flags argument, if present, largely controls which future statements influence the compilation of the code. (Additional flags are documented in the AST module.)" -- assignee: docs@python components: Documentation files: bltinmodule.c.patch keywords: patch messages: 150337 nosy: Jim.Jewett, docs@python priority: normal severity: normal status: open title: correct docstring for builtin compile type: behavior Added file: http://bugs.python.org/file24105/bltinmodule.c.patch ___ Python tracker <http://bugs.python.org/issue13677> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13677] correct docstring for builtin compile
Jim Jewett added the comment: I'm not sure we're looking at the same thing. I was talking about the docstring that shows up at the interactive prompt in response to >>> help(compile) Going to hg.python.org/cpython and selecting branches, then default, then browse, got me to http://hg.python.org/cpython/file/7010fa9bd190/Python/bltinmodule.c which still doesn't mention AST. I also don't see any reference to "src" or "dst", or any "source" that looks like it should be capitalized. I agree that there is (to my knowledge, at this time) only one additional flag. I figured ast or future was needed to get the compilation constants, so it made sense to delegate -- but you seem to be reading something newer than I am. -- ___ Python tracker <http://bugs.python.org/issue13677> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13776] formatter_unicode.c still assumes ASCII
New submission from Jim Jewett :
http://docs.python.org/library/string.html#format-specification-mini-language
defines
fill::=
and the text also excludes '{'. It does not require that the fill character be
ASCII.
However, function parse_internal_render_format_spec
http://hg.python.org/cpython/file/c2153ce1b5dd/Python/formatter_unicode.c#l277
raises a ValueError if fill_char > 127.
I'm honestly not certain which of the three is correct, but they should be
consistent, and if anything but '{' is excluded, it would be best to explain
why.
--
components: Unicode
messages: 151128
nosy: Jim.Jewett, ezio.melotti
priority: normal
severity: normal
status: open
title: formatter_unicode.c still assumes ASCII
type: behavior
___
Python tracker
<http://bugs.python.org/issue13776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12736] Request for python casemapping functions to use full not simple casemaps per Unicode's recommendation
Jim Jewett added the comment: The currently applied patch ( http://hg.python.org/cpython/rev/f7e05d205a52 ) left some dead code in unicodeobject.c function fixup ( http://hg.python.org/cpython/file/f7e05d205a52/Objects/unicodeobject.c#l9386 ) has a shortcut for when the fixer doesn't make any actual changes. The removed fixers (like fixupper ) returned 0 rather than maxchar to indicate that. The only remaining fixer, fix_decimal_and_space_to_ascii (line 8839), does not. (I think fix_decimal_and_space_to_ascii *should* add a touched flag, but until it does, the shortcut dedup code is dead.) Also, around line 10502, there is an #if 0 section with code that relied on one of the removed fixers; is it time to remove that section? -- nosy: +Jim.Jewett ___ Python tracker <http://bugs.python.org/issue12736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used as a type, but has not been defined as a type
Jim Schneider added the comment: Martin - provides a definition for mbstate_t only (at least on HP/UX 11i V2.0). I can verify that the problem still exists for Python 3.2.1. I am working on a workaround for this issue, and I will attach a patch once I get it to build. -- nosy: +jschneid ___ Python tracker <http://bugs.python.org/issue5999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)
New submission from Jim Schneider : In Modules/getpath.c, the following line (#138) causes problems with some compilers (HP/UX 11, in particular - there could be others): static wchar_t *lib_python = L"lib/python" VERSION; Similarly, line #644: module_search_path = L"" PYTHONPATH; The default HP/UX compiler fails to compile this file with the error "Cannot concatenate character string literal and wide string literal". The attached patch converts these two string literals to wide string literals that the HP/UX compiler can understand. Very limited testing indicates that the patch is benign (it does not affect the build on Linux running on x86_64). -- components: Build files: getpath.patch keywords: patch messages: 140348 nosy: jschneid priority: normal severity: normal status: open title: Compiler workaround for wide string constants in Modules/getpath.c (patch) type: compile error versions: Python 3.2 Added file: http://bugs.python.org/file22655/getpath.patch ___ Python tracker <http://bugs.python.org/issue12561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used as a type, but has not been defined as a type
Jim Schneider added the comment: I got it to build on HP-UX 11. However, there are a lot of compiler warnings about type mismatches, the _ctypes, _multiprocessing and termios modules failed to build, and "make test" died after not finding a usable "binascii" module. To get it to build, I did the following: 1) Applied the patch I attached to issue 12561 2) Created a directory sys, and copied /usr/include/sys/stdsyms.h into it. 3) Did "chmod 644" on sys/stdsyms.h and applied the patch stdsyms.patch that I've attached to this issue to it. 4) Ran configure with the argument "CPPFLAGS=-I." At this point, make ran to completion, and produced a python binary. However, "make test" dies within seconds of starting up. -- keywords: +patch Added file: http://bugs.python.org/file22656/stdsyms.patch ___ Python tracker <http://bugs.python.org/issue5999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used as a type, but has not been defined as a type
Jim Schneider added the comment: Martin - sys/_mbstate.h is only included if _INCLUDE__STDC_A1_SOURCE is defined. The only way this gets defined in the vendor-provided include files is if _XOPEN_SOURCE is defined and is equal to 500, or __STDC_VERSION__ is defined and is greater than or equal to 199901. I've attached a patch to broaden the _XOPEN_SOURCE case (as the test should clearly have been >=, not ==). Defining __STDC_VERSION__ to 199901 or greater will also do the job, but it feels more like a hack than just fixing what's broken in the vendor include files. -- ___ Python tracker <http://bugs.python.org/issue5999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)
Jim Schneider added the comment: The __W macro is needed because the token-pasting operator binds to the macro's argument immediately; Having WCHAR(y) expand to __W(y) means that __W is passed WCHAR's argument after it's been macro-expanded. Without the intermediate step, WCHAR(VERSION) becomes LVERSION. As for the name - I have no objection to reasonable name changes. I picked WCHAR because it converts its argument to a wchar_t *. Finally - I am aware that the HP/UX C compiler is broken. Unfortunately, I am required to work with it, and can neither replace it nor ignore it. -- ___ Python tracker <http://bugs.python.org/issue12561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used as a type, but has not been defined as a type
Jim Schneider added the comment: Yes, it is a patch to an HP-provided C compiler system header file. I cannot provide the actual file it patches, due to copyright limitations. -- ___ Python tracker <http://bugs.python.org/issue5999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)
Jim Schneider added the comment: I am attaching an updated patch. This version specifically checks for __hpux, and the macro name has been changed to avoid clashing with other uses. -- Added file: http://bugs.python.org/file22663/getpath.patch ___ Python tracker <http://bugs.python.org/issue12561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
New submission from Jim Schneider : The C compiler that comes with HP/UX 11 has some shortcomings that prevent building Python 3.2.1 out of the box. I am attaching patches here as I work through issues. The first patch fixes namespace shortcomings when trying to use struct termios. -- components: Build files: termios.patch keywords: patch messages: 140423 nosy: jschneid priority: normal severity: normal status: open title: HP/UX compiler workarounds type: compile error versions: Python 3.2 Added file: http://bugs.python.org/file22664/termios.patch ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)
Jim Schneider added the comment: I am collecting HP/UX compiler bug workarounds in issue 12572. Stinner - is the patch you mentioned in a released version of Python 3.2? Also, how is it affected by the fact that the (wide char) strings in question are constants? -- ___ Python tracker <http://bugs.python.org/issue12561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is used as a type, but has not been defined as a type
Jim Schneider added the comment: I am collecting HP/UX compiler workarounds in issue 12572. I will be adding patches to it as I produce them, including a patch to fix this on HP/UX. -- ___ Python tracker <http://bugs.python.org/issue5999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: This patch works around the problem underlying issue 5999 by making sure the __STDC_VERSION__ macro is defined and has a value of at least 199901 -- Added file: http://bugs.python.org/file22666/fileutils.patch ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: Workaround for compiler bug; HP/UX compiler refuses to past (implicitly char *) string constants with wide (wchar_t *) string constants. This patch is also pasted to issue 12561 (which should be closed). Note: There is disagreement as to the best way to proceed on this issue. Stinner (aka haypo) has a patch that should work with non ASCII character sets, and my patch will almost certainly not work in those cases. YMMV. -- Added file: http://bugs.python.org/file22668/getpath.patch ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: This patch just reduces compiler noise by explicitly casting pointers to void *. I expect the Visual Studio C/C++ compiler suite also issued these warnings, too. -- Added file: http://bugs.python.org/file22669/typeobject.patch ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: Sorry - last comment should have been "compiler refuses to past*e*", not "past". -- ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: The HP/UX C compiler grumbles when a symbol that is declared static is later defined without the static storage class specifier. The attached patch just adds the missing "static" keywords. -- Added file: http://bugs.python.org/file22670/Python-ast.patch ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: I'm adding the original listeners for issue 5999 to this one. The fileutils.patch patch attached to this issue directly addresses what's wrong in issue 5999; I'd consider it closed, but as I didn't open it, and I'm not actually part of the python project, that's not my call to make. -- nosy: +eric.araujo, loewis, srid, terry.reedy ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: >From issue 12561 (which I will be closing): Author: STINNER Victor (haypo) * Date: 2011-07-15 15:36 Use >L"" CONSTANT< to decode a byte string to a character string doesn't work with non-ASCII strings. _Py_char2wchar() should be used instead: see for example this fix, commit 5b6e13b6b473. This is in reference to getpath.patch. I have no need to support internationalized versions of the constant strings my patch addresses, so Stinner's commit is overkill for me. -- ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12561] Compiler workaround for wide string constants in Modules/getpath.c (patch)
Jim Schneider added the comment: Constant initializers are required to be constants, not function calls, so _Py_char2wchar cannot be used in the definition of lib_python (line #138 of Modules/getpath.c). -- ___ Python tracker <http://bugs.python.org/issue12561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: Update to getpath.patch (issue 12561) - this version uses _Py_char2wchar where possible. Unfortunately, as lib_python is declared and defined statically, this can't be used in both cases where the HP/UX compiler has issues. -- Added file: http://bugs.python.org/file22671/getpath.patch ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: Terry - I apologize for jumping the gun a bit, and let me be a bit more clear. When I realized that the HP/UX compiler was going to have as many problems as it does compiling python 3, I decided it would be best to create a single issue for all of the compiler issues. In retrospect, opening an issue for the single compiler bug discussed in issue 12561 was a mistake, and I had hoped to migrate the discussion of that issue here. -- ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12572] HP/UX compiler workarounds
Jim Schneider added the comment: Martin - I don't have time to manage your project's administrative requirements with respect to my fixes. I'm providing them out of the hope they will be of use to others who need to build on HP/UX, but I don't really care if they make it into the main branch or not. -- ___ Python tracker <http://bugs.python.org/issue12572> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9734] ABC issubclass/isinstance leaks in Python 2
New submission from Jim Fulton : I assume ABCs use some sort of cache for issubclass checks. I also assume the cache doesn't use weakrefs, leading to leaks in classes created on the fly (as is common in tests). The attached script demonstrates the leak. The leak doesn't seem to occur in Python 3.1.2. -- files: abc_issubclass_leak.py messages: 115323 nosy: j1m priority: normal severity: normal status: open title: ABC issubclass/isinstance leaks in Python 2 versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file18703/abc_issubclass_leak.py ___ Python tracker <http://bugs.python.org/issue9734> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9736] doctest.DocTestSuite doesn't handle test globs correctly
New submission from Jim Fulton : We often run test suites repeatedly using a debug build of python to look for memory leaks. We also got in the bad habit of using a fork of doctest. Recently, we've switched away from our fork and have noticed a problem with the standard doctest's handling of test globs (globals). DocTestSuite gets an initial set of globals from the module the doctest's came from. After running the tests, it seems to clear these, leading to errors if the tests are run again. I've attached a script that illustrates the problem. The script runs a simple test twice and gets a spurious failure the second time. -- components: Library (Lib) files: doctest_DocTestSuite_globs_breakage.py messages: 115326 nosy: j1m priority: normal severity: normal status: open title: doctest.DocTestSuite doesn't handle test globs correctly versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1 Added file: http://bugs.python.org/file18704/doctest_DocTestSuite_globs_breakage.py ___ Python tracker <http://bugs.python.org/issue9736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9736] doctest.DocTestSuite doesn't handle test globs correctly
Jim Fulton added the comment: On Tue, Nov 2, 2010 at 5:55 PM, Éric Araujo wrote: > > Éric Araujo added the comment: > > Would you like to work on a patch? Sure. Jim -- ___ Python tracker <http://bugs.python.org/issue9736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9435] test_distutils fails without zlib
Jim Pharis added the comment: I think this is a dup of #6026 which is fixed... svn log for Lib/distutils... #6026: skip test_get_file_list when zlib is not available. this test requires zlib support #6026 - fix tests that failed without zlib -- nosy: +binbrain ___ Python tracker <http://bugs.python.org/issue9435> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7804] test_readline failure
Jim Pharis added the comment: Unable to recreate this in Ubuntu 10.04 w/3.2 alpha 4. Tried with and without readline lib installed. -- nosy: +binbrain ___ Python tracker <http://bugs.python.org/issue7804> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10576] Add a progress callback to gcmodule
Jim Jewett added the comment: I like the idea, but I do quibble with the signature. As nearly as I can tell, you're assuming (a) Only one callback. I would prefer a sequence of callbacks, to make cooperation easier. (This does mean you would need a callback removal, instead of just setting it to None.) (b) The callback will be called once before collecting generations, and once after (with the number of objects that weren't collected). Should these be separate callbacks, rather than the same one with a boolean? And why does it need the number of uncollected objects? (This might be a case where Practicality Beats Purity, but it is worth documenting.) -- nosy: +jimjjewett ___ Python tracker <http://bugs.python.org/issue10576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10576] Add a progress callback to gcmodule
Jim Jewett added the comment: Does anyone think that it is simpler to register two different callbacks than one? Moderately, yes. Functions that actually help with cleanup should normally be run only in one phase; it is just stats-gathering and logging functions that might run both times, and I don't mind registering those twice. For functions that are run only once (which I personally think is the more normal case), the choices are between @register_gc def my_callback(actually_run_flag, mydict): if not actually_run_flag: return ... vs @register_gc_before def my_callback(mydict): ... -- ___ Python tracker <http://bugs.python.org/issue10576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment: Talk about tunnel vision... The code is right next to it! It is the include paths that are growing without bound (and presumably the LIBPATH as well). The test case is the Cython unit tests. They run until the include variable generates a "line too long" error. The normalize_and_reduce_paths() function needs to be performed on INCLUDE and LIBPATH in addition to the exec path. i.e. os.environ['lib'] and os.environ['include']. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment: In this file: http://svn.python.org/view/python/trunk/Lib/distutils/msvc9compiler.py?rev=62636&view=auto Notice the line containing: os.environ['include'] = vc_env['include'] This causes the process environment variables to acquire the value returned by vcvars.bat. Since vcvars.bat appends it's values to the environment variable, it grows each time called. Note that the submitted patch does make this problem go away. A better patch could combine the two functions or and treat them consistently. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment: Actually, now that I think about it a little more, it seems like "very bad practice" to change the process environment variables as a side effect. A better solution would be to keep a variable for the required ones that is modified as necessary. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3025] batch/IDLE differ: print broken for chraracters>ascii
New submission from Jim Jewett <[EMAIL PROTECTED]>: The str->Unicode change widened IDLE/batch discrepancy. In python 2.x, bytes are printable. >>> for i in range(256): print i, chr(i) works fine. In python 3, chr has become (the old) unichr, and whether a unicode character is printable depends on the environment. In particular, under my Windows XP, the equivalent >>> for i in range(256): print (i, chr(i)) will still work fine under IDLE, but will now crash with an UnicodeEncodeError when run from the command line. Unfortunately, I'm not sure what the right solution actually is, other than a mention in the Whats New document. I believe the 2.5 code was using a system page to print those characters, as they often looked like letters rather than . Copying that would probably be the wrong solution. Limiting IDLE would add consistency, but might be a lot of work for the equivalent of a --pedantic flag. PEP 3138 seems to be proposing a default stdout BackslashReplace, which may at least help. -- assignee: georg.brandl components: Documentation, Unicode messages: 67617 nosy: georg.brandl, jimjjewett severity: normal status: open title: batch/IDLE differ: print broken for chraracters>ascii type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3025> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue775544] Tk.quit leads to crash in python.exe
Jim Jewett <[EMAIL PROTECTED]> added the comment: Were you using IDLE at the time? When I try this (Windows XP SP2), the button and its window do not go away (which is arguably a bug), but it does not crash. If I then try to close the window using the little X (from the window manager), (1) A qb started from the command-line interface exits, as it should. (2) A qb started from within IDLE becomes non-responsive, and Windows asks whether or not I want to continue shutting it down. -- nosy: +jimjjewett ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue775544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment: Any new thoughts on this? I had to patch my local copy again after a reinstall. It would be nice to fix it upstream. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment:
Sorry, posted too quickly.
Actually, the problem was a little different.
There was an environment variable with '=' characters in it.
Here is a patch to deal with that:
--- msvc9compiler.py.orig 2008-07-23 16:13:25.248438400 -0700
+++ msvc9compiler.py2008-07-23 16:13:54.059867200 -0700
@@ -252,7 +252,9 @@
if '=' not in line:
continue
line = line.strip()
-key, value = line.split('=')
+i = line.index('=')
+key = line[0:i]
+value = line[i:]
key = key.lower()
if key in interesting:
if value.endswith(os.pathsep):
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2975>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3503] Calls to print() function in Python 3.0 tutorial
New submission from Jim Sizelove <[EMAIL PROTECTED]>: I decided to learn more about the coming changes in Python 3.0 by installing the beta and working through the tutorial. I found some discrepancies between the code examples and the output I got. The attached patch shows several places where the print() function is called incorrectly. These are mostly examples that are missing the parentheses. The rest of this comment pertains to only one change included in the patch that I find less than satisfactory. In introduction.html, there is an example of printing a fibonacci sequence in one line of output by using the end keyword. When actually run in the python interpreter, the >>> prompt shows at the end of the same line as the fibonacci numbers. The patch fixes this by enclosing a "print()" within an else clause. This "fix" produces the expected output, but I don't think the else clause has been described yet in the tutorial. A better fix would be to wrap the while statement in a function with a print() function call after the end of the while statement (this is how the fib() function is defined in http://docs.python.org/dev/3.0/tutorial/modules.html). But functions have not been explained this early in the tutorial. Perhaps it would be best to drop this example of using the end keyword to the print function in the introduction and explain it later in the tutorial. -- assignee: georg.brandl components: Documentation files: print.diff keywords: patch messages: 70727 nosy: georg.brandl, jsizelove severity: normal status: open title: Calls to print() function in Python 3.0 tutorial versions: Python 3.0 Added file: http://bugs.python.org/file11061/print.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3503> ___ ___ 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
Jim Jewett <[EMAIL PROTECTED]> added the comment: Is there still disagreement over anything except: (1) The type signature of quote and unquote (as opposed to the explicit "quote_as_bytes" or "quote_as string"). (2) The default encoding (latin-1 vs UTF8), and (if UTF-8) what to do with invalid byte sequences? (3) Would waiting for 3.1 cause too many compatibility problems? -- nosy: +jimjjewett ___ 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
[issue3300] urllib.quote and unquote - Unicode issues
Jim Jewett <[EMAIL PROTECTED]> added the comment: Matt pointed out that the email package assumes Latin-1 rather than UTF-8; I assume Bill could patch his patch the same way Matt did, and this would resolve the email tests. (Unless you pronounce to stick with Latin-1) The cookiejar failure probably has the same root cause; that test is encoding (non-ASCII) Latin-1 characters, and urllib.parse.py/Quoter assumes Latin-1. So I see some evidence (probably not enough) for sticking with Latin-1 instead of UTF-8. But I don't see any evidence that fixing the semantics (encoded results should be bytes) at the same time made the conversion any more painful. On the other hand, Matt shows that some of those extra str->byte code changes might never need to be done at all, except for purity. ___ 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
[issue3300] urllib.quote and unquote - Unicode issues
Jim Jewett <[EMAIL PROTECTED]> added the comment: > http://codereview.appspot.com/2827/diff/1/5#newcode1450 > Line 1450: "%3c%3c%0Anew%C3%A5/%C3%A5", > I'm guessing this test broke otherwise? Yes; that is one of the breakages you found in Bill's patch. (He didn't modify the test.) > Given that this references an RFC, > is it correct to just fix it this way? Probably. Looking at http://www.faqs.org/rfcs/rfc2965.html (1) That is not among the exact tests in the RFC. (2) The RFC does not specify charset for the cookie in general, but the Comment field MUST be in UTF-8, and the only other reference I could find to a specific charset was "possibly in a server-selected printable ASCII encoding." Whether we have to use Latin-1 (or document charset) in practice for compatibility reasons, I don't know. ___ 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
[issue3522] zip() function example in tutorial
New submission from Jim Sizelove <[EMAIL PROTECTED]>: The zip() function is now a generator in Python 3.0. There is an example of using the zip() function in the Python 3.0 tutorial, http://docs.python.org/dev/3.0/tutorial/datastructures.html. When running the example, I got: >>> mat = [[1, 2, 3], [4, 5, 6], [7, 8, 9]] >>> zip(*mat) I wrapped it in a call to list() to get the example output: >>> list(zip(*mat)) [(1, 4, 7), (2, 5, 8), (3, 6, 9)] The attached patch file contains this change. -- assignee: georg.brandl components: Documentation files: datastructures.diff keywords: patch messages: 70871 nosy: georg.brandl, jsizelove severity: normal status: open title: zip() function example in tutorial versions: Python 3.0 Added file: http://bugs.python.org/file11077/datastructures.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3522> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3523] Reverse quotes in Python 3.0 tutorial
New submission from Jim Sizelove <[EMAIL PROTECTED]>: The Input and Output section of the tutorial says: "Reverse quotes (``) are equivalent to repr(), but they are no longer used in modern Python code and are removed in future versions of the language." Is now that future time with Python 3.0? I get syntax errors when I try to run the examples that use reverse quotes. The attached patch removes the explanation and examples of reverse quotes. -- assignee: georg.brandl components: Documentation files: input_output.diff keywords: patch messages: 70873 nosy: georg.brandl, jsizelove severity: normal status: open title: Reverse quotes in Python 3.0 tutorial versions: Python 3.0 Added file: http://bugs.python.org/file11079/input_output.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3523> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3524] IOError when attempting negative seek in file (Python 3.0 tutorial)
New submission from Jim Sizelove <[EMAIL PROTECTED]>:
The Input and Output section of the Python 3.0 tutorial
(http://docs.python.org/dev/3.0/tutorial/inputoutput.html) shows an
example of seeking in a negative direction from the end of a file. I
get an IOError when attempting to run the example in Python 3.0b2 on Mac
OS X 10.4 (PPC). I don't know whether the tutorial or the code should
be changed.
>>> f = open('workfile', 'r+')
>>> f.write('0123456789abcdef')
16
>>> f.seek(-3, 2)
Traceback (most recent call last):
File "", line 1, in
File
"/Users/jimsize/Programming/Python/py3k/3.0b2/lib/python3.0/io.py", line
1609, in seek
raise IOError("can't do nonzero end-relative seeks")
IOError: can't do nonzero end-relative seeks
--
assignee: georg.brandl
components: Documentation
messages: 70874
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: IOError when attempting negative seek in file (Python 3.0 tutorial)
type: behavior
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3524>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3525] Changes to exceptions not reflected in tutorial examples.
New submission from Jim Sizelove <[EMAIL PROTECTED]>:
PEPs 3109 and 3110 describe changes to Exceptions. The attached patch
file makes changes to the tutorial to bring it in line with the changes
to errors and exceptions implemented in Python 3.0.
I'll make a comment about the .args of exceptions instances. The
tutorial states "use of .args is discouraged." I found, however, that
the alternative of unpacking the args using __getitem__ raises a
TypeError.
>>> try:
... raise Exception('spam', 'eggs')
... except Exception as inst:
... x, y = inst
...
Traceback (most recent call last):
File "", line 2, in
Exception: ('spam', 'eggs')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 4, in
TypeError: 'Exception' object is not iterable
Does that mean that now .args is encouraged?
--
assignee: georg.brandl
components: Documentation
files: errors.diff
keywords: patch
messages: 70876
nosy: georg.brandl, jsizelove
severity: normal
status: open
title: Changes to exceptions not reflected in tutorial examples.
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file11080/errors.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3525>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3525] Changes to exceptions not reflected in tutorial examples.
Jim Sizelove <[EMAIL PROTECTED]> added the comment: The conversations that led to the removal of __getitem__ from Exceptions can be found in issue2291 and issue2379. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3529] Remove long integer literals from Python 3.0 tutorial
New submission from Jim Sizelove <[EMAIL PROTECTED]>: The distinction between integers and long integers has been removed in Python 3.0. The attached patch file changes the long literals to Python 3.0 integer literals in the Floating Point Arithmetic section of the tutorial. -- assignee: georg.brandl components: Documentation files: floatingpoint.diff keywords: patch messages: 70922 nosy: georg.brandl, jsizelove severity: normal status: open title: Remove long integer literals from Python 3.0 tutorial versions: Python 3.0 Added file: http://bugs.python.org/file11090/floatingpoint.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3529> ___ ___ 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
Jim Jewett <[EMAIL PROTECTED]> added the comment: Matt, Bill's main concern is with a policy decision; I doubt he would object to using your code once that is resolved. The purpose of the quoting functions is to turn a string (representing the human-readable version) into bytes (that go over the wire). If everything is ASCII, there isn't any disagreement -- but it also isn't obvious that they're bytes instead of characters. So people started (well, continued, since it dates to pre-unicode C) treating them as though they were strings. The fact that ASCII (and therefore most wire protocols) looks the same as bytes or as characters was one of the strongest arguments against splitting the bytes and string types. Now that this has been done, Bill feels we should be consistent. (You feel wire-protocol bytes should be treated as strings, if only as bytestrings, because the libraries use them that way -- but this is a policy decision.) To quote the final paragraph of 1.2.1 """ In local or regional contexts and with improving technology, users might benefit from being able to use a wider range of characters; such use is not defined by this specification. Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US-ASCII coded character set if this representation is allowed by the scheme or by the protocol element in which the URI is referenced. Such a definition should specify the character encoding used to map those characters to octets prior to being percent-encoded for the URI. """ So the mapping to bytes (or "octets") for non-ASCII isn't defined (here), and if you want to use it, you need to specify charset. But in practice, people do use it without specifying a charset. Which charset should be assumed? The old code (and test cases) assumed Latin-1. You want to assume UTF-8 (though you took the document charset when available -- which might also make sense). ___ 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
[issue3584] Exception for test_urllib2_localnet
New submission from Jim Hermann <[EMAIL PROTECTED]>: When I installed Python 2.5.2 on my Fedora Core 4 system, I ran 'make test" and the process stopped at this point: test_urllib2_localnet Exception in thread Thread-1067: Traceback (most recent call last): File "/usr/local/src/Python-2.5.2/Lib/threading.py", line 486, in __bootstrap_inner self.run() File "/usr/local/src/Python-2.5.2/Lib/test/test_urllib2_localnet.py", line 64, in run self._RequestHandlerClass) File "/usr/local/src/Python-2.5.2/Lib/test/test_urllib2_localnet.py", line 22, in __init__ RequestHandlerClass) File "/usr/local/src/Python-2.5.2/Lib/SocketServer.py", line 330, in __init__ self.server_bind() File "/usr/local/src/Python-2.5.2/Lib/BaseHTTPServer.py", line 101, in server_bind SocketServer.TCPServer.server_bind(self) File "/usr/local/src/Python-2.5.2/Lib/SocketServer.py", line 341, in server_bind self.socket.bind(self.server_address) File "", line 1, in bind error: (98, 'Address already in use') Thanks. Jim -- components: Tests messages: 71300 nosy: jimhermann severity: normal status: open title: Exception for test_urllib2_localnet type: crash versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3584> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment: Here is the equals sign fix as a separate patch file. Added file: http://bugs.python.org/file11343/equalsInEnv.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment: Any hope for these two patches being applied? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2975] VS8 include dirs grow without bound
Jim Kleckner <[EMAIL PROTECTED]> added the comment: Yes, much better. I should have read into the interior of the discussion rather than just the edges... Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2975> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7372] Regression in pstats
Jim Fulton added the comment: On Mon, Jan 25, 2010 at 7:35 PM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > See also #7372. > > AFAIU add_callers can receive either a tuple or an int (and this is what is > not working now). When I looked at #7372 I wasn't able to find out why it > might receive two different objects and not always the same (i.e. always a > tuple, possibly with only one int). From the first message it seems that > cProfile returns the tuple of 4 ints and profile returns a single int. > Can profile be fixed to return a tuple (of 4 or 1 ints) too? Ah interesting. I ran into this recently when I noticed that some analysis tools I'd written a while back no longer worked and had to be updated because data that were ints were now tuples. Aside from these particular issues, it would be really great if the profiler stats data structure was specified. :) Jim -- ___ Python tracker <http://bugs.python.org/issue7372> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3890] ssl.SSLSocket.recv() implementation may not work with non-blocking sockets
Jim Smyth added the comment: Is there any chance of this being resolved in time for any 2.x release? I have a non-blocking application that I recently switched over to SSL and ran into this bug. I can work around it by trying to shorten the messages and beefing up the buflen, but these solutions are not ideal. -- nosy: +jimsmyth ___ Python tracker <http://bugs.python.org/issue3890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5103] ssl.SSLSocket timeout not working correctly when remote end is hanging
Jim Duchek added the comment: This is happening 'in the wild' to me fairly regularly. Since it's not hanging in python, I can't watchdog/kill the thread it's happening in. matejcik seems correct on fixing this, there's no need to unset the timeout here. -- nosy: +Jim.Duchek ___ Python tracker <http://bugs.python.org/issue5103> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6257] Idle terminates on source save while debugging
Jim Shaw added the comment: I am having the same problem with Windows Vista and Windows 7. -- components: +IDLE nosy: +JimShaw versions: +Python 3.1 -Python 3.0 ___ Python tracker <http://bugs.python.org/issue6257> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8501] --dry-run option doesn't work
New submission from Jim Fulton : The --dry-run option is ignored by the install command. It leads to an error when used as a global option. It should be fixed or removed. I vote for removal, but don't really care. Removal seems easier. :) To reproduce, create the simple project: http://docs.python.org/distutils/introduction.html#a-simple-example and then try the option. See also: http://mail.python.org/pipermail/distutils-sig/2010-April/016000.html -- assignee: tarek components: Distutils messages: 103979 nosy: j1m, tarek severity: normal status: open title: --dry-run option doesn't work type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker <http://bugs.python.org/issue8501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1179] [CVE-2007-4965] Integer overflow in imageop module
Jim Panetta added the comment: Is this final yet? Our system security group is a little paranoid about buffer overflows of any sort and are starting to make noises. I can confirm that the Oct 20 patch applies against Python 2.5.1 on RHEL4, and that the string length error is generated when running poc.py. -- nosy: +jhpanetta __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1179> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1824] UUIDCreate()->UuidCreate() in msilib docs.
New submission from Jim Wilson: At http://docs.python.org/lib/module-msilib.html, UUIDCreate() is misspelled. -- components: Documentation messages: 59901 nosy: Jimbo severity: minor status: open title: UUIDCreate()->UuidCreate() in msilib docs. type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1824> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1825] msilib.add_data() takes exactly three parameters
New submission from Jim Wilson: At: http://docs.python.org/lib/module-msilib.html, add_data(...) is documented to take two parameters, but invoking it with two draws a complaint that three are needed. Examination of bdist_msi.py leads me to believe the missing (middle) parameter is "table", but I can barely distinguish a database from a hole in the ground. -- components: Documentation messages: 59909 nosy: Jimbo severity: minor status: open title: msilib.add_data() takes exactly three parameters type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1825> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1854] Broken link in msilib docs
New submission from Jim Wilson: at http://docs.python.org/lib/database-objects.html, under "See Also:", the link, MSIOpenView leads nowhere. From earlier reading, I suspect it should be "MSIDatabaseOpenView" (or perhaps "MSIDatabaseOpenViewPaddedOutEvenMoreToMakeYourEyesGlazeOver"). -- components: Documentation messages: 59998 nosy: Jimbo severity: minor status: open title: Broken link in msilib docs type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1854> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1855] Codepage unset in msilib.init_database()
New submission from Jim Wilson: At http://msdn2.microsoft.com/en-us/library/aa367864(VS.85,printer).aspx, Satanic Verses sayeth: "The Codepage Summary property must be set before any string properties are set in the summary information.", but so far as I can tell, PID_CODEPAGE is never used in msilib.__init__.py, etal. Confirming evidence: msilib's GetProperty(msilib.PID_CODEPAGE) raises "Not Implemented" on Python2.5.1's own .msi file. -- components: Distutils messages: 60006 nosy: Jimbo severity: normal status: open title: Codepage unset in msilib.init_database() versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1855> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1884] msilib.SetProperty(msilib.PID_CODEPAGE, '1252') raises 0x65d = type mismatch
New submission from Jim Wilson: I believe Codepage (a summary property which must be set *before* any other string value), is a string. Documentation admits it might also be an integer, but it doesn't matter. Both foo.SetProperty(PID_CODEPAGE, '1252') and foo.SetProperty(PID_CODEPAGE, 1252) raise "unknown error 65d". I believe 0x65d (1629d) to be ERROR_DATATYPE_MISMATCH. -- components: Build messages: 61440 nosy: Jimbo severity: normal status: open title: msilib.SetProperty(msilib.PID_CODEPAGE, '1252') raises 0x65d = type mismatch versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1884> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
New submission from Jim Kleckner:
When I install 2.6a1 onto a Windoze machine I get a dialog:
There is a problem with this Windows Installer package.
A program run as part of the setup did not finish as expected.
Contact your support personnel or package vendor.
Note that it didn't have VS2008 or any other new code installed.
The problem appears related to Tkinter but that isn't clear.
When running the Python console, running
import Tkinter
results in an error saying that _tkinter can't be loaded.
DLL load failed. The system can't find _tkinter.pyd
_tkinter.pyd and tcl84.dll and tk84.dll are in DLLs and
appear to have reasonable permissions.
I suspect something in the install failed to set something
in the registry.
This is on a current-patch XP
system and that I also tried python-2.6.13944.msi
from the buildbot just in case after uninstalling/reinstalling
with no difference.
Attached is a compressed log of the install.
Perhaps this "PROPERTY CHANGE: Deleting SECONDSEQUENCE"
is the problem?
Here is an excerpt from the log file:
Property(S): Privileged = 1
Property(S): DATABASE = C:\WINDOWS\Installer\5f5ad0.msi
Property(S): OriginalDatabase = C:\cygwin\tmp\python-2.6a1.msi
Property(S): UILevel = 5
Property(S): Preselected = 1
Property(S): CostingComplete = 1
Property(S): OutOfDiskSpace = 0
Property(S): OutOfNoRbDiskSpace = 0
Property(S): PrimaryVolumeSpaceAvailable = 0
Property(S): PrimaryVolumeSpaceRequired = 0
Property(S): PrimaryVolumeSpaceRemaining = 0
Property(S): SOURCEDIR = C:\cygwin\tmp\
Property(S): SourcedirProduct = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8}
Property(S): ProductToBeRegistered = 1
MSI (s) (FC:D0) [16:38:30:939]: MainEngineThread is returning 1603
MSI (s) (FC:C0) [16:38:30:939]: Destroying RemoteAPI object.
MSI (s) (FC:54) [16:38:30:939]: Custom Action Manager thread ending.
MSI (c) (E0:54) [16:38:30:954]: Back from server. Return value: 1603
MSI (c) (E0:54) [16:38:30:954]: Decrementing counter to disable
shutdown. If counter >= 0, shutdown will be denied. Counter after
decrement: -1
MSI (c) (E0:54) [16:38:30:954]: PROPERTY CHANGE: Deleting SECONDSEQUENCE
property. Its current value is '1'.
Action ended 16:38:30: ExecuteAction. Return value 3.
MSI (c) (E0:54) [16:38:30:954]: Doing action: FatalError
Action 16:38:30: FatalError.
Action start 16:38:30: FatalError.
Action 16:38:30: FatalError. Dialog created
Action ended 16:38:32: FatalError. Return value 2.
Action ended 16:38:32: INSTALL. Return value 3.
MSI (c) (E0:54) [16:38:32:375]: Destroying RemoteAPI object.
MSI (c) (E0:2C) [16:38:32:375]: Custom Action Manager thread ending.
Property(C): X = C:\Python26\Tools\pynche\X\
Property(C): UpgradeCode = {65E6DE48-A358-434D-AA4F-4AF72DB4718F}
Property(C): ProductName = Python 2.6a1
Property(C): ProductCode = {0BA82E1B-52FD-4E03-8610-A6C76238E8A8}
Property(C): ProductVersion = 2.6.101
Property(C): Manufacturer = Python Software Foundation
--
components: Installation
files: debuglog.txt.zip
messages: 63371
nosy: jkleckner
severity: normal
status: open
title: Install failure of 2.6a1 on Windows XP without VS8 installed
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9634/debuglog.txt.zip
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2256>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
Jim Kleckner added the comment: I uninstalled and re-ran the install without the "compile all" selected. The install didn't report errors. running: python -c "import test.testall" results in a traceback with the message: import _socket ImportError: DLL load failed: The system could not find the file specified. What sorts of things should I probe into? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2256> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1657] [patch] epoll and kqueue wrappers for the select module
Jim Jewett <[EMAIL PROTECTED]> added the comment: Is pyepoll a good prefix? To me, it looks a lot like the _Py and Py reservered namespaces, but not quite... -- nosy: +jimjjewett __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1657> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
Jim Kleckner <[EMAIL PROTECTED]> added the comment: Ping. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2256> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
Jim Kleckner <[EMAIL PROTECTED]> added the comment: It appears that issue2563 may be a dependency. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2256> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2256] Install failure of 2.6a1 on Windows XP without VS8 installed
Jim Kleckner <[EMAIL PROTECTED]> added the comment: I hadn't seen any comment here that I should try it again until your question (that was why the ping). I did try it again and my application worked. Thanks! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2256> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2679] email.feedparser regex duplicate
New submission from Jim Jewett <[EMAIL PROTECTED]>: feedparser defines four regexs for end-of-line, but two are redundant. NLCRE checks for the three common line endings. NLCRE_crack also captures the line ending. NLCRE_eol also adds a $ to ensure it is at the end. NLCRE_bol ... is identical to NLCRE_crack. It should either use a ^ to insist on line-start, or be explicitly the same. (e.g., NLCRE_bol=NLCRE_crack.) (It gets away with not listing the ^ because the current code only uses NLCRE_bol.match. (Actually, if the regexes are considered private, then the current code could just use the bound methods directly ... setting NLCRE_bol to the .match method, NLCRE_eol to the .search method, and NLCRE_crack to the .split method.) -- components: Library (Lib) messages: 65723 nosy: jimjjewett severity: normal status: open title: email.feedparser regex duplicate versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2679> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Jim Jewett <[EMAIL PROTECTED]> added the comment:
> These features are to bring the Regexp code closer in line with Perl 5.10
Why 5.1 instead of 5.8 or at least 5.6? Is it just a scope-creep issue?
> as well as add a few python-specific
because this also adds to the scope.
> 2) Make named matches direct attributes
> of the match object; i.e. instead of m.group('foo'),
> one will be able to write simply m.foo.
> 3) (maybe) make Match objects subscriptable, such
> that m[n] is equivalent to m.group(n) and allow slicing.
(2) and (3) would both be nice, but I'm not sure it makes sense to do
*both* instead of picking one.
> 5) Add a well-formed, python-specific comment modifier,
> e.g. (?P#...);
[handles parens in comments without turning on verbose, but is slower]
Why? It adds another incompatibility, so it has to be very useful or
clear. What exactly is the advantage over just turning on verbose?
> 9) C-Engine speed-ups. ...
> a number of Macros are being eliminated where appropriate.
Be careful on those, particular on str/unicode and different compile options.
--
nosy: +jimjjewett
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2636>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Jim Jewett <[EMAIL PROTECTED]> added the comment: Python 2.6 isn't the last, but Guido has said that there won't be a 2.10. > Match object is a C-struct with python binding > and I'm not exactly sure how to add either feature to it I may be misunderstanding -- isn't this just a matter of writing the function and setting it in the tp_as_sequence and tp_as_mapping slots? > Larry Wall and Guido agreed long ago that we, the python > community, own all expressions of the form (?P...) Cool -- that reference should probably be added to the docs. For someone trying to learn or translate regular expressions, it helps to know that (?P ...) is explicitly a python extension (even if Perl adopts it later). Definately put the example in the doc. r'He(?# 2 (TWO) ls)llo' should match "Hello" but it doesn't. Maybe even without the change, as doco on the current situation. Does VERBOSE really have to be the first flag, or does it just have to be on the whole pattern instead of an internal switch? I'm not sure I fully understand what you said about template. Is this a special undocumented switch, or just an internal optimization mode that should be triggered whenever the repeat operators don't happen to occur? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2636> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
