[issue10538] PyArg_ParseTuple(s*) does not always incref object
New submission from Kristján Valur Jónsson krist...@ccpgames.com: The new s* code for PyArg_ParseTuple is used to fill a Py_buffer object from the arguments. This object must be relased using PyBuffer_Release() after use. However, if the object in the tuple does not support the new buffer interface, the old buffer interface is queried and the Py_buffer object is manually filled in. For this case, the source object is _not_ increfed and buffer.obj remains set to 0. This causes different semantics in the function for objects that are passed in: If the Py_buffer interface is supported directly, then it is safe for the function to store this and release this at a later time. If it isn't supported, then no extra reference to the object is got and the function cannot safely keep the Py_buffer object around. The Fix is as follows: Change line 1402 of getargs.c from: PyBuffer_FillInfo(view, NULL, buf, count, 1, 0); to PyBuffer_FillInfo(view, arg, buf, count, 1, 0); -- messages: 122445 nosy: krisvale priority: normal severity: normal status: open title: PyArg_ParseTuple(s*) does not always incref object type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10538] PyArg_ParseTuple(s*) does not always incref object
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Wichert Akkerman wich...@wiggy.net added the comment: I can help test changes for python 2.x. The python 3.x ecosystem is at least a year away from becoming interesting for me I'm afraid. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10538] PyArg_ParseTuple(s*) does not always incref object
Changes by Georg Brandl ge...@python.org: -- assignee: - pitrou nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10122] Documentation typo fix and a side question
Georg Brandl ge...@python.org added the comment: I don't waste my time by merging every little typo fix to the maintenance branches immediately; I rather merge them all at once every now and then. You will certainly understand that nobody is harmed by a stray d, even if it has a pointy tip. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10299] Add index with links section for built-in functions
Georg Brandl ge...@python.org added the comment: Dividing the table in sections makes sense to me; it provides the kind of grouping that is helpful sometimes, but cannot be kept when sorting alphabetically. So when the table is grouped, the actual docs can remain alphabetized. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10526] Minor typo in What's New in Python 2.7
Georg Brandl ge...@python.org added the comment: Thanks, fixed in r86794. -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10526 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9312] Fix usage of :option: markup in stdlib ReST docs
Georg Brandl ge...@python.org added the comment: Yes, you're right; you could have linked to the correct -c option by using this form: :option:`unittest -c` -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10420] Document of Bdb.effective is wrong.
Georg Brandl ge...@python.org added the comment: Thanks, fixed in r86798. -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10420 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10172] code block has no syntax coloring
Georg Brandl ge...@python.org added the comment: This is because the Python used to render doesn't recognize the new-style exception catching; this will be fine once the system is upgraded to 2.6. -- nosy: +georg.brandl resolution: - later status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5211] Fix complex type to avoid coercion in 2.7.
Mark Dickinson dicki...@gmail.com added the comment: I think that's expected behaviour. Note that int vs float behaves in the same way as float vs complex: class xint(int): ... def __radd__(self, other): ... print __radd__ ... return 42 ... 3 + xint(5) __radd__ 42 3.0 + xint(5) # xint.__radd__ not called. 8.0 As with your example, the float.__add__ method is happy to deal with an int or an instance of any subclass of int. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5211 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10535] Enable warnings by default in unittest
Changes by Davide Rizzo sor...@gmail.com: -- nosy: +davide.rizzo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10535 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1059244] distutil bdist hardcodes the python location
anatoly techtonik techto...@gmail.com added the comment: As I can't reopen this issue, I'd like to ask for another opinion before closing this ticket. I think it's closed prematurely. For the bare minimum there should be a link to corresponding issue in distutils2 project. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1059244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Brian Jones bkjo...@gmail.com added the comment: Sure. I'll create a patch in the next few days and submit it. Thanks for the link to the guidelines. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1059244] distutil bdist hardcodes the python location
Tarek Ziadé ziade.ta...@gmail.com added the comment: I am +1 with what Eric said. I'd suggest that you send a mail to teh distutils2 development mailing list to make some proposals. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1059244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Brian Jones bkjo...@gmail.com added the comment: So... have I missed a memo, or is it currently impossible to test the current svn version of distutils in the current svn version of Python? The tests for (at least) register and upload are written using Python 2.x syntax and modules. How are new features and fixes for distutils being tested? Is it valid to use a 2.x version of Python to test the trunk version of distutils? Sorry if these questions have really obvious answers. First time patcher :? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Tarek Ziadé ziade.ta...@gmail.com added the comment: If you can make your server work with the current implementation, I'd rather not change this in distutils but in distutils2. Distutils is frozen and we make only bug fixes. By bug fix I mean anything that is a bug. A non-strict implementation of the EOLs is not a bug, and I suggest that you write your patch against distutils2. Eric, thanks for all the hard work in triaging the bugs ! Let's make sure we do the bare minimal maintenance in distutils, and suggest to people to contribute in distutils2. Brian, for distutils1, the register and upload command would be considered buggy if they don't work for PyPI, which is not the case. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10538] PyArg_ParseTuple(s*) does not always incref object
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6983] Add specific get_platform() for freebsd
Changes by Tarek Ziadé ziade.ta...@gmail.com: -- components: +Distutils2, Library (Lib) -Distutils ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Brian Jones bkjo...@gmail.com added the comment: If it's not a bug in distutils1, I imagine it will not be a bug in distutils2, since that will also presumably work with PyPI, and PyPI will be the single solitary supported implementation of the service? I also don't see distutils2 in this list http://svn.python.org/projects/ which means either distutils2 isn't part of the standard library, or it doesn't follow the documented patch submission process, or perhaps both? Insight welcome here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10510] distutils upload/register should use CRLF in HTTP requests
Tarek Ziadé ziade.ta...@gmail.com added the comment: If it's not a bug in distutils1, I imagine it will not be a bug in distutils2 Yes that would be a feature request. we would be happy to add. e.g. make the commands works with server X ou server Y. I also don't see distutils2 in this list http://svn.python.org/projects/ which means either distutils2 isn't part of the standard library, or it doesn't follow the documented patch submission process, or perhaps both? Insight welcome here. Distutils2 is developed at http://hg.python.org/distutils2 and will be included when ready in the stdlib (circa 3.3), as a distutils replacer. It's in fact the distutils trunk, with lots of changes (some are backward incompatible). It will be installable from 2.4 onward. It does not follow the same process. Which I have described in python-dev last week: http://mail.python.org/pipermail/python-dev/2010-November/105772.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10539] Regular expression not checking 'range' element on 1st char in string.
New submission from Jamie Murray txr...@gmail.com: The first char in a word is omitted from being checked against the 'range' element of the 1st part of this expression. The second char is properly checked to see if it's in range # Desired safe string to expect goodString = f42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88 # Test string to return False if it's not within reg ex range. # but still returns a false positive even though the g at the start is outside of a-f range. badString = g42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88 # 2nd test string which does return a false result correctly. otherBadString = fg2e6be1-29bf-4f3c-ba58-1ae1d9ca5f88 See attached file for example. Python 2.5.4 (r254:67916, Dec 23 2008, 15:19:34) [MSC v.1400 64 bit (AMD64)] on win32 -- components: Regular Expressions files: RegExPyBug.py messages: 122461 nosy: TxRxFx priority: normal severity: normal status: open title: Regular expression not checking 'range' element on 1st char in string. type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file19823/RegExPyBug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10540] test_shutil fails on Windows after r86733
New submission from Brian Curtin cur...@acm.org: My build slave shows a test failure at test_dont_copy_file_onto_link_to_itself. This happens because the implementation of _samefile in Lib/shutil.py (line 70) doesn't work for Windows hard links. Patch on the way. -- assignee: brian.curtin components: Library (Lib), Windows messages: 122462 nosy: brian.curtin priority: normal severity: normal stage: needs patch status: open title: test_shutil fails on Windows after r86733 type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10541] regrtest.py -T broken
New submission from Walter Dörwald wal...@livinglogic.de: Running regrtest.py with coverage option seems to be broken for the py3k branch at the moment. Run the following commands on the shell: wget http://svn.python.org/snapshots/python3k.tar.bz2 tar xjf python3k.tar.bz2 cd python ./configure --enable-unicode=ucs4 --with-pydebug make coverage ./python.exe Lib/test/regrtest.py -T -N test_urllib This gives the following output: [1/1] test_urllib Not printing coverage data for 'Lib/test/regrtest.py': [Errno 2] No such file or directory: 'Lib/test/regrtest.py' Traceback (most recent call last): File Lib/test/regrtest.py, line 1502, in module main() File Lib/test/regrtest.py, line 698, in main r.write_results(show_missing=True, summary=True, coverdir=coverdir) File /Users/walter/x/pybug/python/Lib/trace.py, line 331, in write_results with open(filename, 'rb') as fp: IOError: [Errno 2] No such file or directory: 'Lib/test/regrtest.py' [123146 refs] I'm testing on Mac OS X 10.6.5. Attached is the complete log of the shell session. This bug might be related to issue 10329, as the failing line was introduced in r86303. -- assignee: haypo components: Tests files: build.log messages: 122463 nosy: doerwalter, haypo priority: normal severity: normal status: open title: regrtest.py -T broken Added file: http://bugs.python.org/file19824/build.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
New submission from Alexander Belopolsky belopol...@users.sourceforge.net:
As discussed in issue 10521 and the sprawling len(chr(i)) = 2? thread [1] on
python-dev, many functions in python library behave differently on narrow and
wide builds. While there are unavoidable differences such as the length of
strings with non-BMP characters, many functions can work around these
differences. For example, the ord() function already produces integers over
0x when given a surrogate pair as a string of length two on a narrow build.
Other functions such as str.isalpha(), are not yet aware of surrogates. See
also issue9200.
A consensus is developing that non-BMP characters support on narrow builds is
here to stay and that naive functions should be fixed. Unfortunately, working
with surrogates in python code is tricky because unicode C-API does not provide
much support and existing examples of surrogate processing look like this:
-while (u != uend w != wend) {
-if (0xD800 = u[0] u[0] = 0xDBFF
- 0xDC00 = u[1] u[1] = 0xDFFF)
-{
-*w = (((u[0] 0x3FF) 10) | (u[1] 0x3FF)) + 0x1;
-u += 2;
-}
-else {
-*w = *u;
-u++;
-}
-w++;
-}
The attached patch introduces a Py_UNICODE_NEXT() macro that allows replacing
the code above with two lines:
+while (u != uend w != wend)
+*w++ = Py_UNICODE_NEXT(u, uend);
The patch also introduces a set of macros for manipulating the surrogates, but
I have not started replacing more instances of verbose surrogate processing
because I would like to first look for higher level abstractions such as
Py_UNICODE_NEXT(). For example, there are many instances that can benefit from
Py_UNICODE_PUT_NEXT(ptr, ch) macro that would put a UCS4 character ch into
Py_UNICODE buffer pointed by ptr and advance ptr by 1 or 2 units as necessary.
[1] http://mail.python.org/pipermail/python-dev/2010-November/105908.html
--
assignee: belopolsky
components: Extension Modules, Interpreter Core, Unicode
files: unicode-next.diff
keywords: patch
messages: 122464
nosy: Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti,
lemburg, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Py_UNICODE_NEXT and other macros for surrogates
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19825/unicode-next.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10542
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] str.isprintable() is always False for large code points
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: AFAICT, all ctype methods (isalpha, isdigit, etc.) have the same problem. I posted a patch at issue10542 that introduces a Py_UNICODE_NEXT() macro that can help fixing all these methods. I am adding #10542 as a dependency and if there are no objections, I will change the title to extend the scope of this issue to cover all ctype methods. -- assignee: - belopolsky components: +Interpreter Core dependencies: +Py_UNICODE_NEXT and other macros for surrogates nosy: +belopolsky stage: - patch review type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- nosy: +haypo, loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10540] test_shutil fails on Windows after r86733
Brian Curtin cur...@acm.org added the comment: Here is a patch. os.path.samefile and hard links don't work for Windows the same way they do for Mac/Linux. In the case where we are on Windows and a link comes into the _samefile function, check that it's a link and then use os.path.sameopenfile. If it's not a link but a regular file, or it's some other OS, do the os.path.samefile check. -- keywords: +patch nosy: +tarek Added file: http://bugs.python.org/file19826/issue10540.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10540 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10543] Test discovery (unittest) does not work with jython
Changes by Michael Foord mich...@voidspace.org.uk: -- assignee: - michael.foord components: +Library (Lib) type: - behavior versions: +Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9509] argparse FileType raises ugly exception for missing file
Changes by SilentGhost michael.mischurow+...@gmail.com: Removed file: http://bugs.python.org/file19815/test_argparse.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9509] argparse FileType raises ugly exception for missing file
SilentGhost michael.mischurow+...@gmail.com added the comment: On windows proposed changes to Lib/test/test_argparse.py cause it to enter an infinite loop in TempDirMixin.tearDown method. As it seemed exclusively Windows issue, this new patch replaces while loop with the ignore_errors parameter for shutil.rmtree. Now all test pass. -- Added file: http://bugs.python.org/file19827/test_argparse.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10543] Test discovery (unittest) does not work with jython
Michael Foord mich...@voidspace.org.uk added the comment: Won't need fixing in 3.2. The __pycache__ changes mean that the module.__file__ no longer points to the compiled bytecode file. -- versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10543 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10535] Enable warnings by default in unittest
Michael Foord mich...@voidspace.org.uk added the comment: I'm also thinking that it might be better to include the name of the deprecated method in the message and use three filters for fail* methods, assert* methods, and the assert*Regexp* methods that will be deprecated. That sounds good, well - it sounds *essential*. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10535 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10539] Regular expression not checking 'range' element on 1st char in string.
Eric Smith e...@trueblade.com added the comment: I'm not sure I understand. The output I get is: f42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88 g42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88 False The first string matches. The second string matches because the leading g is being matched by \w. The third string does not match because the g in the second position is not matched by [0-9][a-f]. For the second string you're matching \w followed by 7 [0-9][a-f], just as the regex allows. Am I missing something? -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5211] Fix complex type to avoid coercion in 2.7.
Blair bidih...@gmail.com added the comment: I see your point Mark, however it does not seem to be the right way to do this. Are you aware that Python has formally specified this behaviour somewhere? I could not find an explicit reference in the documentation. The problem that has been fixed is covered in the documentation: (3.4.8. Emulating numeric types: Note If the right operandâs type is a subclass of the left operandâs type and that subclass provides the reflected method for the operation, this method will be called before the left operandâs non-reflected method. This behavior allows subclasses to override their ancestorsâ operations.) This rule is needed so that mixed-type arithmetic operations do not revert to the ancestor's type. However, one would expect that different numeric types (int float complex) would all behave in a similar way. For example, xi = xint(3) 3 + xi # is an xint(6) 3.0 + xi # is float(6) This is the same problem as the one that has been fixed from a practical point of view. Such behaviour is not going to be useful (IMO). It seems to me that xint.__radd__ would need to be called if the left operand is a subclass of any of the number types (in this case, isinstance(left_op,numbers.Complex) == True). Am I missing something? Mark Dickinson dicki...@gmail.com added the comment: I think that's expected behaviour. Note that int vs float behaves in the same way as float vs complex: ... def __radd__(self, other): ... print __radd__ ... return 42 ... 3 + xint(5) __radd__ 42 3.0 + xint(5) # xint.__radd__ not called. 8.0 As with your example, the float.__add__ method is happy to deal with an int or an instance of any subclass of int. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5211 ___ -- Added file: http://bugs.python.org/file19828/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5211 ___I see your point Mark, however it does not seem to be the right way to do this. brbrAre you aware that Python has formally specified this behaviour somewhere? I could not find an explicit reference in the documentation.br brThe problem that has been fixed is covered in the documentation:brbr(3.4.8. Emulating numeric types: NotebrIf the right operandâs type is a subclass of the left operandâs type and that subclass provides thebrreflected method for the operation, this method will be called before the left operandâs non-reflected method.br This behavior allows subclasses to override their ancestorsâ operations.)brbrThis rule is needed so that mixed-type arithmetic operations do not revert to the ancestor#39;s type. However, one would expect that different numeric types (int float complex) would all behave in a similar way. For example,br brxi = xint(3)br3 + xi # is an xint(6)br3.0 + xi # is float(6)brbrThis is the same problem as the one that has been fixed from a practical point of view. Such behaviour is not going to be useful (IMO). brbr It seems to me that xint.__radd__ would need to be called if the left operand is a subclass of any of the number types (in this case, isinstance(left_op,numbers.Complex) == True). brbrAm I missing something? brbr blockquote type=cite class=cite cite=Mark Dickinson lt;a href=mailto:dicki...@gmail.com;dicki...@gmail.com/agt; added the comment:brbr I think that#39;s expected behaviour. Note that int vs float behaves in the same way as float vs complex:brbr gt;gt;gt; class xint(int):br ...    def __radd__(self, other):br ...        print quot;__radd__quot;br ...        return 42br ... br gt;gt;gt; 3 + xint(5)br __radd__br 42br gt;gt;gt; 3.0 + xint(5) # xint.__radd__ not called.br 8.0brbr As with your example, the float.__add__ method is happy to deal with an int or an instance of any subclass of int.brbr --brbr ___br Python tracker lt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;br lt;a href=http://bugs.python.org/issue5211;http://bugs.python.org/issue5211/agt;br ___/blockquote ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10539] Regular expression not checking 'range' element on 1st char in string.
Georg Brandl ge...@python.org added the comment: I don't think so; closing as invalid. -- nosy: +georg.brandl resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10539 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10539] Regular expression not checking 'range' element on 1st char in string.
Jamie Murray txr...@gmail.com added the comment: Apologies, sincere and most humble apolgies doh! On 26 Nov 2010 18:51, Georg Brandl rep...@bugs.python.org wrote: Georg Brandl ge...@python.org added the comment: I don't think so; closing as invalid. -- nosy: +georg.brandl resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10539 ___ -- Added file: http://bugs.python.org/file19829/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10539 ___pApologies, sincere and most humble apolgies doh!/p div class=gmail_quoteOn 26 Nov 2010 18:51, quot;Georg Brandlquot; lt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt; wrote:br type=attributiongt; brgt; Georg Brandl lt;a href=mailto:ge...@python.org;ge...@python.org/agt; added the comment:br gt; brgt; I don#39;t think so; closing as invalid.brgt; brgt; --brgt; nosy: +georg.brandlbrgt; resolution: -gt; invalidbrgt; status: open -gt; closedbrgt; brgt; ___br gt; Python tracker lt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;brgt; lt;a href=http://bugs.python.org/issue10539;http://bugs.python.org/issue10539/agt;brgt; ___br /div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
New submission from Inyeol Lee inyeol@gmail.com: Simple coroutine with for loop works: def pack_a(): while True: L = [] for i in range(2): L.append((yield)) print(L) pa = pack_a() next(pa) pa.send(1) pa.send(2) [1, 2] If using list comprehension (generator expression), it fails: def pack_b(): while True: L = [(yield) for i in range(2)] print(L) pb = pack_b() endless loop here I understand what's going on here - generator expression is converted to nested function and there's no way to either stop the execution inside nested function (since it's not started yet!) or send() a value to its yield expression. Still I think this behavior is a bug and needs fixed. - best fix would make it behave the same as for loop. - if it's not fixable, yield expression inside genexp should not be allowed. -- components: Interpreter Core messages: 122475 nosy: Inyeol.Lee priority: normal severity: normal status: open title: yield expression inside generator expression does nothing type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10532] A bug related to matching the empty string
Ned Deily n...@acm.org added the comment: Closing this issue since it appears to not be a bug. -- nosy: +ned.deily resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10545] remove or rewrite Using Backslash to Continue Statements anti-idiom
New submission from rurpy the second ru...@yahoo.com: The Python HOWTOs-Idioms and Anti-Idioms has a section Using Backslash to Continue Statements. It says that line continuation is dangerous and gives two reasons. 1. Hard to see a space after the backslash. This is not dangerous as it cause an impossible-to-miss syntax error (as pointed out in the following sentence.) 2. It can cause other subtle errors. It gives a code example purporting to demonstrate this but without saying what the input data to the code is or what the resulting problem is. I spent a while trying to figure it out unsuccessfully. In http://www.mail-archive.com/python-l...@python.org/msg249344.html a number of c.l.p regulars did not figure it out either. I also note related bug http://bugs.python.org/issue7391 that points out that avoinding backslashed continuations with parens is not always possible. So I suggest... 1. If the the given example actually illustrates a real problem, document clearly what it is. This is a reference manual, not a quiz book. 2. If not, then remove that argument. Now the only reason for not using backslashes is that a hard-to-see space after the backslash will cause a syntax error. That is neither dangerous or a strong reason not to do it. An unstated reason is that PEP-8 recommends against it but its recommendation is not absolute and is based only on aethtetics. With no real arguments against using it other than style, it should not be documented as an anti-idiom, recommendations against it should remain only in PEP-8 with other such style guidelines, and this section should be removed from the Anti-Idioms chapter. -- assignee: d...@python components: Documentation messages: 122477 nosy: d...@python, rurpy2 priority: normal severity: normal status: open title: remove or rewrite Using Backslash to Continue Statements anti-idiom ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10545 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you paste something.
Ned Deily n...@acm.org added the comment: This appears to be another variant of the IDLE, OS X 10.6, 64-bit, Apple-supplied Tk 8.5 problems. As a workaround, you can re-install 2.7rc1 using the 32-bit-only installer; IDLE there does not exhibit these problems. -- assignee: - ned.deily components: +Macintosh nosy: +ned.deily, ronaldoussoren priority: normal - critical stage: - needs patch title: IDLE crashes when you paste something. - OS X IDLE 2.7rc1 from 64-bit installer hangs when you paste something. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10546] UTF-16-LE and UTF-16-BE support non-BMP characters
New submission from STINNER Victor victor.stin...@haypocalc.com: Python3 doc tells that UTF-16-LE and UTF-16-BE only support BMP characters. What? I think that it is wrong. It was maybe wrong with Python2 and narrow build (unichr() only supports BMP characters), but it is no more true in Python3. -- assignee: d...@python components: Documentation files: utf_16_bmp.patch keywords: patch messages: 122479 nosy: d...@python, haypo priority: normal severity: normal status: open title: UTF-16-LE and UTF-16-BE support non-BMP characters versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19830/utf_16_bmp.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1178] IDLE - add paste code functionality
Terry J. Reedy tjre...@udel.edu added the comment: I would really like something like this -- for 3.2b1 next week. I am constantly running posted interactive code and the lack of this is a major nuisance. There seems to be a glitch in how the editor deals with ' ' when trying to delete it. However, as well as removing ' ' and '... ' from code lines, I would like it to add '# ' to output lines. I do not see that in the patch. Since I have XP also (and access to Win7) I would consider this working on those two sufficient reason to commit. As near as I can tell, the patch cannot possibly break other systems as long as the feature is not used. Once in the beta, it could get wider testing. -- nosy: +terry.reedy -nobody priority: low - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1178] IDLE - add paste code functionality
Terry J. Reedy tjre...@udel.edu added the comment: An alternative approach would be to leave pasting alone but add a 'Convert interactive code' option to the format menu, with keycode alt-v (not currently used as far as I can see). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Éric Araujo mer...@netwok.org added the comment: New features don’t go into stable branches. The patch is also reviewable at http://codereview.appspot.com/3340041 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build
Terry J. Reedy tjre...@udel.edu added the comment: As a practical matter, I think that for at least the next decade, people are at least as likely to want to fill with a composed, multi-BMP-codepoint 'char' (grapheme) as with a non-BMP char. So to me, failure with the latter is no worse than failure with the former. The underlying problem is that centering k chars within n spaces with fill i is based on one-char per code encodings *and* fixed pitch fonts with one-char per space. That model is not universally applicable, so I do not consider it a bug that functions based on that model are also not universally applicable. Perhaps docs should be clearer about the limitations of many of the string methods in the new context. A full general solution to the general problem of centering requires a shift to physical units (points or mm) and detailed font information, including kerning. This is beyond the scope of a string method. So I consider this a feature request for a partial generalization of unclear utility and unclear definition. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you paste something.
Terry J. Reedy tjre...@udel.edu added the comment: Is this a duplicate of other issues (close?)? Is this an Apple problem beyond our control (close?)? -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9312] Fix usage of :option: markup in stdlib ReST docs
Éric Araujo mer...@netwok.org added the comment: Great, thanks! New markup committed as r86823, long lines rewrapped in r86824 (along with a few minor touch-ups). I think we’re good now, I’ll backport shortly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1059244] distutil bdist hardcodes the python location
Éric Araujo mer...@netwok.org added the comment: Distutils2 bugs are tracked here (bugs.python.org), feel free to open a feature request for the Distutils2 component. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1059244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Nov 26, 2010 at 6:37 PM, Terry J. Reedy rep...@bugs.python.org wrote:
Terry J. Reedy tjre...@udel.edu added the comment:
As a practical matter, I think that for at least the next decade, people are
at least as likely to
want to fill with a composed, multi-BMP-codepoint 'char' (grapheme) as with a
non-BMP char.
So to me, failure with the latter is no worse than failure with the former.
I disagree. '\N{AEGEAN WORD SEPARATOR DOT}' ('ā') looks like a
reasonably shaped fill character, while say 'Z\N{COMBINING ACUTE
ACCENT}\N{COMBINING GRAVE ACCENT}' ('Ź̀') does not. Yet this is not
the point of this bug report. The point is that Python user should
not care (much) about how many bytes per character Python uses under
the hood or what is the numeric value of the character that she can
enter in her program.
The underlying problem is that centering k chars within n spaces with fill i
is based
on one-char per code encodings *and* fixed pitch fonts with one-char per
space.
No. ' Section Title '.center(40, '*') will look good regardless of
font width and even more so when combined with center tag or its
equivalent in a given application.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10521
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build
Eric Smith e...@trueblade.com added the comment: I think these macros would be a reasonable approach. I think str.center, etc. should support non-BMP chars, because to not do so can raise an exception. Supporting composed graphemes seems like another problem altogether. And while we could fix that, it's clearly a larger step. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Eric Smith e...@trueblade.com added the comment: In addition to the proposed Py_UNICODE_NEXT and Py_UNICODE_PUT_NEXT, str.__format__ would also need a function that tells it how many Py_UNICODEs are needed to store a given Py_UCS4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Fri, Nov 26, 2010 at 7:27 PM, Eric Smith rep...@bugs.python.org wrote: .. In addition to the proposed Py_UNICODE_NEXT and Py_UNICODE_PUT_NEXT, str.__format__ would also need a function that tells it how many Py_UNICODEs are needed to store a given Py_UCS4. Yes, this functionality is currently hidden in unicode_aswidechar(PyUnicodeObject *unicode, wchar_t *w, Py_ssize_t size): /* Helper function for PyUnicode_AsWideChar() and PyUnicode_AsWideCharString(): convert a Unicode object to a wide character string. - If w is NULL: return the number of wide characters (including the nul character) required to convert the unicode object. Ignore size argument. .. */ and I believe is reimplemented in a few other places. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9264] trace.py documentation is incomplete
Éric Araujo mer...@netwok.org added the comment: Divided command-line options logically into sub-sections and improved their explanations Using the program/cmdoption combo may be a good idea here. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Eric Smith e...@trueblade.com added the comment: I'd need access to this without having to build a PyUnicodeObject, for efficiency. But it sounds like it does have the basic functionality I need. For my use I'd really need it to take the result of Py_UNICODE_NEXT. Something like: Py_ssize_t Py_UNICODE_NUM_NEEDED(Py_UCS4 c) and it would always return 1 or 2. Always 1 for a wide build, and for a narrow build 1 if c is in the BMP else 2. Choose a better name, of course. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10299] Add index with links section for built-in functions
Éric Araujo mer...@netwok.org added the comment: Possible groups: Types constructors: bool, bytearray, bytes, complex, dict, float, frozenset, int, list, memoryview, object, range, set, slice, str, tuple Mathematical functions: abs, bin, divmod, hex, oct, pow, round Working with sequences: all, any, enumerate, filter, iter, len, map, max, min, reversed, sorted, sum, zip Working with strings: chr, format, ord I/O: input, open, print Introspection/metaprogramming: ascii, delattr, dir, getattr, globals, hasattr, help, id, isinstance, issubclass, locals, repr, setattr, type, vars Advanced functions: classmethod, compile, eval, exec, hash, next, property, staticmethod, super, __import__ The last two are debatable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Fri, Nov 26, 2010 at 7:45 PM, Eric Smith rep...@bugs.python.org wrote: .. For my use I'd really need it to take the result of Py_UNICODE_NEXT. Something like: Py_ssize_t Py_UNICODE_NUM_NEEDED(Py_UCS4 c) and it would always return 1 or 2. Always 1 for a wide build, and for a narrow build 1 if c is in the BMP else 2. Choose a better name, of course. Can you describe your use case in more detail? Would Py_UNICODE_PUT_NEXT() combined with Py_UNICODE_CODEPOINT_COUNT(Py_UNICODE *begin, Py_UNICODE *end) solve it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10541] regrtest.py -T broken
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10541 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
STINNER Victor victor.stin...@haypocalc.com added the comment: I don't like macro having a result and using multiple instructions using the evil magic trick (the ,). It's harder to maintain the code and harder to debug than a classical function. Don't you think that modern compilers are able to inline the code? (If not, we may add the right C attribute/keyword) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10507] Check well-formedness of reST markup within make patchcheck
Éric Araujo mer...@netwok.org added the comment: Have a look at Doc/tools/rstlint.py -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Eric Smith e...@trueblade.com added the comment:
The code will basically be:
Py_UCS4 fill;
parse_format_string(fmt, ..., fill, ...);
/* lots more code */
if (fill_needed) {
/* compute how many characters to reserve */
space_needed = Py_UNICODE_NUM_NEEDED(fill) *
number_of_characters_to_fill;
}
It would be most convenient (and require the fewest changes) if the computation
could just use fill, instead of remembering the pointers to the beginning and
end of fill.
Py_UNICODE_CODEPOINT_COUNT could be implemented with a primitive that does what
I want.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10542
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5211] Fix complex type to avoid coercion in 2.7.
Blair bidih...@gmail.com added the comment: I'd like to add a few more observations to the mix. I have run the following in both 2.6.6 and in 2.7 class xfloat(float): def __new__(cls,x): return float.__new__(cls,x) def __radd__(self,lhs): print __radd__ got: %s % type(lhs) if isinstance(lhs,(int,float)): return xfloat( float(self) + lhs ) else: return NotImplemented xf = xfloat(9.0) cases = dict(int=1,float=1.0,complex=1.0+1j) for k,v in cases.items(): y = v + xf print %s + xfloat % k print type(y) print y In 2.7 this gives: __radd__ got: type 'int' int + xfloat class '__main__.xfloat' 10.0 __radd__ got: type 'float' float + xfloat class '__main__.xfloat' 10.0 complex + xfloat type 'complex' (10+1j) In 2.6.6 I get: __radd__ got: type 'int' int + xfloat class '__main__.xfloat' 10.0 __radd__ got: type 'float' float + xfloat class '__main__.xfloat' 10.0 __radd__ got: type 'complex' complex + xfloat type 'complex' (10+1j) They are the same except for the last case. My feeling is that the behaviour of 2.6.6 (for subclassing float) is correct. The behaviour of 2.6.6 is needed to enable you to implement the commutative property of addition (ie, you expect to get the same outcome from x+y or y+x), which I would say is a pretty fundamental requirement. I have also tried the following class xint(int): def __new__(cls,x): return int.__new__(cls,x) def __radd__(self,lhs): print __radd__ got: %s % type(lhs) if isinstance(lhs,(int,)): return xint( float(self) + lhs ) else: return NotImplemented print print --- xf = xint(9) cases = dict(int=1,float=1.0,complex=1.0+1j) for k,v in cases.items(): y = v + xf print %s + xint % k print type(y) print y In 2.6.6 I get __radd__ got: type 'int' int + xint class '__main__.xint' 10 float + xint type 'float' 10.0 __radd__ got: type 'complex' complex + xint type 'complex' (10+1j) and in 2.7 --- __radd__ got: type 'int' int + xint class '__main__.xint' 10 float + xint type 'float' 10.0 complex + xint type 'complex' (10+1j) In my opinion, 2.6.6 was faulty in the float + xint case, for the same reasons as above, and 2.7 is faulty in both float + xint and complex + xint. -- Added file: http://bugs.python.org/file19832/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5211 ___I#39;d like to add a few more observations to the mix.brbrI have run the following in both 2.6.6 and in 2.7brbrclass xfloat(float):br   def __new__(cls,x):br       return float.__new__(cls,x)brbr   def __radd__(self,lhs):br        print quot;__radd__ got: %squot; % type(lhs)br       if isinstance(lhs,(int,float)):br           return xfloat( float(self) + lhs )br       else:br           return NotImplementedbrbrbrxf = xfloat(9.0)br brcases = dict(int=1,float=1.0,complex=1.0+1j)brfor k,v in cases.items():br   y = v + xfbr   print quot;%s + xfloatquot; % kbr   print type(y)br   print ybrbrIn 2.7 this gives:brbr__radd__ got: lt;type #39;int#39;gt;br int + xfloatbrlt;class #39;__main__.xfloat#39;gt;br10.0br__radd__ got: lt;type #39;float#39;gt;brfloat + xfloatbrlt;class #39;__main__.xfloat#39;gt;br10.0brcomplex + xfloatbrlt;type #39;complex#39;gt;br (10+1j)brbrIn 2.6.6 I get:brbr__radd__ got: lt;type #39;int#39;gt;brint + xfloatbrlt;class #39;__main__.xfloat#39;gt;br10.0br__radd__ got: lt;type #39;float#39;gt;brfloat + xfloatbrlt;class #39;__main__.xfloat#39;gt;br 10.0br__radd__ got: lt;type #39;complex#39;gt;brcomplex + xfloatbrlt;type #39;complex#39;gt;br(10+1j)brbrThey are the same except for the last case.brbrMy feeling is that the behaviour of 2.6.6 (for subclassing float) is correct.br brThe behaviour of 2.6.6 is needed to enable you to implement the commutative property of addition (ie, you expect to get the same outcome from x+y or y+x), which I would say is a pretty fundamental requirement.brbr I have also tried the followingbrbrclass xint(int):br   def __new__(cls,x):br       return int.__new__(cls,x)       brbr   def __radd__(self,lhs):br       print quot;__radd__ got: %squot; % type(lhs)br        if isinstance(lhs,(int,)):br           return xint( float(self) + lhs )br       else:br           return NotImplementedbrbrprintbrprint quot;---quot;brxf = xint(9)brbrcases = dict(int=1,float=1.0,complex=1.0+1j)br for k,v in cases.items():br   y = v + xfbr   print quot;%s + xintquot; % kbr   print type(y)br   print ybr   brIn 2.6.6 I getbrbr__radd__ got: lt;type #39;int#39;gt;brint + xintbrlt;class #39;__main__.xint#39;gt;br 10brfloat + xintbrlt;type #39;float#39;gt;br10.0br__radd__
[issue9200] str.isprintable() is always False for large code points
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Attached patch fixes isprintable and other ctype-like methods. I left
isspace() out for now because I could not find a test character outside of BMP
to test with, but I think we should fix that for completeness as well.
At this point the goal is mostly to showcase Py_UNICODE_NEXT(), not
completeness. See issue10542.
I also noticed that upper/lower/swapcase methods have the same issue:
'\N{MATHEMATICAL BOLD CAPITAL A}'.lower() == '\N{MATHEMATICAL BOLD CAPITAL
A}'
True
This will be a subject of a separate issue.
--
Added file: http://bugs.python.org/file19831/issue9200.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9200
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Fri, Nov 26, 2010 at 8:41 PM, STINNER Victor rep...@bugs.python.org wrote: .. I don't like macro having a result and using multiple instructions using the evil magic trick (the ,). It's harder to maintain the code and harder to debug than a classical function. You are preaching to the choir. In fact, my first version (issue10521-unicode-next.diff attached to issue10521) used a function. I would not worry about implementation at this point, though. Let's find the best abstraction first. Don't you think that modern compilers are able to inline the code? (If not, we may add the right C attribute/keyword) Not in C. In C++, I could use a reference to the pointer incremented by the macro, but in C, I have to use an address. Once you take an address of a variable, the compiler will refuse to put it in a register. So no, I don't think we can write an ANSI C function that will be as efficient as the macro. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Eric Smith e...@trueblade.com added the comment: The compiler's decision to inline something should not be related to its ability to put variables in a register. But I definitely agree that we should get the abstraction right first and worry about the implementation later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Fri, Nov 26, 2010 at 9:22 PM, Eric Smith rep...@bugs.python.org wrote: .. But I definitely agree that we should get the abstraction right first and worry about the implementation later. I am fairly happy with Py_UNICODE_NEXT() abstraction. It's semantics should be natural for users familiar with python iterators and the fact that it expands to simply *ptr++ on wide builds makes it easy to explain its usage. I am note very happy about the end argument for the following reasons: 1. Builtin next() takes the default value as a second argument. Extension writers may expect the same from Py_UNICODE_NEXT(). The name end should be self-explainatory though, especially to those with an exposure to STL. 2. If Py_UNICODE_NEXT() stays as a macro, an innocent looking Py_UNICODE_NEXT(p, p + size) will have a hard to detect bug. Can be fixed by making Py_UNICODE_NEXT() a function. I wonder whether it is best to prefix the new macros with an underscore. On one hand, we want to make this available to extension writers, on the other hand, once more people start dealing with non-BMP issues, a better abstraction may be found and we man not want to maintain Py_UNICODE_NEXT() indefinitely. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Raymond, I wonder if you would like to comment on the iterator analogy and/or on adding public names to C API. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8600] test_gdb failures
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Mark, can you opine on this? -- assignee: belopolsky - lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you paste something.
Ronald Oussoren ronaldousso...@mac.com added the comment: On 27 Nov, 2010, at 0:42, Terry J. Reedy wrote: Terry J. Reedy tjre...@udel.edu added the comment: Is this a duplicate of other issues (close?)? I don't know yet. Is this an Apple problem beyond our control (close?)? This might be fixable. There is a patch that improves AquaTk 8.5 support which I need to integrate/test. Ronald -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you paste something.
Ned Deily n...@acm.org added the comment: Ronald, which patch are you thinking of? Issue6075? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
