[issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation

Raymond Hettinger added the comment: > this is well formed xml and has nothing to do with tail. In fact, it does have something to do with tail. The 'TEXT' is a captured as the tail of element b: >>> root3 = ET.fromstring('TEXT') >>> root3[0].tail 'TEXT' -- nosy: +eli.bendersky, rhetti

[issue24076] sum() several times slower on Python 3

Stefan Behnel added the comment: > there are three ingredients here - sum, (x)range and the integer addition > that sum will be performing at each iteration. ... not to forget the interpreter startup time on his machine. :) I did a tiny bit of profiling and about 90% of the time seems to be sp

[issue24005] Documentation Error: Extra line Break

Jaivish Kothari added the comment: Thanks for support . I agree it is not a bug at all but just as Tim said it would be easy to copy paste code directly to interpreter with such changes. This was my first contribution in python though not accepted , it is ok :) . I'll try to contribute more to

[issue24076] sum() several times slower on Python 3

Mark Dickinson added the comment: Throwing out sum, I'm seeing significant slowdown simply from xrange versus range: taniyama:Desktop mdickinson$ python2 -m timeit -s 'x = xrange(3, 10**9, 3)' 'for e in x: pass' 10 loops, best of 3: 5.01 sec per loop taniyama:Desktop mdickinson$ python3 -m tim

[issue24076] sum() several times slower on Python 3

Mark Dickinson added the comment: Łukasz: there are three ingredients here - sum, (x)range and the integer addition that sum will be performing at each iteration. Is there any chance you can separate the effects on your machine? On my machine (OS X, 64-bit), I'm seeing *some* speed difference

[issue24050] [2.7] crash in third party module mopidy

Changes by R. David Murray : -- resolution: not a bug -> third party stage: -> resolved ___ Python tracker ___ ___ Python-bugs-list m

[issue24075] list.sort() should do quick exit if len(list) <= 1

Mark Dickinson added the comment: > I should also clarify that Raymond and Mark and responsible for maintaining most of the algorithmic/data structure code in Python. Well, Raymond at least. I plead not guilty; I think you're confusing me with someone else. :-) But for this issue, this mathem

[issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation

Ned Deily added the comment: (This issue is a followup to your Issue24072.) Again, while the ElementTree documentation is certainly not nearly as complete as it should be, I don't think this is a documentation error per se. The key issue is: with which element is each text string associated?

[issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation

New submission from Jérôme Laurens: The documentation for xml.etree.ElementTree.Element.text reads "If the element is created from an XML file the attribute will contain any text found between the element tags." import xml.etree.ElementTree as ET root3 = ET.fromstring('TEXT') print(root3.text)

[issue24078] inspect.getsourcelines ignores context and returns wrong line #

Siming Yuan added the comment: according to inspect.py line 675 - this is only a best effort. is this intended? inspect.py @ 672 if isclass(object): name = object.__name__ pat = re.compile(r'^(\s*)class\s*' + name + r'\b') # make some effort to find the best matching

[issue24078] inspect.getsourcelines ignores context and returns wrong line #

New submission from Siming Yuan: if the same class name is used within a module, but defined in different contexts (either class in class or class in function), inspect.getsourcelines() on the class object ignores the object context and only returns the first matched name. reproduce: a.py --

[issue24077] man page says -I implies -S. code says -s.

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue24077] man page says -I implies -S. code says -s.

Ned Deily added the comment: Thanks for the report, John! -- nosy: +ned.deily resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ _

[issue24077] man page says -I implies -S. code says -s.

Roundup Robot added the comment: New changeset d774401879d8 by Ned Deily in branch '3.4': Issue #24077: Fix typo in man page for -I command option: -s, not -S. https://hg.python.org/cpython/rev/d774401879d8 New changeset 493b3310d5d0 by Ned Deily in branch 'default': Issue #24077: merge from 3.4

[issue24077] man page says -I implies -S. code says -s.

John Beck added the comment: Thank you very much for clarifying that. I have updated the bug Title accordingly. -- title: man page says -I implies -S. code says -s. Should it be both? -> man page says -I implies -S. code says -s. ___ Python tracker

[issue24077] man page says -I implies -S. code says -s. Should it be both?

Changes by Ned Deily : -- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python stage: -> needs patch ___ Python tracker ___

[issue24077] man page says -I implies -S. code says -s. Should it be both?

Christian Heimes added the comment: The isolated mode implies -E (ignore env vars) and -s (don't add user site directory). The code and tests are correct, just the man page is wrong. The site module is still loaded in -I mode as it doesn't impose any security implications. I'd looks like I ma

[issue24077] man page says -I implies -S. code says -s. Should it be both?

John Beck added the comment: Adding Christian Heimes to the nosy list; as the author of the fix for issue 16499, he seems an excellent person to answer the question and offer advice on the approaches discussed herein. -- nosy: +christian.heimes ___ Py

[issue24077] man page says -I implies -S. code says -s. Should it be both?

New submission from John Beck: The man page for Python (3.4 and 3.5) says: -I Run Python in isolated mode. This also implies -E and -S. In isolated mode sys.path contains neither the scripts directory nor the users site-packages directory. All PYTHON* environm

[issue15809] 2.7 IDLE console uses incorrect encoding.

Terry J. Reedy added the comment: #19625, with a bit of discussion, was closed as a duplicate of this issue. -- ___ Python tracker ___ ___

[issue24075] list.sort() should do quick exit if len(list) <= 1

Changes by Sergey B Kirpichev : Added file: http://bugs.python.org/file39232/0001-list.sort-Add-quick-exit-if-length-of-list-1.patch ___ Python tracker ___ _

[issue24075] list.sort() should do quick exit if len(list) <= 1

Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 06:51:21PM +, Paul Moore wrote: > But that's a sort without a key. Why it does matter? It have quick exit. For same reasons - Python could... > In Perl you do a key sort via: That's just your implementation. But we could add

[issue1298835] Add a vendor-packages directory for system-supplied modules

Changes by John Beck : -- nosy: +jbeck ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue24075] list.sort() should do quick exit if len(list) <= 1

Benjamin Peterson added the comment: On Wed, Apr 29, 2015, at 13:25, Sergey B Kirpichev wrote: > > Sergey B Kirpichev added the comment: > > On Wed, Apr 29, 2015 at 03:25:19PM +, Benjamin Peterson wrote: > > So, basically you need a base case for recursion? What's wrong with > > explicitly

[issue24076] sum() several times slower on Python 3

Antoine Pitrou added the comment: If that's due to the different representation of Python 2's int type and Python 3's int type then I don't see an easy solution to this. -- versions: -Python 3.4 ___ Python tracker

[issue24076] sum() several times slower on Python 3

Łukasz Langa added the comment: Serhiy, this is 64-bit specific. Antoine, as far as I can tell, the main use case is: "Don't make it look like migrating to Python 3 is a terrible performance downgrade." As we discussed on the language summit this year [1], we have to be at least not worse to

[issue24076] sum() several times slower on Python 3

Antoine Pitrou added the comment: I reproduce under 64-bit Linux. So this may be because the Python long digit (30 bits) is smaller than the C long (64 bits). Lukasz: is there a specific use case? Note you can use Numpy for such calculations. -- __

[issue24076] sum() several times slower on Python 3

Serhiy Storchaka added the comment: Can't reproduce on 32-bit Linux. $ time python2.7 -c "print sum(xrange(3, 10**9, 3)) + sum(xrange(5, 10**9, 5)) - sum(xrange(15, 10**9, 15))" 216668 real1m11.614s user1m11.376s sys 0m0.056s $ time python3.4 -c "print(sum(range(3, 10**

[issue24075] list.sort() should do quick exit if len(list) <= 1

Paul Moore added the comment: On 29 April 2015 at 19:42, Sergey B Kirpichev wrote: >> It's a common computer science technique > > Could you provide any language that avoid this optimization? > > Here is Perl 5: > http://perl5.git.perl.org/perl.git/blob/HEAD:/pp_sort.c#l367 > > (third example)

[issue24076] sum() several times slower on Python 3

New submission from Łukasz Langa: I got a report that summing numbers is noticably slower on Python 3. This is easily reproducible: $ time python2.7 -c "print sum(xrange(3, 10**9, 3)) + sum(xrange(5, 10**9, 5)) - sum(xrange(15, 10**9, 15))" 216668 real0m6.165s user0m6.100

[issue24075] list.sort() should do quick exit if len(list) <= 1

Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 05:44:22PM +, Paul Moore wrote: > I think the documentation is fine: > """ > The key corresponding to each item in the list is calculated once and then > used for the entire sorting process. > """ Does any "sorting process" make

[issue24075] list.sort() should do quick exit if len(list) <= 1

Paul Moore added the comment: I think the documentation is fine: """ The key corresponding to each item in the list is calculated once and then used for the entire sorting process. """ This corresponds with the standard "decorate-sort-undecorate" approach to handling key functions in sorts. I

[issue24075] list.sort() should do quick exit if len(list) <= 1

Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 03:25:19PM +, Benjamin Peterson wrote: > So, basically you need a base case for recursion? What's wrong with > explicitly writing that out? Because it's complex (and costly). This is not a trivial test and I don't see reasons to

[issue23910] property_descr_get reuse argument tuple

Joe Jevnik added the comment: I don't think that we need to worry about reusing the single argument tuple in a recursive situation because we never need the value after we start the call. We also just write our new value and then clean up with a NULL to make sure that we don't blow up when we

[issue23910] C implementation of namedtuple (WIP)

Raymond Hettinger added the comment: > 0.0699 usec per loop --> 0.0468 That's pretty good for a small patch :-) For the pre-computed 1-tuple, I think you need to check for a refcnt of 1 and fallback to PyTuple_New if the tuple is in use (i.e. a property that calls another property). See O

[issue24075] list.sort() should do quick exit if len(list) <= 1

Benjamin Peterson added the comment: On Wed, Apr 29, 2015, at 11:03, Sergey B Kirpichev wrote: > > Sergey B Kirpichev added the comment: > > On Wed, Apr 29, 2015 at 02:32:34PM +, Benjamin Peterson wrote: > > Why does your key function depend on the size of the list? > > Because it's a real

[issue24075] list.sort() should do quick exit if len(list) <= 1

Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 02:32:34PM +, Benjamin Peterson wrote: > Why does your key function depend on the size of the list? Because it's a real life. Here is the code: https://github.com/skirpichev/omg/blob/gruntz-use-subs/sympy/series/gruntz.py#L337 A

[issue24075] list.sort() should do quick exit if len(list) <= 1

Changes by Benjamin Peterson : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24075] list.sort() should do quick exit if len(list) <= 1

Mark Dickinson added the comment: > Considering calling the key function is observable behavior, I don't think > this should be changed. +1 -- nosy: +mark.dickinson ___ Python tracker

[issue24075] list.sort() should do quick exit if len(list) <= 1

Raymond Hettinger added the comment: FWIW, I don't think this is worth special casing. -- ___ Python tracker ___ ___ Python-bugs-list

[issue19625] IDLE 2.7 should use UTF-8 as it's default encoding

irdb added the comment: On cmd and powershell: >python -c "import sys; print(sys.getdefaultencoding());" utf-8 >python -c "import sys; print(sys.stdout.encoding);" cp720 In IDLE: >>> import sys; print(sys.getdefaultencoding()); utf-8 >>> sys.stdout.encoding 'cp1256' -- ___

[issue24075] list.sort() should do quick exit if len(list) <= 1

Stéphane Wirtel added the comment: Yep, add a regression test. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue24075] list.sort() should do quick exit if len(list) <= 1

Benjamin Peterson added the comment: Why does your key function depend on the size of the list? That seems like the root of the problem. Considering calling the key function is observable behavior, I don't think this should be changed. The patch makes behavior list.sort() inconsistent. --

[issue24075] list.sort() should do quick exit if len(list) <= 1

Changes by Serhiy Storchaka : -- nosy: +rhettinger, tim.peters stage: -> patch review type: behavior -> performance versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 ___ Python tracker ___

[issue24075] list.sort() should do quick exit if len(list) <= 1

Sergey B Kirpichev added the comment: should I add a regression test? If so, where? ./Lib/test/test_sort.py? -- ___ Python tracker ___ _

[issue19625] IDLE 2.7 should use UTF-8 as it's default encoding

irdb added the comment: Although in Python 3 IDLE can indeed print UTF-8 characters. But still sys.stdout.encoding == locale.getpreferredencoding() != 'utf-8'. >>> sys.stdout.encoding 'cp1256' Shouldn't it be 'utf-8'? -- ___ Python tracker

[issue19625] IDLE 2.7 should use UTF-8 as it's default encoding

Stéphane Wirtel added the comment: On OS X and with IDLE 3, I get utf-8 with sys.stdout.encoding, not sure, but I think you have to check the default encoding on Windows. What’s the result if you execute: python3 -c 'import sys; print(sys.getdefaultencoding())' -- nosy: +matrixise __

[issue24075] list.sort() should do quick exit if len(list) <= 1

Stéphane Wirtel added the comment: The patch is ok for me, -- nosy: +matrixise, r.david.murray ___ Python tracker ___ ___ Python-bugs-

[issue24075] list.sort() should do quick exit if len(list) <= 1

New submission from Sergey B Kirpichev: If there is nothing to sort (i.e. one item), why call key function at all? In my practical situation, simplest key() function will lead to recursion in case of such trivial lists. I can make similar cmp-type function (i.e. mycmp=lambda a, b: cmp(key(a),

[issue21243] Auto-generate exceptions.c from a Python file

Brett Cannon added the comment: All of the exception code is written in C. My hypothesis is that it isn't necessary to define *all* exceptions in C. Using a technique similar to importlib, I suspect we could write a bunch of the exceptions that are not critical to interpreter startup in Python

[issue24069] Option to delete obsolete bytecode files

Changes by Brett Cannon : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17908] Unittest runner needs an option to call gc.collect() after each test

Antoine Pitrou added the comment: Le 28/04/2015 21:00, Robert Collins a écrit : > So you could add this as a hook to the loader (decorate each test > with some new thing) and a CLI option to use that hook for a gc > collect call. Can I take this as meaning you're not opposed to adding other opti

[issue21243] Auto-generate exceptions.c from a Python file

Stéphane Wirtel added the comment: I think I have understood your issue, but can you explain with more details. If I can develop this part, I can propose a patch for your issue. Thank you for your time -- nosy: +matrixise ___ Python tracker

[issue24073] sys.stdin.mode can not give the right mode and os.fdopen does not check argument

Xiang Zhang added the comment: Thanks for your reply Ned and it does solve my puzzle. It's my fault to misunderstand the attribute and make noise here. -- ___ Python tracker ___

[issue8538] Add FlagAction to argparse

Changes by Wolfgang Maier : -- nosy: +wolma ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue24074] string, center, ljust, rjust, width paramter should accept None

Raymond Hettinger added the comment: Sorry, this use case seems contrived. The common use case for centering is with a known width (otherwise, what is the point). Also, it isn't hard to write something like: s.center(w or 0) -- nosy: +rhettinger priority: normal -> low type: beha

[issue24073] sys.stdin.mode can not give the right mode and os.fdopen does not check argument

Ned Deily added the comment: I think the issue here is that you are expecting the "mode" attribute of a file object (or io.* object in Py3) to reflect the "readable" and "writeable" access mode of the underlying file descriptor (for POSIX-like systems). But, as noted in the documentation for