[issue2511] Give AST's excepthandler proper attributes
Georg Brandl [EMAIL PROTECTED] added the comment: Committed in r62047. -- status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2511 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
New submission from Mark Hammond [EMAIL PROTECTED]: I've taken the liberty of adding Trent, Christian and Martin to the nosy list as I know they are actively, if reluctantly interested in this. This patch allows the distutils to cross-compile on Windows. It has been tested on x86 and amd64 platforms, with both platforms successfully able to natively and cross-compile extension modules and create binary distributions. To cross-compile, specify '--plat-name' to the build command (valid values are 'win32', 'win-amd64' and 'win-ia64'). This option name was chosen to be consistent with the bdist_dumb command. I've included the docs I added below (which are also in the patch), but note that as with native compilation using distutils, it's not necessary to set any environment variables or do anything else special with your environment to make this work. The patch also adds a x64 target for the 'bdist_wininst' target, which it creates as distutils/command/wininst-9.0-amd64.exe. This executable is necessary even for bdist_wininst to work natively on x64, but is still included here for simplicity. To assist with testing, I've also added a distutils setup.py script to the PC/example_nt directory. This is capable of creating bdist_wininst executables for both native and cross platforms; 'setup.py build --platname=win-amd64 bdist_wininst' will create an amd64 installer on an x86 machine. The patch has not been tested with a Visual Studio environment without cross-compile tools installed - it will obviously fail, but its not clear how ugly this failure will be. Below is the text I added to docs/distutils/builtdist.rst: Cross-compiling on Windows = Starting with Python 2.6, distutils is capable of cross-compiling between Windows platforms. In practice, this means that with the correct tools installed, you can use a 32bit version of Windows to create 64bit extensions and vice-versa. To build for an alternate platform, specify the :option:`--plat-name` option to the build command. Valid values are currently 'win32', 'win-amd64' and 'win-ia64'. For example, on a 32bit version of Windows, you could execute:: python setup.py build --plat-name=win-amd64 to build a 64bit version of your extension. The Windows Installers also support this option, so the command:: python setup.py build --plat-name=win-amd64 bdist_wininst would create a 64bit installation executable on your 32bit version of Windows. Note that by default, Visual Studio 2008 does not install 64bit compilers or tools. You may need to reexecute the Visual Studio setup process and select these tools. -- assignee: mhammond components: Distutils files: windows-cross-compile.patch keywords: 64bit, patch messages: 64743 nosy: Trent.Nelson, ctheune, loewis, mhammond severity: normal status: open title: 64bit cross compilation on windows type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9900/windows-cross-compile.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2513 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2505] Easier creation of _ast nodes
Georg Brandl [EMAIL PROTECTED] added the comment: Committed in r62049. -- status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2505 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class
Georg Brandl [EMAIL PROTECTED] added the comment: Gerhard: Note that you don't need to commit identical changes to the trunk and 3k branches -- the merging process will take care of this. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2176 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2514] new AST init breaks on Store and other fieldless Nodes
New submission from Armin Ronacher [EMAIL PROTECTED]: #2505 adds a new init to the ast nodes that allows initialization of the fields directory from the constructor. Unfortunately there are nodes where fields is None (_ast.Store and others) and the constructor didn't take care of this. The patch applied adds a test for None to fix the problem. -- components: Extension Modules files: initfix.diff keywords: patch messages: 64746 nosy: aronacher severity: normal status: open title: new AST init breaks on Store and other fieldless Nodes versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9901/initfix.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2514 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Hans-Peter Jansen [EMAIL PROTECTED] added the comment: But should not this patch be handled in a way wherein. key.capitalize() is just replaced by key.upper()? Hmm, are you sure? hello.upper() 'HELLO' but the issue is with values containing dashes: 'accept-charset'.capitalize() 'Accept-charset' whereas the rest of the world would expect: 'Accept-Charset' ^ This is especially useful, if you try to emulate the behavior of a typical browser as close as possible. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
John J Lee [EMAIL PROTECTED] added the comment: Specifically, these improvements could be made: * the headers actually sent to httplib could be normalized to Standard-Http-Case by urllib2 * the urllib2.Request.headers interface could support case-insensitive key lookup __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
John J Lee [EMAIL PROTECTED] added the comment:
urllib2.Request.headers is, in practice, an undocumented public
interface. Did you run the tests? There is room for improvement here,
but not in the way you suggest.
python[1]$ python2.6
iPython 2.6a1+ (trunk:62045M, Mar 30 2008, 03:07:23)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type help, copyright, credits or license for more information.
import test.test_urllib2
print test.test_urllib2.test_request_headers_dict.__doc__
The Request.headers dictionary is not a documented interface. It should
stay that way, because the complete set of headers are only accessible
through the .get_header(), .has_header(), .header_items() interface.
However, .headers pre-dates those methods, and so real code will be
using
the dictionary.
The introduction in 2.4 of those methods was a mistake for the same
reason:
code that previously saw all (urllib2 user)-provided headers in .headers
now sees only a subset (and the function interface is ugly and
incomplete).
A better change would have been to replace .headers dict with a dict
subclass (or UserDict.DictMixin instance?) that preserved the .headers
interface and also provided access to the unredirected headers. It's
probably too late to fix that, though.
Check .capitalize() case normalization:
url = http://example.com;
Request(url, headers={Spam-eggs: blah}).headers[Spam-eggs]
'blah'
Request(url, headers={spam-EggS: blah}).headers[Spam-eggs]
'blah'
Currently, Request(url, Spam-eggs).headers[Spam-Eggs] raises
KeyError,
but that could be changed in future.
--
nosy: +jjlee
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2275
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2451] No way to disable socket timeouts in httplib, etc.
John J Lee [EMAIL PROTECTED] added the comment: I've attached a patch. My patch introduces one minor issue: it's an inconvenience when wrapping objects if special default values like socket._GLOBAL_DEFAULT_TIMEOUT are not public. However, I think it's not worth making that special value public in this case, because it's not needed by code that does not support the socket.getdefaulttimeout() global default timeout. Patch description - * Change the timeout arguments that were introduced with Facundo's 2.6 timeout changes so that they have the same meaning as the argument of socket.socket.settimeout() . Specifically, None means no timeout (previously, there was no way to request that), and there is no special public timeout value meaning use the global default socket.getdefaulttimeout() value (previously, you could pass None to request that). This affects socket, urllib2, urllib (only urllib.ftpwrapper, for urllib2's benefit, urllib public interface and behaviour is unchanged), httplib, ftplib, telnetlib, poplib, and smtplib. * Fix a test bug: test_urllib2net changed global state by calling urllib2.install_opener(), which interfered with other tests. * In tests, where possible, close sockets by calling high-level methods (e.g. call ftplib.FTP.close(), rather than poking into the object's internals to .close() the socket directly). * Inconsistent defaulting behaviour in telnetlib was introduced with the timeout changes (r54608). Made timeout behave like port in terms of defaulting behaviour. * Improve socket.create_connection() documentation. Some of these changes need to be propagated to the individual protocol modules that call this function (e.g. httplib). - Document return value - Be more PEP 8-compliant (Connect to..., not Connects to...) - Remove this sentence, since it seems out of place in API documentation and unlikely to be true: Especially useful for higher-level protocols, it is not normally used directly from application-level code. - Reword to remove any doubt that the timeout applies to (almost) all blocking operations, not just .connect() - Rephrase timeout parameter description for better English style. - Note that create_connection() is a convenience function (rather than part of the thin wrapper around the C API). - Make the docstring for create_connection() match the official reST API docs. Unresolved issues with the new 2.6 timeout functionality * http://bugs.python.org/issue2452 * I did not propagate the changes to socket.create_connection() docs to all the protocol modules (httplib, etc.). Probably this change should be committed separately -- I ran out of time. * References in the docs to the global default timeout setting are vague. They should specifically refer to socket.getdefaulttimeout() . This should be done in such a way as to also fix the lack of documentation of the None special value in the protocol modules documentation (httplib, etc.). I should have fixed that as part of this patch, but ran out of time -- sorry! * Inconsistency: CacheFTPHandler has per-handler timeout, per-request timeout is ignored! Doc/library/urllib2.rst says (in two places): This actually only work for HTTP, HTTPS, FTP and FTPS connections. That's not true. (What about CacheFTPHandler, for instance?) It's also unclear why it refers to *connections* rather than URL schemes, handler classes, and the network operations they perform. (there's also a little grammatical error here -- s/work/works/) * API weirdness: Only some, special, urllib2.Request objects may be passed to handlers, because the constructor does not create objects with a .timeout. Should it really be per-request anyway (I'm not sure)? -- keywords: +patch Added file: http://bugs.python.org/file9902/issue2451.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2451 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2451] No way to disable socket timeouts in httplib, etc.
John J Lee [EMAIL PROTECTED] added the comment: Should I also have selected Python 3.0 from the Versions list, BTW? Don't know what the proper process is ATM... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2451 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2451] No way to disable socket timeouts in httplib, etc.
John J Lee [EMAIL PROTECTED] added the comment: Me: This should be done in such a way as to also fix the lack of documentation of the None special value in the protocol modules documentation (httplib, etc.). I should have fixed that as part of this patch, but ran out of time -- sorry! Erm, possibly the meaning and allowed values of the timeout arguments would be more naturally documented by pointing to the socket .settimeout() method docs, actually. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2451 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2515] Segfault while operating on closed sqlite3 cursor.
New submission from Paul Davis [EMAIL PROTECTED]: Replicated on: #Ubuntu 7.0 Python 2.5.1 (r251:54863, Mar 7 2008, 03:39:23) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 #OS 10.4.11 Python 2.5.1 (r251:54863, Oct 26 2007, 16:52:32) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin #OS 10.5.2 Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin -- components: Library (Lib) files: sqlite_segfault.py messages: 64753 nosy: pjdavis severity: normal status: open title: Segfault while operating on closed sqlite3 cursor. type: crash versions: Python 2.5 Added file: http://bugs.python.org/file9903/sqlite_segfault.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2515 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Sat, Mar 29, 2008 at 4:58 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: This has basically almost never been a problem in the real world. I believe Ned gave an important use case. In coverage testing, optimized runs can show false gaps in coverage. In addition, a no optimize option would provide a valuable learning tool. Python has an excellent simple VM very suitable for a case study in introductory CS courses. Unfortunately, inability to disable peephole optimizer makes understanding the resulting bytecode more difficult, particularly given some arbitrary choices made by the optimizer (such as 2*3+1 = 7, but 1+2*3 = 1+6). Furthermore, as Raymond suggested in another thread, peephole optimizer was deliberately kept to bare minimum out of concerns about compilation time. Given that most python code is pre-compiled, I think it is a rare case when code size/speed improvements would not be worth increased compilation time. In a rare case when compilation time is an issue, users can consider disabling optimization. Finally, an easy way to disable the optimizer would help in developing the optimizer itself by providing an easy way to measure improvements and debugging. No need to complicate the world further by adding yet another option and the accompanying implementation-specific knowledge of why you would ever want to use it. This would not really be a new option. Most users expect varying levels of optimization with -O option and python already has 3 levels: plain, -O, and -OO or Py_OptimizeFlag = 0,1, and 2. Moreover, in fact, Py_OptimizeFlag can be set to an arbitrary positive integer using undocumented -OOO.. option. I don't see how anyone would consider adding say -G with Py_OptimizeFlag = -1 that would disable all optimization as complicating the world. Also, when the peepholer is moved (after the AST is created, but before the opcodes), then little oddities like this will go away. I don't see how moving optimization up the chain will help with this particular issue. Note that the problem is not with peepholer emiting erroneous line number information, but the fact that the continue statement is optimized away by replacing the if statement's jump to continue with a direct jump to the start of the loop. As I stated in my first comment, trace output is correct and as long as the compiler avoids redundant double jumps, the continue statement will not show up in trace regardless where in compilation chain it is optimized. The only way to get correct coverage information is to disable double jump optimization. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2506 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Antoine Pitrou [EMAIL PROTECTED] added the comment: Alexandre, is it normal that the unit tests look much less complete in your latest patch than they were in the previous one? Also, they don't test the Python fallback implementation anymore. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2451] No way to disable socket timeouts in httplib, etc.
Benjamin Peterson [EMAIL PROTECTED] added the comment: Marking just 2.6 is fine. The fix will be merged into 3.0 -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2451 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: Oops, I forgot to include the unit tests, with svn add, when I made the diff. Added file: http://bugs.python.org/file9904/bytesio+misc-fixes-5.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: There is a small bug in the last patch I posted. The unit tests assumed (wrongly) that accelerator module for io.StringIO (i.e., _stringio) was present. Added file: http://bugs.python.org/file9905/bytesio+misc-fixes-6.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2514] new AST init breaks on Store and other fieldless Nodes
Georg Brandl [EMAIL PROTECTED] added the comment: Fixed in r62051. -- nosy: +georg.brandl resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2514 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2452] inaccuracy in httplib timeout documentation
Changes by Alan Kennedy [EMAIL PROTECTED]: -- nosy: +amak __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2452 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Senthil [EMAIL PROTECTED] added the comment: Hi John, Greetings! I agree with both of your suggestions. Attached is the patch which aims to implement both in one go. Please provide your comments on that. If this method is okay, I shall go ahead with patches for tests and attach it also. Thanks, Senthil Added file: http://bugs.python.org/file9906/issue2275.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Changes by Senthil [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9906/issue2275.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Changes by Senthil [EMAIL PROTECTED]: Added file: http://bugs.python.org/file9907/issue2275.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Hans-Peter Jansen [EMAIL PROTECTED] added the comment: Hi Senthil, that looks promising, and the title() trick is nice, as it fixes my issue.. Thanks, Pete __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2275 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Ok I took a detailed look at _bytesio.c.
In write_bytes() there is the following resizing logic:
if (self-pos + len self-string_size) {
if (resize_buffer(self, self-pos + len) 0)
return -1;
}
Replacing `self-string_size` with `self-buf_size` should avoid some
spurious reallocations.
For some reason, using the help() function on a BytesIO instance does
not display the class help.
Overall, the new module looks fine. I can't say anything about the io.py
or _fileio.c fixes.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1751
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Antoine Pitrou [EMAIL PROTECTED] added the comment: One last thing: you probably noticed it, but there is one test which needs correcting in test_StringIO. It's due to the fact that calling next() on a closed BytesIO object raises ValueError now rather than StopIteration. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Raymond Hettinger [EMAIL PROTECTED] added the comment: Weigh the cost/benefit carefully before pushing further. I don't doubt the legitimacy of the use case, but do think it affects far fewer than one percent of Python programmers. In contrast, introducing new command line options is a big deal and will cause its own issues (possibly needing its own buildbot runs to exercise the non-optimized version, having optimized code possibly have subtle differences from the code being traced/debugged/profiled, and more importantly the mental overhead of having to learn what it is, why it's there, and when to use it). My feeling is that adding a new compiler option using a cannon to kill a mosquito. If you decide to press the case for this one, it should go to python-dev since command line options affect everyone. This little buglet has been around since Py2.3. That we're only hearing about it now is a pretty good indicator that this is a very minor in the Python world and doesn't warrant a heavy-weight solution. It would be *much* more useful to direct effort improving the mis- reporting of the number of arguments given versus those required for instance methods: a.f(1, 2) TypeError: f() takes exactly 1 argument (3 given) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2506 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Ned Batchelder [EMAIL PROTECTED] added the comment: Raymond, do you have a cannon-less recommendation of how to kill this particular mosquito? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2506 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: I think that check in write_bytes() is a guard to avoid resize_buffer() from truncating the string stored in the buffer. However, I am not sure if it is still necessary. I don't know why help() doesn't work on BytesIO instances. But, the problem doesn't seems to be in my code, since `help(sys.stdin)` doesn't work either. Finally regarding test_StringIO, see msg59460. Anyway, test_StringIO is superseded by test_memoryio included my patch and should be removed from the stdlib. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
New submission from Alexander Belopolsky [EMAIL PROTECTED]: Opening a new issue per Raymond's request at msg64764: It would be *much* more useful to direct effort improving the mis- reporting of the number of arguments given versus those required for instance methods: a.f(1, 2) TypeError: f() takes exactly 1 argument (3 given) I would suggest that this misreporting may be dear to old-beards reminding the time when there was not as much difference between methods and functions as there is now. It does not seem to be that hard to change the diagnostic to a.f(1, 2) TypeError: f() takes no arguments (2 given) but the novice users would much rather see a.f() takes no arguments (2 given). The later is unfortunately not possible. Raymond, what would you say to class 'A' instance.f() takes no arguments (2 given) diagnostic? -- components: Interpreter Core messages: 64767 nosy: belopolsky, rhettinger severity: normal status: open title: Instance methods are misreporting the number of arguments type: behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2516 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: .. It would be *much* more useful to direct effort improving the mis- reporting of the number of arguments given versus those required for instance methods: a.f(1, 2) TypeError: f() takes exactly 1 argument (3 given) Please see issue2516. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2506 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1751] Fast BytesIO implementation + misc changes
Antoine Pitrou [EMAIL PROTECTED] added the comment: Well, by construction self-buf_size should always be greater than self-string_size, so I don't think there's any risk of truncating anything here. I tried the change, and the tests still ran fine. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1751 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2517] Error when printing an exception containing a Unicode string
New submission from Christoph Burgmer [EMAIL PROTECTED]: Python seems to have problems when an exception is thrown that contains non-ASCII text as a message and is converted to a string. try: ... raise Exception(u'Error when printing ü') ... except Exception, e: ... print e ... Traceback (most recent call last): File , line 4, in ? UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 20: ordinal not in range(128) See http://www.stud.uni-karlsruhe.de/~uyhc/de/content/python-and-exceptions-containing-unicode-messages -- components: Unicode messages: 64770 nosy: christoph severity: normal status: open title: Error when printing an exception containing a Unicode string type: behavior versions: Python 2.4, Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2517 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2517] Error when printing an exception containing a Unicode string
Benjamin Peterson [EMAIL PROTECTED] added the comment: That is because Python encodes it's error messages as ASCII by default, and ü is not in ASCII. You can fix this by using print unicode_msg.encode(utf-8) or something similar. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2517 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Changes by Ned Batchelder [EMAIL PROTECTED]: -- nosy: +nedbat __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2516 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Alexander Belopolsky [EMAIL PROTECTED] added the comment: Attached patch (issue2516poc.diff) presents proof-of-concept code which changes the problematic reporting as follows: a.f(1,2) Traceback (most recent call last): File stdin, line 1, in module TypeError: A object.f() takes exactly 0 arguments (2 given) More effort is needed to make this patch ready: support default/keyword arguments, respect English grammar in 1-argument case, etc. Before I do that, however, I would like to hear that this is a worthwhile fix and that I've chosen the right place in the code to implement it. -- keywords: +patch Added file: http://bugs.python.org/file9908/issue2516poc.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2516 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Benjamin Peterson [EMAIL PROTECTED] added the comment: You have +1 from me to continue developing this patch. -- nosy: +benjamin.peterson priority: - low __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2516 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: .. Weigh the cost/benefit carefully before pushing further. I don't doubt the legitimacy of the use case, but do think it affects far fewer than one percent of Python programmers. I agree with you, but only because fewer than 1% of Python programmers have complete test coverage for their code. :-) On the other hand, I wanted a no-optimize option regardless of the trace issue. Once it is there, I am sure everyone interested in how python compiler works will use it. (I am not sure what % of Python programmers would fall into that category.) I don't know how big of a deal an extra buildbot is, but I don't think it will be necessary. It is hard to imagine optimization that would fix (mask) errors in non-optimized code. Therefore, a non-optimized buildbot is unlikely to flag errors that ar not present in optimized runs. On the other hand errors introduced by optimizer will be easier to diagnose if they disappear when the code runs without optimization. Mental overhead is important, but I think it will be easier to explain the effect of no optimize option than to explain what -O does in the current version. As far as I can tell, -O has nothing to do with peephole optimization and only removes assert statements and replaces __debug__ with 0. I am sure most python users are not aware of the fact that peephole optimization is performed without -O option. My feeling is that adding a new compiler option using a cannon to kill a mosquito. If you decide to press the case for this one, it should go to python-dev since command line options affect everyone. As an alternative to the command line option, what would you say to making sys.flags.optimize writeable and disable peepholer if Py_OprimizeFlag 0? This will allow python tracing tools to disable optimization from within python code. The fact that setting sys.flags.optimize flag will not affect modules that are already loaded is probably a good thing because tracing code itself will run optimized. Such tracing tools may also need to use a custom importer that would ignore precompiled code and effectively set dont_write_bytecode flag. This little buglet has been around since Py2.3. That we're only hearing about it now is a pretty good indicator that this is a very minor in the Python world and doesn't warrant a heavy-weight solution. I still maintain that this is not a bug. Not hearing about it before is probably an indication that users sophisticated enough to try to achieve full test coverage for their code were able to recognize false coverage gaps as such. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2506 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Raymond Hettinger [EMAIL PROTECTED] added the comment: Marking this one as closed. Also, rejecting the various ways to disable peephole optimization. This was discussed with Guido long ago and the decision essentially recognized that for most practical purposes the output of the peepholer is the generated code and no good would come from exposing upstream intermediate steps. Since then, I believe Neal got Guido's approval for either the -O or - OO option to generate new optimizations that potentially change semantics. In that situation, there is a worthwhile reason for the enable/disable option. -- resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2506 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2518] smtpd.py to handle huge email
New submission from HiroakiKawai [EMAIL PROTECTED]: I had some problems when I wanted to do attach a huge data file (such as mp3, avi, or etc.) to an email. Current smtpd.py in Python2.5 calls process_message that takes a string for its argument. This cause python running process to consume too much memory. I'd like to suggest an alternative method for this purpose process_message_huge that takes a file-descriptor for its argument. The patch will use process_message_huge if the method exists, otherwise, it will call process_message with a string that will consume a huge memory for backward compatibility. -- components: Library (Lib) files: smtpd.patch keywords: patch messages: 64776 nosy: kawai severity: normal status: open title: smtpd.py to handle huge email type: security versions: Python 2.5 Added file: http://bugs.python.org/file9909/smtpd.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2518 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2518] smtpd.py to handle huge email
Changes by HiroakiKawai [EMAIL PROTECTED]: -- type: security - resource usage __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2518 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2518] smtpd.py to handle huge email
HiroakiKawai [EMAIL PROTECTED] added the comment: My carelessness, missing importing cStringIO Added file: http://bugs.python.org/file9910/smtpd.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2518 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2518] smtpd.py to handle huge email
Changes by HiroakiKawai [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9909/smtpd.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2518 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
