[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

[Nick Coghlan]

Nick Coghlan  added the comment:

Somewhat inevitably, the detailed disassembler tests broke when Antoine updated 
the code generation for function definitions (as part of PEP 3155). (At least, 
the tests broke, and PEP 3155 seems the most likely culprit).

I subsequently realised there's a potential opportunity here: if Instruction 
objects define an __eq__ method instead of relying on the custom 
"assertBytecodeExactlyMatches" helper method the new disassembly tests 
currently use, then the sequence diffing functionality in unittest could be 
very helpful in identifying and fixing discrepancies between actual output and 
expected output.

However, the assertBytecodeExactlyMatches() API has this concept of a 
"line_offset" which it uses to cope with some of the introspection fodder 
moving around in the files, so the question then becomes how to deal with that 
in the context of an __eq__ implementation.

Accordingly, my current plan is to offer "line_offset" as a keyword-only 
argument to get_instructions() itself. That way, the entire sequence of 
generated bytecode can easily be adjusted to (for example), be based around the 
first line being line 1, even if the actual code object being disassembled is 
located elsewhere in the original source file.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13481] Use an accurate clock in timeit

[Georg Brandl]

Georg Brandl  added the comment:

So does the accuracy outweigh using a Python function to call the actual clock 
function? (and usuable -> usable)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12618] py_compile cannot create files in current directory

[Roundup Robot]

Roundup Robot  added the comment:

New changeset bcc7bf3963cc by Meador Inge in branch '2.7':
Issue #12618: create unit tests for the py_compile module
http://hg.python.org/cpython/rev/bcc7bf3963cc

New changeset 2be3a2e63683 by Meador Inge in branch '3.2':
Issue #12618: create unit tests for the py_compile module
http://hg.python.org/cpython/rev/2be3a2e63683

New changeset f8f58db0715e by Meador Inge in branch 'default':
Issue #12618: create unit tests for the py_compile module
http://hg.python.org/cpython/rev/f8f58db0715e

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow  added the comment:

Yeah, the more I think about it, the more I agree it's Python 4 fodder.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Nick Coghlan]

Nick Coghlan  added the comment:

Yeah, sorry Eric (Snow), you're trying to bite off *way* more than is 
reasonable by proposing to removing sys.path[0] auto-initialisation. While it 
has its problems, it's also far too entrenched in people's expections of 
Python's behaviour to consider removing at this late date. The earliest such a 
radical change could likely be considered is Python 4.

Éric (Araujo): the "just do the right thing" aspect is covered by PEP 395. This 
is an orthogonal proposal that allows power users the ability to override the 
automatic initialisation to handle those cases where it goes wrong.

That said, I may still make this suggestion part of PEP 395 rather than a 
distinct proposal, even though there's no direct dependency (in either 
direction) between this suggestion and the other ideas in that PEP.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13380] ctypes: add an internal function for reseting the ctypes caches

[Meador Inge]

Meador Inge  added the comment:

Committed.  Thanks for the review Antoine.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13380] ctypes: add an internal function for reseting the ctypes caches

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 6783aa5c15ae by Meador Inge in branch '2.7':
Issue #13380: add an internal function for resetting the ctypes caches
http://hg.python.org/cpython/rev/6783aa5c15ae

New changeset fa59b3758b14 by Meador Inge in branch '3.2':
Issue #13380: add an internal function for resetting the ctypes caches
http://hg.python.org/cpython/rev/fa59b3758b14

New changeset 963d861d0eb5 by Meador Inge in branch 'default':
Issue #13380: add an internal function for resetting the ctypes caches
http://hg.python.org/cpython/rev/963d861d0eb5

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

[Matt Joiner]

Changes by Matt Joiner :


--
nosy: +anacrolix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13448] PEP 3155 implementation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> There are some callables which are missing __qualname__:
> 
>   method_descriptor
>   wrapper_descriptor
>   builtin_function_or_method
> 
> For the descriptors, at least, obj.__qualname__ should be equivalent to
> 
>   obj.__objclass__.__qualname__ + '.' + obj.__name__
> 
> Were these overlooked?

Indeed, they were overlooked. Due to the way they are instantiated,
though, it would be quite a bit harder to devise a __qualname__ for
them.

> Also I notice that bound methods have a misleading __qualname__:
> 
>   >>> class A:
>   ...   def f(self): pass
>   ...
>   [66348 refs]
>   >>> A().f.__qualname__
>   'A.f'
> 
> Maybe this should be 'A().f' instead.

I am a bit surprised that this works at all. Apparently attribute
lookups are redirected to the underlying function.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13443] wrong links and examples in the functional HOWTO

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11849] glibc allocator doesn't release all free()ed memory

[Roundup Robot]

Roundup Robot  added the comment:

New changeset e7aa72e6aad4 by Antoine Pitrou in branch 'default':
Better resolution for issue #11849: Ensure that free()d memory arenas are 
really released
http://hg.python.org/cpython/rev/e7aa72e6aad4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13440] Explain the "status quo wins a stalemate" principle in the devguide

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Or expand 'Reporting Bugs' to 'Reporting Bugs and Requesting Features', perhaps 
renamed to 'Suggesting Improvements'. My point is that aspiring developers are 
not the only one that need to read the guideline, not withstanding the fact the 
some new developers or would-be developers are also enthusiastic in making 
proposals.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13448] PEP 3155 implementation

[sbt]

sbt  added the comment:

For builtin_function_or_method it seems obj.__qualname__ should be

  obj.__self__.__qualname__ + '.' + obj.__name__

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13437] Provide links to the source code for every module in the documentation

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13436] compile() doesn't work on ImportFrom with level=None

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Does this apply to 2.7 as well?

I believe msg148146 is due to a commit message typo.

--
nosy: +haypo, terry.reedy
versions: +Python 3.2, Python 3.3 -Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13433] String format documentation contains error regarding %g

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I find the doc for g/G less than clear.

1. (main entry) "Uses lowercase exponential format if exponent is less than -4 
or not less than precision, decimal format otherwise."

'not less' means 'equal or greater', which to me is clearer. Even better and 
clearer to me would be "Uses decimal format if -4 <= exponent < precision, 
exponential format otherwise."


2. (note 4) "The precision determines the number of significant digits before 
and after the decimal point and defaults to 6."

>>> format(.001, 'g')
'0.001'

I only count 4, not 6.

Whoops, that is sort of documented, but in a really backwards way, by saying 
what the alternate form is. "The alternate form ... trailing zeroes are not 
removed as they would otherwise be."

>>> format(.001, '.3g')
'0.001'

Now I count 4, not 3.

3. (several notes) 'The alternate form'? I initially though this meant one of 
the two forms for g/G but then saw it used for other formats with just one 
form. It took too much searching to find the entry for '#', which I had never 
noticed before. Please expand to "The alternate '#' form" or add "(Alternate 
forms are selected by the '#' flag.)" after "Notes:".

I agree with C.I. that we could give some subtle emphasis that g/G treat 
precision differently. But the difference is more than just including the 
minimum 1 char before the decimal point in the precision.

>>> format(.001, 'f')
'0.001000'

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13481] Use an accurate clock in timeit

[Antoine Pitrou]

New submission from Antoine Pitrou :

This patch uses an accurate POSIX clock if possible in the timeit module.

--
components: Library (Lib)
files: timeit_clock.patch
keywords: patch
messages: 148369
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Use an accurate clock in timeit
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23783/timeit_clock.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13448] PEP 3155 implementation

[sbt]

sbt  added the comment:

There are some callables which are missing __qualname__:

  method_descriptor
  wrapper_descriptor
  builtin_function_or_method

For the descriptors, at least, obj.__qualname__ should be equivalent to

  obj.__objclass__.__qualname__ + '.' + obj.__name__

Were these overlooked?

  PS C:\Repos\cpython> .\PCbuild\python_d
  Python 3.3.0a0 (default, Nov 25 2011, 22:14:28) [MSC v.1500 32 bit (Intel)] 
on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import pickle
  [66213 refs]
  >>> attribs = ('__class__', '__name__', '__qualname__')
  [66220 refs]
  >>> for o in (pickle.Pickler, pickle.Pickler.dump, object.__init__, min):
  ...   print([getattr(o, a, None) for a in attribs])
  ...
  [, 'Pickler', 'Pickler']
  [, 'dump', None]
  [, '__init__', None]
  [, 'min', None]
  [66265 refs]

Also I notice that bound methods have a misleading __qualname__:

  >>> class A:
  ...   def f(self): pass
  ...
  [66348 refs]
  >>> A().f.__qualname__
  'A.f'

Maybe this should be 'A().f' instead.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2286] Stack overflow exception caused by test_marshal on Windows x64

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The 'official' PSF build for 2.7 (and 3.x) is done with VS2008, so this may not 
be the last problem you have. I am pretty sure this will never change for 2.7, 
but that is not to say we cannot make a simple change to accommodate VS2010. I 
am sure we will eventually update VS for 3.x. Can you test 3.2 or even better 
3.3?

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11849] glibc allocator doesn't release all free()ed memory

[Charles-François Natali]

Charles-François Natali  added the comment:

> Hmm, quite slow indeed, are you sure you're not running in debug mode?
>

Well, yes, but it's no faster with a non-debug build: my laptop is
really crawling :-)

> If the performance regression is limited to read(), I don't think it's
> really an issue, but using mmap/munmap explicitly would probably benicer
> anyway (1° because it lets the glibc choose whatever heuristic is best,
> 2° because it would help release memory on more systems than just glibc
> systems). I think limiting ourselves to systems which have
> MMAP_ANONYMOUS is good enough.
>

Agreed.
Here's a patch.

--
Added file: http://bugs.python.org/file23782/arenas_mmap.diff

___
Python tracker 

___diff --git a/Objects/obmalloc.c b/Objects/obmalloc.c
--- a/Objects/obmalloc.c
+++ b/Objects/obmalloc.c
@@ -2,8 +2,11 @@
 
 #ifdef WITH_PYMALLOC
 
-#ifdef HAVE_MALLOPT_MMAP_THRESHOLD
-  #include 
+#ifdef HAVE_MMAP
+ #include 
+ #ifdef MAP_ANONYMOUS
+  #define ARENAS_USE_MMAP
+ #endif
 #endif
 
 #ifdef WITH_VALGRIND
@@ -183,15 +186,15 @@
 /*
  * The allocator sub-allocates  blocks of memory (called arenas) aligned
  * on a page boundary. This is a reserved virtual address space for the
- * current process (obtained through a malloc call). In no way this means
- * that the memory arenas will be used entirely. A malloc() is usually
- * an address range reservation for  bytes, unless all pages within this
- * space are referenced subsequently. So malloc'ing big blocks and not using
- * them does not mean "wasting memory". It's an addressable range wastage...
+ * current process (obtained through a malloc()/mmap() call). In no way this
+ * means that the memory arenas will be used entirely. A malloc() is
+ * usually an address range reservation for  bytes, unless all pages 
within
+ * this space are referenced subsequently. So malloc'ing big blocks and not
+ * using them does not mean "wasting memory". It's an addressable range
+ * wastage...
  *
- * Therefore, allocating arenas with malloc is not optimal, because there is
- * some address space wastage, but this is the most portable way to request
- * memory from the system across various platforms.
+ * Arenas are allocated with mmap() on systems supporting anonymous memory
+ * mappings to reduce heap fragmentation.
  */
 #define ARENA_SIZE  (256 << 10) /* 256KB */
 
@@ -557,11 +560,6 @@
 if (numarenas > PY_SIZE_MAX / sizeof(*arenas))
 return NULL;/* overflow */
 #endif
-#ifdef HAVE_MALLOPT_MMAP_THRESHOLD
-/* Ensure arenas are allocated by mmap to avoid heap fragmentation. */
-if (numarenas == INITIAL_ARENA_OBJECTS)
-mallopt(M_MMAP_THRESHOLD, ARENA_SIZE);
-#endif
 nbytes = numarenas * sizeof(*arenas);
 arenaobj = (struct arena_object *)realloc(arenas, nbytes);
 if (arenaobj == NULL)
@@ -594,7 +592,12 @@
 arenaobj = unused_arena_objects;
 unused_arena_objects = arenaobj->nextarena;
 assert(arenaobj->address == 0);
+#ifdef ARENAS_USE_MMAP
+arenaobj->address = (uptr)mmap(NULL, ARENA_SIZE, PROT_READ|PROT_WRITE,
+   MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
+#else
 arenaobj->address = (uptr)malloc(ARENA_SIZE);
+#endif
 if (arenaobj->address == 0) {
 /* The allocation failed: return NULL after putting the
  * arenaobj back.
@@ -1071,7 +1074,11 @@
 unused_arena_objects = ao;
 
 /* Free the entire arena. */
+#ifdef ARENAS_USE_MMAP
+munmap((void *)ao->address, ARENA_SIZE);
+#else
 free((void *)ao->address);
+#endif
 ao->address = 0;/* mark unassociated */
 --narenas_currently_allocated;
 
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -2567,8 +2567,8 @@
  getgrouplist getgroups getlogin getloadavg getpeername getpgid getpid \
  getpriority getresuid getresgid getpwent getspnam getspent getsid getwd \
  if_nameindex \
- initgroups kill killpg lchmod lchown lockf linkat lstat lutimes memrchr \
- mbrtowc mkdirat mkfifo \
+ initgroups kill killpg lchmod lchown lockf linkat lstat lutimes mmap \
+ memrchr mbrtowc mkdirat mkfifo \
  mkfifoat mknod mknodat mktime mremap nice openat pathconf pause pipe2 plock 
poll \
  posix_fallocate posix_fadvise pread \
  pthread_init pthread_kill putenv pwrite readlink readlinkat readv realpath 
renameat \
@@ -2679,15 +2679,6 @@
   [AC_MSG_RESULT(no)
 ])
 
-AC_MSG_CHECKING(whether mallopt can set malloc mmap threshold)
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
-#include 
-]], [[mallopt(M_MMAP_THRESHOLD, 256 * 1024)]])],
-  [AC_DEFINE(HAVE_MALLOPT_MMAP_THRESHOLD, 1, Define if mallopt can set malloc 
mmap threshold.)
-   AC_MSG_RESULT(yes)],
-  [AC_MSG_RESULT(no)
-])
-
 AC_MSG_CHECKING(for broken unsetenv)
 AC_C

[issue12567] curses implementation of Unicode is wrong in Python 3

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This broke several Gentoo buildbots.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11849] glibc allocator doesn't release all free()ed memory

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> On my box:
> default:
> $ ./python -m timeit -s "n=30; f=open('/tmp/10MB.bin', 'rb');
> b=bytearray(n)" "f.seek(0);f.readinto(b)"
> 1000 loops, best of 3: 640 usec per loop
> 
> default without patch ("$ hg revert -r 68258 Objects/obmalloc.c && make"):
> $ ./python -m timeit -s "n=30; f=open('/tmp/10MB.bin', 'rb');
> b=bytearray(n)" "f.seek(0);f.readinto(b)"
> 1000 loops, best of 3: 663 usec per loop
> 
> I'm just observing a random variance (but my computer is maybe too
> slow to notice).

Hmm, quite slow indeed, are you sure you're not running in debug mode?

> However, I really don't see how the patch could play a role here.
> 
> Concerning the slight performance regression, if it's a problem, I see
> two options:
> - revert the patch
> - replace calls to malloc()/free() by mmap()/munmap() to allocate/free
> arenas (but I'm not sure anonymous mappings are supported by every OS
> out there, so this might lead to some ugly #ifdef's...)

If the performance regression is limited to read(), I don't think it's
really an issue, but using mmap/munmap explicitly would probably benicer
anyway (1° because it lets the glibc choose whatever heuristic is best,
2° because it would help release memory on more systems than just glibc
systems). I think limiting ourselves to systems which have
MMAP_ANONYMOUS is good enough.

Here is what the glibc malloc does btw:

/*
   Nearly all versions of mmap support MAP_ANONYMOUS,
   so the following is unlikely to be needed, but is
   supplied just in case.
*/

#ifndef MAP_ANONYMOUS

static int dev_zero_fd = -1; /* Cached file descriptor for /dev/zero. */

#define MMAP(addr, size, prot, flags) ((dev_zero_fd < 0) ? \
 (dev_zero_fd = open("/dev/zero", O_RDWR), \
  mmap((addr), (size), (prot), (flags), dev_zero_fd, 0)) : \
   mmap((addr), (size), (prot), (flags), dev_zero_fd, 0))

#else

#define MMAP(addr, size, prot, flags) \
 (mmap((addr), (size), (prot), (flags)|MAP_ANONYMOUS, -1, 0))

#endif

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11849] glibc allocator doesn't release all free()ed memory

[Charles-François Natali]

Charles-François Natali  added the comment:

> However, there's still another strange regression:
>
> $ ./python -m timeit \
>   -s "n=30; f=open('10MB.bin', 'rb', buffering=0); b=bytearray(n)" \
>   "f.seek(0);f.readinto(b)"
>
> -> default branch:
> 1 loops, best of 3: 43 usec per loop
> -> default branch with patch reverted:
> 1 loops, best of 3: 27.5 usec per loop
>
> FileIO.readinto executes a single read() into the passed buffer.

On my box:
default:
$ ./python -m timeit -s "n=30; f=open('/tmp/10MB.bin', 'rb');
b=bytearray(n)" "f.seek(0);f.readinto(b)"
1000 loops, best of 3: 640 usec per loop

default without patch ("$ hg revert -r 68258 Objects/obmalloc.c && make"):
$ ./python -m timeit -s "n=30; f=open('/tmp/10MB.bin', 'rb');
b=bytearray(n)" "f.seek(0);f.readinto(b)"
1000 loops, best of 3: 663 usec per loop

I'm just observing a random variance (but my computer is maybe too
slow to notice).
However, I really don't see how the patch could play a role here.

Concerning the slight performance regression, if it's a problem, I see
two options:
- revert the patch
- replace calls to malloc()/free() by mmap()/munmap() to allocate/free
arenas (but I'm not sure anonymous mappings are supported by every OS
out there, so this might lead to some ugly #ifdef's...)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13432] Encoding alias "unicode"

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Reverse question: what would be the minus of having this alias?

Please accept that this issue is closed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12567] curses implementation of Unicode is wrong in Python 3

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c3581ca21a57 by Victor Stinner in branch 'default':
Issue #12567: The curses module uses Unicode functions for Unicode arguments
http://hg.python.org/cpython/rev/c3581ca21a57

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1521950] shlex.split() does not tokenize like the shell

[Dan Christian]

Dan Christian  added the comment:

I just realized that I left out a major case.  The shell will also
split ().  I think this is now complete.  If you do "man bash" and
skip down to DEFINITONS it lists all the control characters.

I've attached updated versions of ref_shlex.py and test_shlex.diff.
They replace the previous ones.

-Dan

On Fri, Nov 25, 2011 at 12:25 PM, Dan Christian  wrote:
>
> Dan Christian  added the comment:
>
> I've attached a diff to test_shlex.py and a script that I used to
> verify what the shells actually do.
> Both are relative to Python-3.2.2/Lib/test
>
> I'm completely ignoring the quotes issue for now.  That should
> probably be an enhancement.  I don't think it really matters until the
> parsing issues are resolved.
>
> ref_shlex is python 2 syntax.  python -3 shows that it should convert cleanly.
> ./ref_shlex.py
> It will run by default against /bin/*sh
> If you don't want that, do something like: export SHELLS='/bin/sh,/bin/csh'
> It runs as a unittest.  So you will only see dots if all shells do
> what it expects.  Some shells are flaky (e.g. zsh, tcsh), so you may
> need to run it multiple times.
>
> Getting this into the mainline will be interesting.  I would think it
> would take some community discussion.  I may be able to convince
> people that the current behaviour is wrong, but I can't tell you what
> will break if it is "fixed".  And should the fix be the default?  As
> you mentioned, it depends on what people expect it to do and how it is
> currently being used.  I see the first step as presenting a clear case
> of how it should work.
>
> -Dan

--
Added file: http://bugs.python.org/file23780/ref_shlex.py
Added file: http://bugs.python.org/file23781/test_shlex.diff

___
Python tracker 

___#!/usr/bin/env python

"""Test how various shells parse syntax.
This is only expected to work on Unix based systems.
We use the unittest infrastructure, but this isn't a normal test.

Usage:
  ref_shelex.py [options] shells...
"""
# Written by: Dan Christian for issue1521950
# References: man bash   # look at DEFINITIONS and SHELL GRAMMAR

import glob
import re
import os, sys
import subprocess
import unittest


TempDir = '/tmp' # where we will write temp files
Shells = ['/bin/sh', '/bin/bash'] # list of shells to test against

class ShellTest(unittest.TestCase):
bgRe = re.compile(r'\[\d+\]\s+(\d+|\+ Done)$') # backgrounded command output

def Run(self,
shell,   # shell to use
command, # command to run
filepath=None):  # any files that are expected
"""Carefully run a shell command.
Capture stdout, stderr, and exit status.
Returns: (ret, out, err)
   ret is the return status
   out is the list of lines to stdout
   err is the list of lines to stderr
"""
start_cwd = os.getcwd()
call = [shell, '-c', command]
#print "Running: %s -c '%s'" % (shell, command)
outpath = 'stdout.txt'
errpath = 'stderr.txt'
ret = -1
out = None
err = None
fileout = None
try:
os.chdir(TempDir)
outfp = open(outpath, 'w')
errfp = open(errpath, 'w')
if filepath and os.path.isfile(filepath):
os.remove(filepath)
ret = subprocess.call(call, stdout=outfp, stderr = errfp)
#print "Returned: %d" % ret
outfp = open(outpath, 'r')
out = outfp.readlines()
os.remove(outpath)
errfp = open(errpath, 'r')
err = errfp.readlines()
os.remove(errpath)
if filepath:
ffp = open(filepath)
fileout = ffp.readlines()
os.remove(filepath)
except OSError as msg:
print "Exception!", msg
os.chdir(start_cwd)
# leave files behind for debugging
self.assertTrue(0, "Hit an exception running: " % (
' '.join(call)))
return (ret, out, err, fileout)

def testTrue(self):
""" Trivial case to test execution. """
for shell in Shells:
cmd = '/bin/true'
(ret, out, err, fout) = self.Run(shell, cmd)
self.assertEquals(
0, ret,
"Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret))
self.assertEquals(
[], out,
"Expected %s -c '%s' send nothing to stdout, not: %s" % (
shell, cmd, out))
self.assertEquals(
[], err,
"Expected %s -c '%s' send nothing to stderr, not: %s" % (
shell, cmd, err))

def testEcho(self):
""" Simple case to test stdout. """
for shell in Shells:
cmd = 'echo "hello world"'

[issue12856] tempfile PRNG reuse between parent and child process

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch committed, thank you!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12856] tempfile PRNG reuse between parent and child process

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 3c9ddd93c983 by Antoine Pitrou in branch '3.2':
Issue #12856: Ensure child processes do not inherit the parent's random seed 
for filename generation in the tempfile module.
http://hg.python.org/cpython/rev/3c9ddd93c983

New changeset 588087429809 by Antoine Pitrou in branch 'default':
Issue #12856: Ensure child processes do not inherit the parent's random seed 
for filename generation in the tempfile module.
http://hg.python.org/cpython/rev/588087429809

New changeset e42be90eb9c5 by Antoine Pitrou in branch '2.7':
Issue #12856: Ensure child processes do not inherit the parent's random seed 
for filename generation in the tempfile module.
http://hg.python.org/cpython/rev/e42be90eb9c5

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13402] Document absoluteness of sys.executable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > You could also add a test to test_sys ensuring that sys.executable
> > is always executable.
> 
> And that sys.executable is absolute?

Er, yes, that's what I meant. Sorry.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13402] Document absoluteness of sys.executable

[STINNER Victor]

STINNER Victor  added the comment:

> You could also add a test to test_sys ensuring that sys.executable
> is always executable.

And that sys.executable is absolute?

sys.executable is an empty string if sys.argv[0] has been changed and Python is 
unable to retrieve the real path to the Python executable. See the issue #7774. 
The fact that sys.executable can be empty should be documented.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13402] Document absoluteness of sys.executable

[Antoine Pitrou]

Antoine Pitrou  added the comment:

LGTM too.
You could also add a test to test_sys ensuring that sys.executable is always 
executable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13432] Encoding alias "unicode"

[STINNER Victor]

STINNER Victor  added the comment:

> For example, when Microsoft talks about Unicode they mean UTF-16.

Sorry, but UTF-16 is ambiguously: do you mean UTF-16-LE or UTF-16-BE? ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13432] Encoding alias "unicode"

[Georg Brandl]

Georg Brandl  added the comment:

The mapping "unicode" -> "utf-8" is simply not defined unambiguously, in 
addition to being factually wrong. For example, when Microsoft talks about 
Unicode they mean UTF-16.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1521950] shlex.split() does not tokenize like the shell

[Dan Christian]

Dan Christian  added the comment:

I've attached a diff to test_shlex.py and a script that I used to
verify what the shells actually do.
Both are relative to Python-3.2.2/Lib/test

I'm completely ignoring the quotes issue for now.  That should
probably be an enhancement.  I don't think it really matters until the
parsing issues are resolved.

ref_shlex is python 2 syntax.  python -3 shows that it should convert cleanly.
./ref_shlex.py
It will run by default against /bin/*sh
If you don't want that, do something like: export SHELLS='/bin/sh,/bin/csh'
It runs as a unittest.  So you will only see dots if all shells do
what it expects.  Some shells are flaky (e.g. zsh, tcsh), so you may
need to run it multiple times.

Getting this into the mainline will be interesting.  I would think it
would take some community discussion.  I may be able to convince
people that the current behaviour is wrong, but I can't tell you what
will break if it is "fixed".  And should the fix be the default?  As
you mentioned, it depends on what people expect it to do and how it is
currently being used.  I see the first step as presenting a clear case
of how it should work.

-Dan

On Fri, Nov 25, 2011 at 10:01 AM, Éric Araujo  wrote:
>
> Éric Araujo  added the comment:
>
>> Of course, that's how it's used.  That's all it can do right now.
> :) What I meant is that it is *meant* to be used in this way.
>
>> I was was splitting and combining commands (using ;, &&, and ||) and then 
>> running the resulting
>> (mega) one liners over ssh.  It still gets run by a shell, but I was 
>> specifying the control flow.
> Thank you for the reply.  It is indeed a valuable use case to pass a command 
> line as one string to ssh, and the split/quote combo should round-trip and be 
> useful for this usage.
>
>> I'll see if I can come up with a reference case and maybe a unittest this 
>> weekend
> Great!  A new argument (with a default value which gets us the previous 
> behavior) will probably be needed, to preserve backward compatibility.
>
> --
> nosy: +niemeyer
> versions: +Python 3.3 -Python 3.2
>
> ___
> Python tracker 
> 
> ___
>

--
keywords: +patch
Added file: http://bugs.python.org/file23778/ref_shlex.py
Added file: http://bugs.python.org/file23779/test_shlex.diff

___
Python tracker 

___#!/usr/bin/env python

"""Test how various shells parse syntax.
This is only expected to work on Unix based systems.
We use the unittest infrastructure, but this isn't a normal test.

Usage:
  ref_shelex.py [options] shells...
"""
# Written by: Dan Christian for issue1521950

import glob
import re
import os, sys
import optparse
import subprocess
import unittest


TempDir = '/tmp' # where we will write temp files
Shells = ['/bin/sh', '/bin/bash'] # list of shells to test against

class ShellTest(unittest.TestCase):
bgRe = re.compile(r'\[\d+\]\s+(\d+|\+ Done)$') # backgrounded command output

def Run(self,
shell,   # shell to use
command, # command to run
filepath=None):  # any files that are expected
"""Carefully run a shell command.
Capture stdout, stderr, and exit status.
Returns: (ret, out, err)
   ret is the return status
   out is the list of lines to stdout
   err is the list of lines to stderr
"""
start_cwd = os.getcwd()
call = [shell, '-c', command]
#print "Running: %s -c '%s'" % (shell, command)
outpath = 'stdout.txt'
errpath = 'stderr.txt'
ret = -1
out = None
err = None
fileout = None
try:
os.chdir(TempDir)
outfp = open(outpath, 'w')
errfp = open(errpath, 'w')
if filepath and os.path.isfile(filepath):
os.remove(filepath)
ret = subprocess.call(call, stdout=outfp, stderr = errfp)
#print "Returned: %d" % ret
outfp = open(outpath, 'r')
out = outfp.readlines()
os.remove(outpath)
errfp = open(errpath, 'r')
err = errfp.readlines()
os.remove(errpath)
if filepath:
ffp = open(filepath)
fileout = ffp.readlines()
os.remove(filepath)
except OSError as msg:
print "Exception!", msg
os.chdir(start_cwd)
# leave files behind for debugging
self.assertTrue(0, "Hit an exception running: " % (
' '.join(call)))
return (ret, out, err, fileout)

def testTrue(self):
""" Trivial case to test execution. """
for shell in Shells:
cmd = '/bin/true'
(ret, out, err, fout) = self.Run(shell, cmd)

[issue12424] distutils2: extension section uses bad environment marker separator

[Eli Collins]

Eli Collins  added the comment:

The second patchset (9170231ebf14.diff) should implement all the changes you 
suggested in your second review (dated 2011-09-05).

---

The only non-addressed item in your second review was a request for 
clarification on a potential error I noticed (and described somewhat poorly). 
On later examination, I realized I was mistaken, so didn't want to trouble 
anyone further with it. 

(If you want details... I noticed that if a line ends with ";;", _pop_values() 
will call interpret() with an empty string. I initially though that would cause 
an error, but later realized it just means interpret() would return False, 
causing the line to be ignored, which is probably fine for that border case - 
especially since packaging.metadata has the same behavior for lines ending with 
";").

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow  added the comment:

First of all, I don't want Nick's proposal in this issue (the -p and --nopath0 
flags) to be misunderstood because of me.  His is a great idea that will make a 
really useful shortcut available and will _not_ change any current behavior.

My (overly) long message is an attempt to justify going with a more drastic 
variation, to which your response applies exclusively.  I stand by what I said, 
but I would be quite happy with the original proposal, to which your response 
does not apply.  :)

Just wanted to make all that clear so I don't get in the way of a good thing.  
:)

Your comments are spot on.  Your concerns are exactly the ones I would need to 
assuage before my alternative would be acceptable.  When I get a chance I'll 
take this to python-ideas.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13452] PyUnicode_EncodeDecimal: reject error handlers different than strict

[STINNER Victor]

STINNER Victor  added the comment:

Hum, I only changed PyUnicode_EncodeDecimal in Python 3.3, I prefer to not 
touch stable releases (2.7, 3.2).

New changeset a20fae95618c by Victor Stinner in branch 'default':
Close #13093: PyUnicode_EncodeDecimal() doesn't support error handlers
http://hg.python.org/cpython/rev/a20fae95618c

(Oops, I specified the wrong issue number: fixed in 9a712ad593bb)

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13093] Redundant code in PyUnicode_EncodeDecimal()

[STINNER Victor]

Changes by STINNER Victor :


--
Removed message: http://bugs.python.org/msg148348

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13093] Redundant code in PyUnicode_EncodeDecimal()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset a20fae95618c by Victor Stinner in branch 'default':
Close #13093: PyUnicode_EncodeDecimal() doesn't support error handlers
http://hg.python.org/cpython/rev/a20fae95618c

--
stage: patch review -> committed/rejected

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13448] PEP 3155 implementation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Now committed together with docs and a what's new entry. Thanks for the reviews!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13472] devguide doesn’t list all build dependencies

[Ezio Melotti]

Ezio Melotti  added the comment:

> I think about it in the reverse: You want a featurefull library, and 
> disable some things (zlib, ssl, threads) only if you specifically 
> don’t want them (if you’re a Twisted fan for example ).

I have a few arguments in favor of my position:
1) Python and its test suite should always run without errors, even when some 
dependencies are missing (I've found and fixed several issues related to zlib 
because it was missing here);
2) The default Python installed with the OS will use whatever dependencies are 
already provided, so if you add all the missing ones manually, you'll be 
testing in a scenario that is different from the "default" one (you might argue 
that if no one installs all the missing dependencies, we can't know if they all 
work together everywhere (IIRC at some point we had a discussion about having a 
buildbot without the optional dependencies too));
3) Hard work pays off later. Laziness pays off now!

> the addition of this message and further edits to its wording were done
> exactly to avoid people worrying that their python binary is not usable.

But it's still missing an "optional" before modules imho.  The second message 
that says to "look in setup.py in detect_modules()" doesn't seem too useful too 
(but maybe I should take a look ;).  There are a couple of threads on 
Core-Mentorship by people that got confused by these messages (and some include 
discussions about finding the dependencies).

> Okay; do we need to collect info for all major OSes
> (I’m taking the list of stable 3.2 buildbots to determine “major”)?

You can also do it incrementally, adding e.g. "For Debian and derivative 
systems you can use ``aptitude build-dep pythonX.Y``." and then add other items 
to the list as soon as we figure them out (you can also try to figure them out 
in advanced, as long as finding the command for some obscure platform doesn't 
keep on hold the list of commands for other well known platforms).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13448] PEP 3155 implementation

[Roundup Robot]

Roundup Robot  added the comment:

New changeset e1dbc72bd97f by Antoine Pitrou in branch 'default':
PEP 3155 / issue #13448: Qualified name for classes and functions.
http://hg.python.org/cpython/rev/e1dbc72bd97f

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13400] packaging: build command should accept --compile, --no-compile and --optimize options

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

Byte-compilation should be disabled during building of packages in Gentoo. 
PYTHONDONTWRITEBYTECODE="1" is set by default in environment. This variable 
affects distutils and until recently it affected packaging. --no-byte-compile 
will have to be explicitly passed to `pysetup${version} run build` and 
`pysetup${version} run install_dist` to disable byte-compilation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12307] Inconsistent formatting of section titles in PEP 0

[Eric Snow]

Eric Snow  added the comment:

Éric has addressed this in http://hg.python.org/peps/rev/6c7415a4f0f3 (thanks 
Éric).  Do the docs for python.org have to be manually rebuilt or is that on a 
cron?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13400] packaging: build command should accept --compile, --no-compile and --optimize options

[Éric Araujo]

Éric Araujo  added the comment:

Juste a note: currently, when a command sets one option from the value given to 
another command, they have the same name, with two kinds of exceptions:
- build --build-lib becomes build_lib --build-dir (etc.)
- install --install-lib becomes install_lib --install-dir (etc.)

So, introducing --(no-)byte-compile and --optimize-bytecode= would change that 
scheme, but it is not a big deal.

On the third hand, maybe this is an opportunity to change the option names on 
the build_py and install* commands too.  For example, for a long time I thought 
that --optimize implied --compile, but actually they’re distinct options.

BTW, would these new options simplify some scripts you have, or do you just 
request them for consistency?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9957] SpooledTemporayFile.truncate should take size parameter

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5a6911930bad by Antoine Pitrou in branch 'default':
Issue #9957: SpooledTemporaryFile.truncate() now accepts an optional size 
parameter, as other file-like objects.
http://hg.python.org/cpython/rev/5a6911930bad

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9957] SpooledTemporayFile.truncate should take size parameter

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed, thank you. By the way, Ryan, we now use Mercurial for developing, 
the Subversion repository is obsolete (see the devguide for more info).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1521950] shlex.split() does not tokenize like the shell

[Éric Araujo]

Éric Araujo  added the comment:

> Of course, that's how it's used.  That's all it can do right now.
:) What I meant is that it is *meant* to be used in this way.

> I was was splitting and combining commands (using ;, &&, and ||) and then 
> running the resulting
> (mega) one liners over ssh.  It still gets run by a shell, but I was 
> specifying the control flow.
Thank you for the reply.  It is indeed a valuable use case to pass a command 
line as one string to ssh, and the split/quote combo should round-trip and be 
useful for this usage.

> I'll see if I can come up with a reference case and maybe a unittest this 
> weekend
Great!  A new argument (with a default value which gets us the previous 
behavior) will probably be needed, to preserve backward compatibility.

--
nosy: +niemeyer
versions: +Python 3.3 -Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13479] pickle too picky on re-defined classes

[Guido van Rossum]

Guido van Rossum  added the comment:

Hm, this change allows many other *undesirable* objects pass the test as well. 
I'd prefer to stick to the rule, "when in doubt, raise an error".
Maybe using == instead of 'is' as the test would be acceptable?

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Éric Araujo]

Éric Araujo  added the comment:

I don’t understand all the issues and it’s too late for me to read all the 
thread, but I hope these comments are helpful:

- If our goal is to help naïve users, then one or two new options wouldn’t help 
(people want to run “python path/to/thing.py” and want it to Just Work™)

- Getting a very helpful error message is second-best to Just Working™

- This probably needs a wider audience, python-ideas or python-dev, and maybe a 
PEP to explain all the issues and all the considered solutions.

--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9957] SpooledTemporayFile.truncate should take size parameter

[Éric Araujo]

Éric Araujo  added the comment:

Okay, then stable branches need a doc/docstring patch to remove the statement 
that SpooledTemporaryFile “operates exactly as TemporaryFile does”.  Ryan, 
would you like to do that patch too?

Antoine, will you commit?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13472] devguide doesn’t list all build dependencies

[Éric Araujo]

Éric Araujo  added the comment:

> Moreover these dependencies are optional, so there's no need to install them 
> unless they are
> specifically needed
I think about it in the reverse: You want a featurefull library, and disable 
some things (zlib, ssl, threads) only if you specifically don’t want them (if 
you’re a Twisted fan for example ).

> (on a related note I would also add an "optional" in the warning that says 
> "Python build
> finished, but the necessary bits to build these modules were not found" -- 
> I've seen enough
> people complaining that the build "failed" because this dependencies were 
> missing).
Sure.  I read all changesets for Python’s setup.py recently (don’t judge) and 
the addition of this message and further edits to its wording were done exactly 
to avoid people worrying that their python binary is not usable.

> Explaining how to get them in the build page sounds fine to me.
Okay; do we need to collect info for all major OSes (I’m taking the list of 
stable 3.2 buildbots to determine “major”)?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13400] packaging: build command should accept --compile, --no-compile and --optimize options

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

Maybe --byte-compile and --no-byte-compile could be used.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12876] Make Test Error : ImportError: No module named _sha256

[Éric Araujo]

Éric Araujo  added the comment:

Sorry to be of little help.  I also have a problem with hashlib, but it’s with 
Python 2.4 on Debian multiarch with linux3, so probably different from your 
problem.  You could try asking on the python-dev mailing list.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13210] Support Visual Studio 2010

[Brian Curtin]

Brian Curtin  added the comment:

Before we both go down the same paths and duplicate effort, 
http://hg.python.org/sandbox/vs2010port/ has already completed the transition 
in terms of running the conversion, saving off the VS9 files, making some 
minimal code changes (errno module specifically), and has begun to fix tests. 
This is already done for 'default' aka 3.3.

8 tests failed:
test_distutils test_email test_io test_os test_packaging
test_pep3151 test_socket test_subprocess

The distutils and packaging test failures seem to be about differences in 
command line flags for some of the VS2010 binaries (looks like a link.exe issue 
in one). Most of the others are about remaining errno differences, and the 
subprocess issue is with too many files being open.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10752] build_ssl.py is relying on unreliable behaviour of os.popen

[Sébastien Sablé]

Sébastien Sablé  added the comment:

I had the same issue while compiling Python 2.7 with ActivePerl on windows, and 
I can confirm that the proposed patch solves the issue.

--
nosy: +sable
versions: +Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12618] py_compile cannot create files in current directory

[Meador Inge]

Meador Inge  added the comment:

Éric, sure, I will commit the tests sometime today.  Then I will respond to the 
'os.path.abspath' question as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

I've identified a few other cases where a '#' format is passed a numeric 
literal:

Python/codecs.c:514: return Py_BuildValue("(u#n)", &end, 0, end);
Modules/_io/textio.c:2323: DECODER_DECODE(input, 1, n);

--
nosy: +amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
priority: normal -> high
type:  -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
versions: +Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Thanks Antoine! It solved the issue.

I will check soon with Python trunk to see if the same thing applies.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13210] Support Visual Studio 2010

[Éric Araujo]

Éric Araujo  added the comment:

Just to avoid misunderstandings: The Subversion concept of trunk (or rather 
py3k trunk) maps to the Mercurial branch named default, which is what you get 
when you clone hg.python.org/cpython.  This is 3.3.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13210] Support Visual Studio 2010

[Sébastien Sablé]

Sébastien Sablé  added the comment:

Yes I know, but this is my primary target as this is the version that I use in 
my product for the moment.

I will test python trunk soon now that Python 2.7 with VS2010 is in a rather 
good shape.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9708] cElementTree iterparse does not support "parser" argument

[Silvan Jegen]

Silvan Jegen  added the comment:

I changed a few lines in the glue code of the _elementtree.c Module of Python 
3.3.0a0 to add support for the "parser" argument. I do have to admit though 
that I am not familiar with the Python/C-API so this solution may not be ideal 
(i. e. it may be falling back to the Python implementation of iterparse without 
me realizing).

Please note that it is not possible to give an ElementTree.XMLParser instance 
as a parameter to the cElementTree.iterparse function (which may not be 
desirable in any case) using this patch.

I assume that the patch will be applicable to Python 2.7.x as well, but I did 
not try it. I can apply/adapt it to Python 2.7.x, if you think that would be 
useful.

--
keywords: +patch
nosy: +Shugyousha
Added file: http://bugs.python.org/file23777/issue9708.Python330a0.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11365] Integrate Buildroot patches (cross-compilation)

[Éric Araujo]

Éric Araujo  added the comment:

Because I don’t think anyone will have the time to try to port Python’s 
setup.py to packaging, fix the bugs it founds and add the features it needs in 
time for 3.3.  On my own todo lists, there is much work still needed to define 
the public API, add features we want, test it with real applications such as 
pip, fix major bugs, make the docs usable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13210] Support Visual Studio 2010

[Brian Curtin]

Brian Curtin  added the comment:

Just to be sure in case you didn't know, but patches against 2.7 for this issue 
won't be accepted.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13210] Support Visual Studio 2010

[Sébastien Sablé]

Sébastien Sablé  added the comment:

I don't have commit access on hg.python.org, so I also created a clone on 
bitbucket at:
https://bitbucket.org/sablefr/py27vs2010/overview

I work with a patch queue for the moment since everything is not completely 
settled yet.

The patch are against python 2.7 for the moment, I will do the same for python 
trunk soon.
I can run all the tests with builbot and I am working on reducing the errors.

Currently I am at:
337 tests OK.
5 tests failed:
test_anydbm test_pep277 test_shelve test_subprocess test_trace
1 test altered the execution environment:
test_distutils
45 tests skipped:
test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl
test_commands test_crypt test_curses test_dbm test_dl test_epoll
test_fcntl test_fork1 test_gdb test_gdbm test_gl test_grp
test_imgfile test_ioctl test_kqueue test_linuxaudiodev test_macos
test_macostools test_mhlib test_nis test_openpty test_ossaudiodev
test_pipes test_poll test_posix test_pty test_pwd test_readline
test_resource test_scriptpackages test_sunaudiodev test_tcl
test_threadsignals test_tk test_ttk_guionly test_ttk_textonly
test_wait3 test_wait4 test_zipfile64
6 skips unexpected on win32:
test_gdb test_readline test_tcl test_tk test_ttk_guionly
test_ttk_textonly

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11365] Integrate Buildroot patches (cross-compilation)

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The distutils changes will not happen, we’re under a feature freeze.
> Cross-compilation support would need to be added to packaging, and we
> need to port Python’s build process to packaging too for 3.4 or 3.5.

Why 3.4 or 3.5?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13400] packaging: build command should accept --compile, --no-compile and --optimize options

[Éric Araujo]

Éric Araujo  added the comment:

Thinking about this, build_py --compile clearly refers to byte-compilation of 
Python modules, but the same option on the build command is more ambiguous: It 
could be interpreted to mean “skip C compilation”.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11365] Integrate Buildroot patches (cross-compilation)

[Éric Araujo]

Éric Araujo  added the comment:

The distutils changes will not happen, we’re under a feature freeze.  
Cross-compilation support would need to be added to packaging, and we need to 
port Python’s build process to packaging too for 3.4 or 3.5.  Also, it’s very 
hard to decide to accept one solution from the dozen of different patch sets 
posted on the various issues.  I think this would need a concerted effort from 
all people who have worked on patches, with goals clearly defined in a public 
mailing list, then python-dev agreement (including MvL, who turns a very 
critical eye to such patches), then one patch satisfying the requirements.

I don’t like to reject the hard work of contributors who want to give back, but 
given the situation I describe above I’m inclined to close all of these bugs 
for now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13402] Document absoluteness of sys.executable

[Éric Araujo]

Éric Araujo  added the comment:

This is the bug I was thinking about: #7774.  Adding some people from that 
discussion to nosy.

--
nosy: +flox, haypo, pitrou, ronaldoussoren, schmir

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13480] range exits loop without action when start is higher than end

[R. David Murray]

R. David Murray  added the comment:

Nope.  If you want to count backward, use a negative step.  Not doing anything 
if end is lower than start allows code to take advantage of "don't care" edge 
cases, just like 'abc'[4:] returning the empty string does.  Range is often 
used in 'for' loops, so having the loop not execute if the computed end is less 
than the computed start is an intentional and important feature.

--
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13480] range exits loop without action when start is higher than end

[Asa Dawson]

New submission from Asa Dawson :

range has an odd behavior in which it assumes (regardless of start/end) that it 
should be counting up. Attempting something such as:

for i in range(10,0):
print i

This loop simply runs through without doing anything, because start is larger 
than end.

I'm putting forward the proposition that when end is lower than start, range 
should count downwards rather than upwards.

--
components: None
messages: 148315
nosy: Asa.Dawson
priority: normal
severity: normal
status: open
title: range exits loop without action when start is higher than end
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12559] gzip.open() needs an optional encoding argument

[Rasmus Ory Nielsen]

Changes by Rasmus Ory Nielsen :


--
nosy: +rasmusory

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11849] glibc allocator doesn't release all free()ed memory

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ah, sorry, false alarm. "b[:] = b" actually makes a temporary copy of the 
bytearray when assigning to itself (!).

However, there's still another strange regression:

$ ./python -m timeit \
  -s "n=30; f=open('10MB.bin', 'rb', buffering=0); b=bytearray(n)" \
  "f.seek(0);f.readinto(b)"

-> default branch:
1 loops, best of 3: 43 usec per loop
-> default branch with patch reverted:
1 loops, best of 3: 27.5 usec per loop

FileIO.readinto executes a single read() into the passed buffer.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11849] glibc allocator doesn't release all free()ed memory

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I see you're comparing 3.2 and default: could you run the same
> benchmark on default with and without the patch ?

Same results:
-> default branch:
1000 loops, best of 3: 364 usec per loop
-> default branch with patch reverted:
1 loops, best of 3: 185 usec per loop

(with kernel 2.6.38.8-desktop-8.mga and glibc-2.12.1-11.2.mga1)

And I can reproduce on another machine:

-> default branch:
1000 loops, best of 3: 224 usec per loop
-> default branch with patch reverted:
1 loops, best of 3: 88 usec per loop

(Debian stable with kernel 2.6.32-5-686 and glibc 2.11.2-10)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13432] Encoding alias "unicode"

[STINNER Victor]

STINNER Victor  added the comment:

> 

Python is not a language written for the web, it's generic language to program 
anything! If you have a problem to parse an HTML page, the special case should 
be added to the HTML parser, not to the language.

Do you have the encoding issue with a parser included in Python 
(html.parser.*)? If you have the issue with an third-party parser, you have to 
report the bug there.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10278] add time.wallclock() method

[Michael Foord]

Changes by Michael Foord :


--
nosy:  -michael.foord
versions: +Python 3.3 -Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10278] add time.wallclock() method

[Martin Panter]

Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13479] pickle too picky on re-defined classes

[kxroberto]

Changes by kxroberto :


--
title: pickle to picky on re-defined classes -> pickle too picky on re-defined 
classes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13479] pickle to picky on re-defined classes

[kxroberto]

New submission from kxroberto :

When a class definition was re-executed (reload, exec ..) , pickling of 
existing instances fails for to picky reason (class object id mismatch). Solved 
by the one liner patch below.

Rational: Python is dynamic. Like with any normal attribute lookup: When its 
the same module/..name  this class is really meant - no matter about its id. 
(During unpickling its another id anyway, the code may have evolved years ...)


diff -ur --strip _orig/pickle.py ./pickle.py
--- _orig/pickle.py 2008-09-08 10:58:32 +
+++ ./pickle.py 2011-11-24 15:47:11 +
@@ -747,7 +747,7 @@
 "Can't pickle %r: it's not found as %s.%s" %
 (obj, module, name))
 else:
-if klass is not obj:
+if klass.__name__ != obj.__name__:
 raise PicklingError(
 "Can't pickle %r: it's not the same object as %s.%s" %
 (obj, module, name))

--
components: Library (Lib)
messages: 148311
nosy: kxroberto
priority: normal
severity: normal
status: open
title: pickle to picky on re-defined classes
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13475] Add '-p'/'--path0' command line option to override sys.path[0] initialisation

[Eric Snow]

Eric Snow  added the comment:

The current behavior is an implicit "-p .", which causes all sorts of 
hard-to-figure-out problems, most of which PEP 395 is rightly trying to fix.  
I'm suggesting that the next step would be to make "--nopath0" the default 
(rendering the flag unnecessary).  Since this changes the status quo, I'll try 
to make the case here that it's worth it.

---

First of all, the current implicit sys.path[0] initialization for scripts has 
been around since forever.  Why would we change it now?  The inspiration is 
three-fold: we _said_ we got rid of implicit relative imports already, PEP 395 
already has made a case for changing the status quo (though not to this 
degree), and a "-p" flag provides a simple mechanism to get the current 
behavior explicitly.

Like Nick says in PEP 395, "PEP 328 eliminated implicit relative imports from 
imported modules. This PEP proposes that the de facto implicit relative imports 
from main modules that are provided by the current initialisation behaviour for 
sys.path[0] also be eliminated."

I'm just saying we should go all the way, and that the "-p" flag would allow 
that.  As far as I can tell, there are two meaningful use cases for the 
currently implicit sys.path[0]:  When you are first _learning_ Python (not 
actually using it)...  When you are working on a new project...  Let's look at 
both, first relative to the currently implicit "-p .", then to the explicit 
site.

1. (current behavior) implicit sys.path[0] initialization

When a beginner is first learning Python, they learn at the interactive prompt 
or by running a single script.  Pretty quickly they learn about writing their 
own modules and using import to load them.

Where do the modules live?  In the CWD from which they are calling the Python 
executable.  The current implicit "-p ." means they can import their modules 
right there, and not have to learn yet about sys.path.  That's nice since they 
can concentrate their focus.

But later they _will_ run into hard-to-figure-out problems when they start 
relying on what are effectively implicit relative imports.  Or they will run 
into one of the problems that PEP 395 explains, which are likewise 
head-scratchers.  All of this can be pretty frustrating when you still don't 
know about things like the import machinery.

Consider how that beginner uses the implicit sys.path[0] behavior on a project, 
once they have some experience (hopefully I don't misrepresent something Nick 
explained to me).  The src/ directory of the project won't be under sys.path 
yet.  So to quickly test out their script, they change to src/ and run their 
script from there (something PEP 395 rightfully proposes fine-tuning).  They 
conveniently don't have to manually fiddle with sys.path.  That's a pretty neat 
trick.

The problem I have with this is that there's no difference between the sys.path 
workaround for the script and it's expected normal usage.  If you aren't aware 
of what's going on behind-the-scenes, you may end up with some confusing import 
exceptions later on.

2. explicit sys.path[0] initialization

With a -p flag, it's really easy to say "-p ." and get the previous implicit 
behavior.  Consider the impact on our beginner.  The try to run their script 
that imports modules in their CWD, but end up with an ImportError because we no 
longer have an implicit "-p .".

How is this an improvement?  No more mysterious default behavior.  There's only 
one way it will fail and it will fail the same way every time.  They'll learn 
pretty quickly (if not taught already) you have to use the -p flag if you want 
to import modules that aren't in the "standard" places.  The ImportError 
message, special-cased for imports in __main__, could help in that regard.


As an aside, implicit or explicit "--nopath0", the path to the file for the 
failed import can really help in related situations.  Including it as an 
attribute on the ImportError, and especially in the error message, would rock.  
See issue1559549.


For the "src/" use-case, the developer won't be able to rely on the implicit 
behavior anymore.  A simple, explicit "-p ." fills the gap and makes it clear 
that they are doing something unusual.  On top of that, they can use -p with 
the path to the "src/" directory from anywhere and not have to change their 
directory.  All the better if -p takes advantage of the proposals in PEP 395.


In the end, this boils down to opt-in vs. opt-out.  Either you opt-in to the 
sys.path[0] initialization by using -p, or you opt-out of the default implicit 
"-p ." by passing "--nopath0".  It's a case of "explicit is better than 
implicit" without a clear reason, to me, that the status quo is worth the 
exception anymore in the face of the alternative.

My only concern would be backwards compatibility.  How much do scripts out 
there rely on the implicit sys.path[0] initialization that aren't already 
broken by the removal of implicit relative imports?  I simply don't 

[issue8754] quote bad module name in ImportError-like messages

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13432] Encoding alias "unicode"

[kxroberto]

kxroberto  added the comment:

I wonder where is the origin, who is the inventor of the frequent 
charset=unicode? But:


"Sorry, but it's not obviously that Unicode means UTF-8."

When I faced

the first time on the web, I guessed it is UTF-8 without looking. It even 
sounds colloquially reasonable ;-)  And its right 99.999% of cases. 
(UTF-16 is less frequent than this non-canonical "unicode")


"Definitely; this will just serve to create more confusion for beginners over 
what a Unicode string is:
unicodestring.encode('unicode')   <- WTF?"

I guess no python tutorial writer or encoding menu writer poses that example. 
That string comes in on technical paths:  web, MIME etc.
In the aliases.py there are many other names which are not canonical. frequency 
> convenience > alias


"Joining the chorus: people who need it in their application will have to add 
it themselves (monkeypatching the aliases dictionary as appropriate)."

Those people first would need to be aware of the option: Be all-seeing, or all 
wait for the first bug reports ...  


Reverse question: what would be the minus of having this alias?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11849] glibc allocator doesn't release all free()ed memory

[Charles-François Natali]

Charles-François Natali  added the comment:

> For the record, this seems to make large allocations slower:
>
> -> with patch:
> $ ./python -m timeit "b'x'*20"
> 1 loops, best of 3: 27.2 usec per loop
>
> -> without patch:
> $ ./python -m timeit "b'x'*20"
> 10 loops, best of 3: 7.4 usec per loop
>

Yes, IIRC, I warned it could be a possible side effect: since we're
now using mmap() instead of brk() for large allocations (between 256B
and 32/64MB), it can be slower (that's the reason adaptive mmap
threadshold was introduced in the first place).

> More surprising is that, even ignoring the allocation cost, other operations 
> on the memory area seem more expensive:

Hum, this it strange.
I see you're comparing 3.2 and default: could you run the same
benchmark on default with and without the patch ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13478] No documentation for timeit.default_timer

[Sandro Tosi]

New submission from Sandro Tosi :

Hello,
timeit documentation doesn't mention default_timer, while the module exposes it 
publicly and there's code snippets on the web using it. It should be documented 
then.


ps: adding Georg to nosy as per Experts list

--
assignee: docs@python
components: Documentation
messages: 148307
nosy: docs@python, georg.brandl, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: No documentation for timeit.default_timer
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com