[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 options to the unittest core? (say, something to run a test until failure, or to watch for reference leaks, or to run tests in multiple processes :-)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the Py3 io.* objects and Py2 file object, their mode attributes reflect the mode given in the object constructor (for io.*) or the open() built-in (for Py2). The default sys.stdin object will always be created as a readable file/io object from Python's perspective but that doesn't mean that any file descriptor to which the object might refer actually allows read access. That may not be determined until your program does something that causes a call to the system runtime libraries that requires read access to the file, for example, sys.stdin.read() or, for Py2, os.fdopen(sys.stdin.fileno()). (As documented, the Py3 os.fdopen is an alias of the open() built-in.) If you need to know the access mode of a particular fi le descriptor, you can use fcntl.fcntl() F_GETFL function to examine the access mode of the fd. Or you could just use try/except blocks to catch exceptions. https://docs.python.org/3/library/os.html#os.open https://docs.python.org/3/library/io.html#io.FileIO https://docs.python.org/2/library/stdtypes.html#file.mode https://docs.python.org/3/library/fcntl.html#fcntl.fcntl http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html -- nosy: +ned.deily resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue21243 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: behavior - enhancement versions: +Python 3.5 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8538] Add FlagAction to argparse
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de: -- nosy: +wolma ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8538 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23882] unittest discovery doesn't detect namespace packages when given no parameters
Alex Shkop added the comment: Yes. That is how issue23882_find_all.patch works. I just removed hte condition if (not namespace and not os.path.isfile(os.path.join(full_path, '__init__.py'))): return None, False This makes namespace parameter redundant. Can I remove it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23882 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24056] Expose closure generator status in function repr()
Nick Coghlan added the comment:
It's mostly pedagogical - similar to normal functions vs generator
functions, folks talk about functions and closures as different things, even
though in Python a closure is just a normal function with one or more
references to cells that were defined in outer scopes.
Having that show up in the repr() then becomes a way of clarifying that some,
but not all, Python function objects are closures, even though closures aren't
represented as a distinct type.
That difference also shows up in the bytecode that creates them (note the
MAKE_FUNCTION vs MAKE_CLOSURE):
def outer():
... x = 1
... def inner_function():
... pass
... def inner_closure():
... return x
...
import dis
dis.dis(outer)
2 0 LOAD_CONST 1 (1)
3 STORE_DEREF 0 (x)
3 6 LOAD_CONST 2 (code object inner_function at
0x7fade75e5c90, file stdin, line 3)
9 LOAD_CONST 3 ('outer.locals.inner_function')
12 MAKE_FUNCTION0
15 STORE_FAST 0 (inner_function)
5 18 LOAD_CLOSURE 0 (x)
21 BUILD_TUPLE 1
24 LOAD_CONST 4 (code object inner_closure at
0x7fade75e5a50, file stdin, line 5)
27 LOAD_CONST 5 ('outer.locals.inner_closure')
30 MAKE_CLOSURE 0
33 STORE_FAST 1 (inner_closure)
36 LOAD_CONST 0 (None)
39 RETURN_VALUE
One particular case where the distinction matters and is known to be genuinely
confusing for new Python users is the late binding behaviour of closures:
lambda: i # closure
lambda i=i: i # not a closure
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24056
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24074] string, center, ljust, rjust, width paramter should accept None
New submission from Glen Fletcher: I've only list python 2.7, as I'm not sure that version 3 doesn't accept None, if so this should be changed there too. If these function are passed None, as the width they should return the string unchanged, just as they would for with a width set to 0. Reasoning, A common use of these would be in list comprehensions and such, i.e. (string.center(encode(i), w) for i, w in items, widths), given the that items and widths may be of differing length in theory i should be a empty string and width 0 it not specified however the best way of dealing with this would be to use itertools.izip_longest(items, widths, default=None) and None would be encode as No Value, however this would require writing (string.center(encode(i), 0 if w is None else w) for i, w in itertools.izip_longest(items, widths, default=None)), which is far harder to follow, when its quite reasonable to expect these string alignment functions to return an unpadded string if passed None as the width. -- components: Library (Lib) messages: 242215 nosy: glenflet priority: normal severity: normal status: open title: string, center, ljust, rjust, width paramter should accept None type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24074 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 for easier maintenance and usage by other interpreters. You would need to make sure the Python objects did get set on the proper C global variables for access by C extension code. You could use BaseException or something temporarily for all exceptions before loading the Python code and then replace the temporary placeholders with the actual exceptions. IOW, you would need to: 1. Identify which exceptions are necessary to load the Python code holding some built-in exceptions 2. Write Python code for the exceptions which are not necessary for interpreter startup 3. Load the Python file during startup ala importlib 4. Make sure the exceptions make it into the builtin namespace 5. Make sure the exceptions end up in the proper C global variables -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21243 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24069] Option to delete obsolete bytecode files
Changes by Brett Cannon br...@python.org: -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24069 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Objects/enumobject.c::105 for an example. Also, consider providing a way to clean-up that tuple on shutdown. For example, look at what is done with the various freelists. An easier way is to make the premade tuple part of the property object struct so that it gets freed when the property is deallocated. Adding Serhiy to the nosy list, he can help with cleaning-up the patch so that it is ready to apply. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 writing that out? Because it's complex (and costly). This is not a trivial test and I don't see reasons to fix that is not broken. And it will be difficult to explain for readers: remember, I need this exceptional case only in the world with a strange Python's convention (Python try to sort a list when it doesn't make sense). Mathematical algorithm is not broken - programming language is. Here is C: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/msort.c;#l45 Here is Ruby: https://github.com/ruby/ruby/blob/trunk/array.c#L2454 I don't understand the analogy, since neither of these two have key functions. It's practical if you have a broken key function and test it with a one element list. It's silly to test key function on a single-element list *only*. BTW, why this issue was closed? 3 of us agreed this doesn't seem like a suitable change. And 1 seems to be ok with patch. Is this just a question of number of votes? I should also clarify that Raymond and Mark and responsible for maintaining most of the algorithmic/data structure code in Python. At least, please consider this as a documentation issue. That ... feature may be obvious for a Python developer, but not for mathematician (as well as ordinary Python user). This is probably impossible to prove either way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298835] Add a vendor-packages directory for system-supplied modules
Changes by John Beck john.b...@oracle.com: -- nosy: +jbeck ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1298835 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 look appealing. This might be a flawed benchmark but people will make them anyway. In this particular case, there's internal usage at Twitter that unearthed it. The example is just a simplified repro. Some perf degradations were expected, like switching text to Unicode. In this case, the end result computed by both 2.7 and 3.4 is the same so we should be able to address this. [1] http://lwn.net/Articles/640224/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. It's a common computer science technique, possibly not as familiar to a mathematician, but regardless, the docs clearly state that the key is calculated for each item. Your existing code, with a check for Omega having length 1 and omitting the sort in that case, looks entirely reasonable to me. Maybe you could add a comment Avoid a costly calculation of the key when length is 1, as we know we don't need to sort then and leave it at that. -- nosy: +paul.moore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 dealloc the tuple. For example: class C(object): ... @property ... def f(self): ... return D().f ... class D(object): ... @property ... def f(self): ... return 1 ... C().f 1 This works with recursive properties. I also think that is is getting cleaned up on shutdown, if I put a pointer to garbage in the tuple, the interpreter blows up on shutdown; this makes me think that tuple_dealloc is being called somewhere. About putting the tuple on the property instance, that would nice for memory management; however, that increases the memory overhead of each property. This also means that we would only get the faster lookup after the property has been accessed once; this is fine but the current implementation makes it so that all properties are faster after any of them are looked up once. I could be wrong about the cleanup though. I am also updating the title and headers because this issue is no longer about namedtuple. -- components: +Interpreter Core -Extension Modules title: C implementation of namedtuple (WIP) - property_descr_get reuse argument tuple ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org 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)
But that's a sort without a key. In Perl you do a key sort via:
@sorted = map { $_-[0] }
sort { $a-[1] = $b-[1] } # use numeric comparison
map { [$_, length($_)] }# calculate the length of the string
@unsorted;
(From http://en.wikipedia.org/wiki/Schwartzian_transform). That
computes the keys first, and would compute the key for a list of
length 1, just like Python does. It's just that Python bundles that
whole construct into the key= argument.
But it's your choice - if this is a big enough deal to put you off
Python, I guess no-one will be able to stop you. The fact of the
matter is that what Python does is documented behaviour, and the
benefit (small) isn't worth the cost of making a change (which would
only be in Python 3.5 and later anyway, as it's a backward
incompatible change, not a bug fix).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24075
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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**9, 3)) + sum(range(5, 10**9, 5)) - sum(range(15, 10**9, 15))) 216668 real1m11.658s user1m10.980s sys 0m0.572s $ python2.7 -m timeit -n1 -r1 sum(xrange(3, 10**9, 3)) + sum(xrange(5, 10**9, 5)) - sum(xrange(15, 10**9, 15)) 1 loops, best of 1: 72 sec per loop $ python3.4 -m timeit -n1 -r1 sum(range(3, 10**9, 3)) + sum(range(5, 10**9, 5)) - sum(range(15, 10**9, 15)) 1 loops, best of 1: 72.5 sec per loop $ python2.7 -m timeit -s a = list(range(10**6)) -- sum(a) 10 loops, best of 3: 114 msec per loop $ python3.4 -m timeit -s a = list(range(10**6)) -- sum(a) 10 loops, best of 3: 83.5 msec per loop What is sys.int_info on your build? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 fix that is not broken. And it will be difficult to explain for readers: remember, I need this exceptional case only in the world with a strange Python's convention (Python try to sort a list when it doesn't make sense). Mathematical algorithm is not broken - programming language is. Here is C: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/msort.c;#l45 Here is Ruby: https://github.com/ruby/ruby/blob/trunk/array.c#L2454 It's practical if you have a broken key function and test it with a one element list. It's silly to test key function on a single-element list *only*. BTW, why this issue was closed? 3 of us agreed this doesn't seem like a suitable change. And 1 seems to be ok with patch. Is this just a question of number of votes? At least, please consider this as a documentation issue. That ... feature may be obvious for a Python developer, but not for mathematician (as well as ordinary Python user). When key function value has no sense at all - it's not clear from the documentation, that the key function will be called. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 sense for [1] or []?! No, it isn't. So, it's not clear if this process started at all. This not just mine opinion - most computer languages implement the quick exit in question (see examples above). 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) Your existing code, with a check for Omega having length 1 and omitting the sort in that case, looks entirely reasonable to me. (Well, then I should look for other languages, if Python devs insist in doing useless work...) Maybe you could add a comment Avoid a costly calculation of the key when length is 1, as we know we don't need to sort then I sure, for most people - the idea of sorting list with one element will look crazy. There is no room for any costly calculations. (Common sense, nothing more.) So, such comment will add more questions... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.100s sys 0m0.032s $ time python3.4 -c print(sum(range(3, 10**9, 3)) + sum(range(5, 10**9, 5)) - sum(range(15, 10**9, 15))) 216668 real0m16.413s user0m16.086s sys 0m0.089s I can't tell from initial poking what's the core issue here. Both examples produce equivalent bytecode, the builtin_sum() function is only noticably different in the fact that it uses PyLong_* across the board, including PyLong_AsLongAndOverlow. We'll need to profile this, which I didn't have time for yet. -- components: Interpreter Core messages: 242238 nosy: lukasz.langa, pitrou, rhettinger priority: normal severity: normal stage: needs patch status: open title: sum() several times slower on Python 3 type: performance versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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* environment
variables are ignored, too. Further restrictions may be imposed
to prevent the user from injecting malicious code.
But the code says:
-I : isolate Python from the user's environment (implies -E and -s)
and the code to handle -I does:
case 'I':
Py_IsolatedFlag++;
Py_NoUserSiteDirectory++;
Py_IgnoreEnvironmentFlag++;
break;
where Py_NoUserSiteDirectory is the variable corresponding to the -s flag
rather than the -S flag. But it seems like -I should really imply both
-s and -S. So I am filing this bug primarily to find out whether or not
it really should be both. If so, great: a patch is attached; details
below. But if not, then the man page should be corrected.
The rest of this is written under the assumption that -I should imply -S
as well as -s.
Background: depending on which packages are installed on different Solaris
systems, test_site passes or not. Certain packages (e.g., dogpile.core,
dogpile.cache, repoze.lru) that have a .pth file with import types
which results in test_site.StartupImportTests failing because types has
been imported which is in the list of collections modules, none of which
are expected to be imported. So we thought well, -S should fix that
then noticed the man page saying -I implied -S which is how we got here.
Tweaking the code and man page so -I does imply -S was trivial. But three
other changes were needed:
1. In test_site.py, test_startup_imports() asserted that 'site' was in the
list of modules that had been imported. This is no longer true, so I
deleted the assert.
2. test_inspect failed because of a name error, that turned out to be
inspect.py calling exit instead of sys.exit. So the attached patch
corrects both of those. This fix is probably generally applicable
even if the -I should imply both -S and -s assumption turns out to
be false.
3. test_venv failed because it and the venv module were using -I to imply
-s and -E but not -S. Changing three instances of -Im to -Esm
(one in Lib/venv/__init__.py, the other two in Lib/test/test_venv.py)
fixed this. However, even if the -I should imply both -S and -s
assumption is true, this change may not be desirable in the general
case, but needed because of Solaris' hacky work-around for issue
1298835 not yet being fixed.'
I.e., we ship /usr/lib/python3.4/site-packages/vendor-packages.pth
with the one line:
import site; site.addsitedir('/usr/lib/python3.4/vendor-packages')
(likewise for other versions).
So this may not be desirable in general, but I mention it for the
sake of completeness.
--
components: Interpreter Core
files: 25-site-module.patch
keywords: patch
messages: 242248
nosy: dhduvall, jbeck
priority: normal
severity: normal
status: open
title: man page says -I implies -S. code says -s. Should it be both?
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39233/25-site-module.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24077
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24077] man page says -I implies -S. code says -s. Should it be both?
Changes by Ned Deily n...@acm.org: -- assignee: - docs@python components: +Documentation -Interpreter Core nosy: +docs@python stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 https://hg.python.org/cpython/rev/493b3310d5d0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Changes by Sergey B Kirpichev skirpic...@gmail.com: Added file: http://bugs.python.org/file39232/0001-list.sort-Add-quick-exit-if-length-of-list-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue15809 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 made a typo in dd0d751cc7f1 and used upper case instead of lower case for python.man. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 here a quick exit as well. The fact of the matter is that what Python does is documented behaviour No. Unless you absolutely sure - all readers think that sorting process starts even for trivial lists. No reasons to believe in that nonsense - as you could see from sorting implementations in other languages. benefit (small) isn't worth the cost of making a change (which would only be in Python 3.5 and later anyway It's easy for users (i.e. me) to backport this feature (i.e. make wrapper for sorted()). Benefit is small, I admit, but why not remove unnecessary restrictions from the language? I hope, I did my best to explain why. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24077] man page says -I implies -S. code says -s.
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 class definition:
# use the one with the least indentation, which is the one
# that's most probably not inside a function definition.
candidates = []
for i in range(len(lines)):
match = pat.match(lines[i])
if match:
# if it's at toplevel, it's already the best one
if lines[i][0] == 'c':
return lines, i
# else add whitespace to candidate list
candidates.append((match.group(1), i))
if candidates:
# this will sort by whitespace, and by line number,
# less whitespace first
candidates.sort()
return lines, candidates[0][1]
else:
raise OSError('could not find class definition')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24078
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 class A(object): class B(object): pass class C(object): class B(object): pass -- import inspect import a inspect.getsourcelines(a.C.B) (['class B(object):\n', 'pass\n'], 2) -- components: Library (Lib) messages: 242254 nosy: siyuan priority: normal severity: normal status: open title: inspect.getsourcelines ignores context and returns wrong line # type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24078 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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('ab/TEXT/a')
print(root3.text)
CURRENT OUTPUT
None
TEXT is between the elements tags but does not appear in the output
BTW : this is well formed xml and has nothing to do with tail.
--
components: XML
messages: 242256
nosy: jlaurens
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element.text does not conform to the documentation
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24079
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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), key(b))) and then wrap this with cmp_to_key. But that looks silly. Simple test case: $ cat a.py a = [1] def spam(x): raise Exception a.sort(key=spam) print(a) $ python a.py Traceback (most recent call last): File a.py, line 6, in module a.sort(key=spam) File a.py, line 4, in spam raise Exception Exception -- components: Interpreter Core files: trivial-sorting-py3.patch keywords: patch messages: 24 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: list.sort() should do quick exit if len(list) = 1 type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39231/trivial-sorting-py3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19625 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue19625 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Changes by Serhiy Storchaka storch...@gmail.com: -- 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 rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Stéphane Wirtel added the comment: Yep, add a regression test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19625 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? Perhaps this example will help:
root4 = ET.fromstring('aATEXTbBTEXT/bBTAIL/a')
root4
Element 'a' at 0x10224c228
root4.text
'ATEXT'
root4.tail
root4[0]
Element 'b' at 0x1022ab278
root4[0].text
'BTEXT'
root4[0].tail
'BTAIL'
As in your original example, any text following the element b is associated
with b's tail attribute until a new tag is found, pushing or popping the tree
stack. While the description of the text attribute does not explicitly state
this, the tail attribute description immediately following it does. This is
also explained in more detail in the ElementTree resources on effbot.org that
are linked to from the Python Standard Library documentation. Nevertheless, it
probably would be helpful to expand the documentation on this point if someone
is willing to put together a documentation patch for review.
With regard to your comment about well formed xml, I don't think there is
anything in the documentation that implies (or should imply) that the
distinction between the text attribute and the tail attribute has anything
to do with whether it is well-formed XML. The tutorial for the third-party
lxml package, which provides another implementation of ElementTree, goes into
more detail about why, in general, both text and tail are necessary.
https://docs.python.org/3/library/xml.etree.elementtree.html#additional-resources
http://effbot.org/zone/element.htm#text-content
http://lxml.de/tutorial.html#elements-contain-text
--
assignee: - docs@python
components: +Documentation -XML
nosy: +docs@python, ned.deily
stage: - needs patch
versions: +Python 2.7, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24079
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 life. Here is the code: https://github.com/skirpichev/omg/blob/gruntz-use-subs/sympy/series/gruntz.py#L337 Algorithm is recursive and computation of MRV set will be finished only if I add an exceptional case for len(Omega). Or even more ugly solution with cmp-style function: https://github.com/skirpichev/omg/blob/efc70377639f78fc0f246629989056cb80a71923/sympy/series/gruntz.py#L339 So, basically you need a base case for recursion? What's wrong with explicitly writing that out? Considering calling the key function is observable behavior, I don't think this should be changed. The patch makes behavior list.sort() inconsistent. Yes, in some sense. On another hand, it's reasonable to believe that key function will be called iff we need one. But if there is nothing to sort at all - why do sorting, why you want to call key function? Looks irrational to me. Last by not least. Why the return value of the key function *must* be defined in this case? Just a hidden, undocumented restriction and has no practical value. It's practical if you have a broken key function and test it with a one element list. BTW, why this issue was closed? 3 of us agreed this doesn't seem like a suitable change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 spent creating and deallocating throw-away PyLong objects. My guess is that it simply lacks a free-list in _PyLong_New(). -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mathematician prefers the simple invariant that the key function is called exactly once per list item. If your key function doesn't work for one of those items for some reason, that sounds like a problem with the key function rather than a reason to change the sorting implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 in the integer arithmetic, but not enough to explain the whole of the timing mismatch. One thing we've lost in Python 3 is the fast path for small-int addition *inside* the ceval loop. It may be possible to restore something there. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 towards it .Thanks for commenting . Could you guys suggest some issues i could work on as a beginner :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24005 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24050] [2.7] crash in third party module mopidy
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: not a bug - third party stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24050 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 timeit -s 'x = range(3, 10**9, 3)' 'for e in x: pass' 10 loops, best of 3: 8.62 sec per loop -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24076 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24075] list.sort() should do quick exit if len(list) = 1
Changes by Benjamin Peterson benja...@python.org: -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Algorithm is recursive and computation of MRV set will be finished only if I add an exceptional case for len(Omega). Or even more ugly solution with cmp-style function: https://github.com/skirpichev/omg/blob/efc70377639f78fc0f246629989056cb80a71923/sympy/series/gruntz.py#L339 Considering calling the key function is observable behavior, I don't think this should be changed. The patch makes behavior list.sort() inconsistent. Yes, in some sense. On another hand, it's reasonable to believe that key function will be called iff we need one. But if there is nothing to sort at all - why do sorting, why you want to call key function? Looks irrational to me. Last by not least. Why the return value of the key function *must* be defined in this case? Just a hidden, undocumented restriction and has no practical value. BTW, why this issue was closed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24075 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
