Mailman 3 April 2014 - Python-Dev

Python 2.7.7. on Windows
by Mike Miller April 30, 2014

April 30, 2014

Greetings, I've just woken up and noticed Python 2.7.7 is on track to be released, and in a rather unique event contains a few security enhancements in addition to the usual fixes: http://legacy.python.org/dev/peps/pep-0466/ I thought this might be a good time to make a final plea to fix a long-standing security issue in the installer on Windows. By default it installs Python to the root folder, thereby bypassing filesystem permissions: http://bugs.python.org/issue1284316 The main rationale given (for not using the standard %ProgramFiles%) has been that the full path to python is too long to type, and ease of use is more important than the security benefits given by following Windows conventions. However, adding python to the PATH variable is an alternative solution that would result in even fewer keystrokes needing to be typed at a console, while maintaining system security. As this is an installer setting and not a code change, I gather that the opportunities for code breakage should be fewer. Please consider updating this setting to a more secure and friendly default, for 2.7.7 and 3.5+ as well. -Mike

14 25

Aborting unit tests on first failure
by Nikolaus Rath April 30, 2014

April 30, 2014

Hello, I've just run the testsuite of hg tip with ./python -m test -u network,urlfetch -j 8 -G -v and it finished with ,---- | [...] | test_extract_dir (test.test_zipfile.TestWithDirectory) ... ok | test_store_dir (test.test_zipfile.TestWithDirectory) ... ok | test_different_file (test.test_zipfile.TestsWithMultipleOpens) ... ok | test_interleaved (test.test_zipfile.TestsWithMultipleOpens) ... ok | test_same_file (test.test_zipfile.TestsWithMultipleOpens) ... ok | | ---------------------------------------------------------------------- | Ran 163 tests in 14.522s | | OK (skipped=25) | 368 tests OK. | 2 tests failed: | test_decimal test_itertools | 1 test altered the execution environment: | test___all__ | 17 tests skipped: | test_bz2 test_curses test_dbm_gnu test_devpoll test_idle | test_kqueue test_msilib test_ossaudiodev test_readline | test_startfile test_tcl test_tk test_ttk_guionly test_ttk_textonly | test_winreg test_winsound test_zipfile64 `---- I thought the -G option is would cause the test to stop as soon as an error occured: | -G, --failfast fail as soon as a test fails (only with -v or -W) But it my case it seems that it actually continued to run all the other test modules. Did I misunderstand what -G is supposed to do, or is this a bug in the test runner? It seems to work fine within a single test module, i.e. if I run | ./python -m test -u network,urlfetch -j 8 -G -v test_decimal ..then execution stops right after the failed test. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«

2 1

bytes with trailing \0?
by Nikolaus Rath April 29, 2014

April 29, 2014

Hello, I was surprised to find the following in bytesobject.c: ,---- | [...] | As always, an extra byte is allocated for a trailing \0 byte (newsize | does *not* include that), and a trailing \0 byte is stored. | */ | | int | _PyBytes_Resize(PyObject **pv, Py_ssize_t newsize) | { | [...] | `---- Does this mean that bytes objects are internally stored with a trailing \0? Why is that? Isn't that just wasting a byte, because \0 might also be in the middle of the byte sequence, and the bytes objects stores its length explicitly anyway? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«

2 1

pep8 reasoning
by Chris Withers April 29, 2014

April 29, 2014

Hi All, Apologies if this is considered off topic, but I'm keen to get the "language designers" point of view and short of emailing Barry, Guido and Nick directly, this seemed like the best place. I'm having a tough time persuading some people of the benefits of pep8, particularly when it comes to applying to an existing large code base. The biggest sticking point is naming, particularly as it's the one thing that can't necessarily be changed module by module. What were the compelling reasons to go from mixedCase to underscore_separated? What's considered the best approach for migrating from the former to the latter? A couple of others that have raised some consternation; what are the technical reasons for this pattern being bad: if len(seq) if not len(seq) ...or, for me, the rather ugly: if 0 != len(seq) Likewise, these: if greeting == True: if greeting is True: Please don't misunderstand me: I dislike the above intensely, but it's an emotional response based on 10-15 years of doing things the other way. I'm interested in arguments that don't include things like "it's pythonic" (which some people consider a derogatory term ;-)), or "just because", I trust that the stuff in pep8 was done with specific reasoning in mind, but I'm feeling rather useless at giving that reasoning and I'm hoping you can help :-) cheers, Chris

26 68

Re: [Python-Dev] Python-Dev Digest, Vol 129, Issue 81
by Mike Miller April 28, 2014

April 28, 2014

Hi, note the pep, it makes allowances for security enhancements. -Mike > Message: 5 Date: Mon, 28 Apr 2014 20:23:12 +0200 > From: Antoine Pitrou <solipsis(a)pitrou.net> > To: python-dev(a)python.org Subject: > Re: [Python-Dev] Python 2.7.7. on Windows > Message-ID: <20140428202312.6903d62a@fsol> > Regardless of whether this change this or not, we certainly cannot > change it in a bugfix version. So, 3.5 at the earliest it would be. > Regards > Antoine.

3 2

Re: [Python-Dev] Python 2.7.7. on Windows
by Mike Miller April 28, 2014

April 28, 2014

Hi, Those bugs were fixed 9 years ago or so around 2005. I use python in ProgramFiles every day without issue. If another bug has crept in somewhere, it can be fixed. -Mike > ------------------------------ > From: Sturla Molden <sturla.molden(a)gmail.com> > To: python-dev(a)python.org > Subject: Re: [Python-Dev] Python 2.7.7. on Windows > Message-ID: > <771463774420395726.352685sturla.molden-gmail.com(a)news.gmane.org> > > "C:\Program Files\Python27" contains an empty space in the path. If you > want to randomly break build tools for C extensions, then go ahead and > change it. > > Sturla

1 0

Commit-ready patches needing review
by Nikolaus Rath April 28, 2014

April 28, 2014

Hello, While my last appeal resulted in quite some commits (thanks!), I still have some more commit-ready patches waiting for review. It'd be great if some people could find time to take a look: * http://bugs.python.org/issue1738 (filecmp.dircmp does exact match only) * http://bugs.python.org/issue20951 (SSLSocket.send() returns 0 for non-blocking socket) In this case someone just needs to decide if we want to (a) document the current behavior, (b) deprecate the current behavior or (c) change the current behavior. I have attached patches for (a) and (b), and if (c) is the desired route I'll be happy to create a patch on short notice. * http://bugs.python.org/issue20177 (Derby #8: Convert 28 sites to Argument Clinic across 2 files) * http://bugs.python.org/issue19414 (iter(ordered_dict) yields keys not in dict in some circumstances) * http://bugs.python.org/issue15955 (gzip, bz2, lzma: add option to limit output size) Nadeem has kindly reviewed the first iteration of this patch, but the second iteration has been waiting for attention for quite some time now. * http://bugs.python.org/issue20578 (BufferedIOBase.readinto1 is missing) * http://bugs.python.org/issue21057 (TextIOWrapper does not support reading bytearrays or memoryviews) Best, Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«

3 4

file objects guarantees
by Charles-François Natali April 28, 2014

April 28, 2014

Hi, What's meant exactly by a "file object"? Let me be more specific: for example, pickle.dump() accepts a "file object". Looking at the code, it doesn't check the return value of its write() method. So it assumes that write() should always write the whole data (not partial write). Same thing for read, it assumes there won't be short reads. A sample use case would be passing a socket.makefile() to pickle: it works, because makefile() returns a BufferedReader/Writer which takes care of short read/write. But the documentation just says "file object". And if you have a look the file object definition in the glossary: https://docs.python.org/3.5/glossary.html#term-file-object """ There are actually three categories of file objects: raw binary files, buffered binary files and text files. Their interfaces are defined in the io module. The canonical way to create a file object is by using the open() function. """ So someone passing e.g. a raw binary file - which doesn't handle short reads/writes - would run into trouble. It's the same thing for e.g. GzipFile, and probably many others. Would it make sense to add a note somewhere?

2 1

Add calloc-like memory allocators to Python
by Victor Stinner April 28, 2014

April 28, 2014

Hi, We made progress on the following issue and the latest patch (calloc-5.patch) is ready for a review: http://bugs.python.org/issue21233 This issue should help numpy to reuse Python memory allocators to use the new tracemalloc module of Python 3.4. The issue is only for Python 3.5. It was also discussed that numpy might require a memory allocator with a specified alignment for SIMD instructions. This topic is discussed in a different issue: http://bugs.python.org/issue18835 Summary of calloc-5.patch: - add the following functions: * void* PyMem_RawCalloc(size_t nelem, size_t elsize) * void* PyMem_Calloc(size_t nelem, size_t elsize) * void* PyObject_Calloc(size_t nelem, size_t elsize) * PyObject* _PyObject_GC_Calloc(size_t basicsize) - add "void* calloc(void *ctx, size_t nelem, size_t elsize)" field to the PyMemAllocator structure - optimize bytes(n) and bytearray(n) to allocate objects using calloc() instead of malloc() - update tracemalloc to trace also calloc() - document new functions and add unit tests for the calloc "hook" (in _testcapi) Victor

1 0

Clarification on MRO when inheriting from builtin type.
by Paul Sokolovsky April 28, 2014

April 28, 2014

Hello, I used http://python-history.blogspot.com/2010/06/method-resolution-order.html and https://www.python.org/download/releases/2.3/mro/ as the reference, but it doesn't explain MRO in the following example (python3.4): ~~~~ class User: def __str__(self): return "User.__str__" def append(self, a): print("User", a) class C(list, User): pass t = C([1, 2, 3]) print(t) t.append(10) print(t) print(t[-1]) ~~~~ The output is: ===== User.__str__ User.__str__ 10 ===== From the output, "User" class as expected does not override list.append(), but does override list.__str__(). Is this behavior documented somewhere (complete arrangement)? What's the rationale behind it? I need this info to implement MRO in an alternative Python implementation (MicroPython). Thanks, Paul mailto:pmiscml@gmail.com

2 3