Mailman 3 May 2015 - Python-Dev

Re: [Python-Dev] cpython (merge 3.4 -> default): Added tests for more builtin types.
by Ned Deily May 17, 2015

May 17, 2015

In article <20150516183940.21146.77232(a)psf.io>, serhiy.storchaka <python-checkins(a)python.org> wrote: > https://hg.python.org/cpython/rev/7b350f712c0e > changeset: 96099:7b350f712c0e > parent: 96096:f0c94892ac31 > parent: 96098:955dffec3d94 > user: Serhiy Storchaka <storchaka(a)gmail.com> > date: Sat May 16 21:35:56 2015 +0300 > summary: > Added tests for more builtin types. > Made test_pprint discoverable. > > … [View More]

3 2

Re: [Python-Dev] [Python-checkins] peps: Apply Chris's changes, including an acceptance mark
by Yury Selivanov May 17, 2015

May 17, 2015

Chris, Could you please add a link to the email where the PEP was accepted? Thanks, Yury On 2015-05-16 10:12 PM, chris.angelico wrote: > https://hg.python.org/peps/rev/f876276ce076 > changeset: 5854:f876276ce076 > user: Chris Angelico <rosuav(a)gmail.com> > date: Sun May 17 12:12:19 2015 +1000 > summary: > Apply Chris's changes, including an acceptance mark > > files: > pep-0485.txt | 6 +++--- > 1 files changed, 3 insertions(+), 3 … [View More]

2 1

No tags in semi-official github mirror of cpython repository.
by INADA Naoki May 16, 2015

May 16, 2015

Hi. I foud "semi official github mirror" of cpython. https://github.com/python/cpython I want to use it as upstream of our project (Translating docs in Japanese). But it doesn't have tags. Is the repository stable enough for forking project like us? Or should we use mercurial? Could you mirror tags too? Thanks -- INADA Naoki <songofacandy(a)gmail.com>

2 1

Scandir module's C code updated to Python 3.5 code
by Ben Hoyt May 15, 2015

May 15, 2015

Hi folks, With os.scandir() now in the Python 3.5 stdlib, I just thought I'd let folks know that I've released the scandir module version 1.0. So this is now basically a copy-n-paste of the C code that went into CPython 3.5's posixmodule.c with the necessary changes to make it work or Python 2.x (2.6+). You can use the following import to pick os.scandir/os.walk if on Python 3.5+ or the scandir module version otherwise: try: from os import scandir, walk except ImportError: … [View More]

1 0

Minimal async event loop and async utilities (Was: PEP 492: async/await in Python; version 4)
by Paul Moore May 15, 2015

May 15, 2015

On 6 May 2015 at 07:46, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > Another problem with the "core" idea is that > you can't start with an event loop that "just does > scheduling" and then add on other features such > as I/O *from the outside*. There has to be some > point at which everything comes together, which > means choosing something like select() or > poll() or I/O completion queues, and build that > into the heart of your event loop. At that point … [View More]

4 5

Re: [Python-Dev] cpython: inspect: Add __slots__ to BoundArguments.
by Serhiy Storchaka May 15, 2015

May 15, 2015

On 14.05.15 00:38, yury.selivanov wrote: > https://hg.python.org/cpython/rev/ee31277386cb > changeset: 96038:ee31277386cb > user: Yury Selivanov <yselivanov(a)sprymix.com> > date: Wed May 13 17:18:41 2015 -0400 > summary: > inspect: Add __slots__ to BoundArguments. Note that adding __slots__ breaks pickleability.

3 3

Summary of Python tracker Issues
by Python tracker May 15, 2015

May 15, 2015

ACTIVITY SUMMARY (2015-05-08 - 2015-05-15) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 4840 ( +2) closed 31123 (+54) total 35963 (+56) Open issues with patches: 2237 Issues opened (39) ================== #21162: code in multiprocessing.pool freeze if inside some code from s http://bugs.python.org/issue21162 reopened by Ivan.K #21593: Clarify … [View More]

1 0

Re: [Python-Dev] cpython: inspect: Micro-optimize __eq__ for Signature, Parameter and BoundArguments
by Serhiy Storchaka May 15, 2015

May 15, 2015

On 15.05.15 01:23, yury.selivanov wrote: > https://hg.python.org/cpython/rev/f0b10980b19e > changeset: 96056:f0b10980b19e > parent: 96054:15701e89d710 > user: Yury Selivanov <yselivanov(a)sprymix.com> > date: Thu May 14 18:20:01 2015 -0400 > summary: > inspect: Micro-optimize __eq__ for Signature, Parameter and BoundArguments > > Provide __ne__ method for consistency. > > files: > Lib/inspect.py | 32 ++++++++++++++++++++++----… [View More]

1 0

PEP 455 -- TransformDict
by Raymond Hettinger May 14, 2015

May 14, 2015

Before the Python 3.5 feature freeze, I should step-up and formally reject PEP 455 for "Adding a key-transforming dictionary to collections". I had completed an involved review effort a long time ago and I apologize for the delay in making the pronouncement. What made it a interesting choice from the outset is that the idea of a "transformation" is an enticing concept that seems full of possibility. I spent a good deal of time exploring what could be done with it but found that it mostly … [View More]fell short of its promise. There were many issues. Here are some that were at the top: * Most use cases don't need or want the reverse lookup feature (what is wanted is a set of one-way canonicalization functions). Those that do would want to have a choice of what is saved (first stored, last stored, n most recent, a set of all inputs, a list of all inputs, nothing, etc). In database terms, it models a many-to-one table (the canonicalization or transformation function) with the one being a primary key into another possibly surjective table of two columns (the key/value store). A surjection into another surjection isn't inherently reversible in a useful way, nor does it seem to be a common way to model data. * People are creative at coming up with using cases for the TD but then find that the resulting code is less clear, slower, less intuitive, more memory intensive, and harder to debug than just using a plain dict with a function call before the lookup: d[func(key)]. It was challenging to find any existing code that would be made better by the availability of the TD. * The TD seems to be all about combining data scrubbing (case-folding, unicode canonicalization, type-folding, object identity, unit-conversion, or finding a canonical member of an equivalence class) with a mapping (looking-up a value for a given key). Those two operations are conceptually orthogonal. The former doesn't get easier when hidden behind a mapping API and the latter loses the flexibility of choosing your preferred mapping (an ordereddict, a persistentdict, a chainmap, etc) and the flexibility of establishing your own rules for whether and how to do a reverse lookup. Raymond Hettinger P.S. Besides the core conceptual issues listed above, there are a number of smaller issues with the TD that surfaced during design review sessions. In no particular order, here are a few of the observations: * It seems to require above average skill to figure-out what can be used as a transform function. It is more expert-friendly than beginner friendly. It takes a little while to get used to it. It wasn't self-evident that transformations happen both when a key is stored and again when it is looked-up (contrast this with key-functions for sorting which are called at most once per key). * The name, TransformDict, suggests that it might transform the value instead of the key or that it might transform the dictionary into something else. The name TransformDict is so general that it would be hard to discover when faced with a specific problem. The name also limits perception of what could be done with it (i.e. a function that logs accesses but doesn't actually change the key). * The tool doesn't self describe itself well. Looking at the help(), or the __repr__(), or the tooltips did not provide much insight or clarity. The dir() shows many of the _abc implementation details rather than the API itself. * The original key is stored and if you change it, the change isn't stored. The _original dict is private (perhaps to reduce the risk of putting the TD in an inconsistent state) but this limits access to the stored data. * The TD is unsuitable for bijections because the API is inherently biased with a rich group of operators and methods for forward lookup but has only one method for reverse lookup. * The reverse feature is hard to find (getitem vs __getitem__) and its output pair is surprising and a bit awkward to use. It provides only one accessor method rather that the full dict API that would be given by a second dictionary. The API hides the fact that there are two underlying dictionaries. * It was surprising that when d[k] failed, it failed with transformation exception rather than a KeyError, violating the expectations of the calling code (for example, if the transformation function is int(), the call d["12"] transforms to d[12] and either succeeds in returning a value or in raising a KeyError, but the call d["12.0"] fails with a TypeError). The latter issue limits its substitutability into existing code that expects real mappings and for exposing to end-users as if it were a normal dictionary. * There were other issues with dict invariants as well and these affected substitutability in a sometimes subtle way. For example, the TD does not work with __missing__(). Also, "k in td" does not imply that "k in list(td.keys())". * The API is at odds with wanting to access the transformations. You pay a transformation cost both when storing and when looking up, but you can't access the transformed value itself. For example, if the transformation is a function that scrubs hand entered mailing addresses and puts them into a standard format with standard abbreviations, you have no way of getting back to the cleaned-up address. * One design reviewer summarized her thoughts like this: "There is a learning curve to be climbed to figure out what it does, how to use it, and what the applications [are]. But, the [working out the same] examplea with plain dicts requires only basic knowledge." -- Patricia [View Less]

3 2

Mac popups running make test
by Skip Montanaro May 14, 2015

May 14, 2015

I haven't run the test suite in awhile. I am in the midst of running it on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup: I assume this is testing some server listening on localhost. Is this a new thing, either with the Python test suite or with Mac OS X? (I'd normally be hidden behind a NAT firewall, but at the moment I am on a miserable public connection in a Peet's Coffee, so it takes on slightly more importance...) I've also seen the Crash Reporter pop up many … [View More]

7 9

Repository builds as 2.7.8+
by Terry Reedy May 13, 2015

May 13, 2015

Python 2.7.8+ (default, May 13 2015, 16:46:29) [MSC v.1500 32 bit (Intel)] on win32 Shouldn't this be 2.7.9+ or 2.7.10rc1? -- Terry Jan Reedy

3 4

Fwd: [docs] Python documentation missing
by Sandro Tosi May 13, 2015

May 13, 2015

Hello, this happens every time we cut a RC release: the files referenced in the download section are missing and (rightfully so) people complain ---------- Forwarded message ---------- From: Ronald Legere <rjljr2(a)gmail.com> Date: Wed, May 13, 2015 at 11:14 AM Subject: [docs] Python documentation missing To: docs(a)python.org The links to the downloadable documentation for python 2.7 are 404 on this page: https://docs.python.org/2/download.html Are they available somewhere???? --… [View More]

2 2

Re: [Python-Dev] cpython: Issue #20172: Convert the winsound module to Argument Clinic.
by Serhiy Storchaka May 13, 2015

May 13, 2015

On 13.05.15 09:32, zach.ware wrote: > https://hg.python.org/cpython/rev/d3582826d24c > changeset: 96006:d3582826d24c > user: Zachary Ware <zachary.ware(a)gmail.com> > date: Wed May 13 01:21:21 2015 -0500 > summary: > Issue #20172: Convert the winsound module to Argument Clinic. > +/*[clinic input] > +winsound.PlaySound > + > + sound: Py_UNICODE(nullable=True) I think this is no longer correct syntax. Should be Py_UNICODE(accept={str, NoneType}).

2 1

Re: [Python-Dev] [Python-checkins] cpython: Issue #24064: Property() docstrings are now writeable.
by Eric V. Smith May 13, 2015

May 13, 2015

On 5/13/2015 4:10 AM, raymond.hettinger wrote: > https://hg.python.org/cpython/rev/1e8a768fa0a5 > changeset: 96010:1e8a768fa0a5 > user: Raymond Hettinger <python(a)rcn.com> > date: Wed May 13 01:09:59 2015 -0700 > summary: > Issue #24064: Property() docstrings are now writeable. > (Patch by Berker Peksag.) > diff --git a/Doc/library/collections.rst b/Doc/library/collections.rst > --- a/Doc/library/collections.rst > +++ b/Doc/library/… [View More]

2 1

Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
by Larry Hastings May 13, 2015

May 13, 2015

On 05/12/2015 11:18 AM, Jesus Cea wrote: > Larry, could you comment about the impact in the buildbots?. I suppose > option #1 could allows us to test both 3.5 and 3.6 changes. Would you > confirm this? Workflow #1 gets us automatic buildbot testing for the 3.5 branch (betas and 3.5.1) and trunk (3.6). It doesn't get us testing of the 3.5.0 release candidates automatically, because those would be hosted at bitbucket. However: hg.python.org allows creating "server-side clones" … [View More]

1 0

Fwd: Coverity Scan update
by Guido van Rossum May 12, 2015

May 12, 2015

---------- Forwarded message ---------- From: "Dakshesh Vyas" <dvyas(a)coverity.com> Date: May 12, 2015 1:08 AM Subject: Coverity Scan update To: "guido(a)python.org" <guido(a)python.org> Cc: Hello Guido van Rossum, Thank you for using Coverity Scan. With more than 4000 open source projects now registered at Coverity Scan, we are committed to help the open source community find quality and security issues early in development. We would like to inform you that you can now nominate … [View More]your favorite defect! Tell us which defects you are glad were found using Coverity Scan and get special gifts like a Samsung Gear 2 Smartwatch, Code Black Drone or Tile for iOS and Android. Gifts will be distributed every month based on defect nomination! We recently added new hardware resource and upgraded our Scan server to our latest 7.6 version, which includes great new features: * New security and quality checkers with version 7.6. * You can now setup automatic approval for viewing defects in read-only mode for everyone. * See charts showing defects outstanding vs. fixed over a period of time, and sort high impact defects by category. * Support for standard SSL port 443 instead of 8443. * Subscribe to email notifications for your entire open source project or for specific components or modules within your project. * You can now submit builds more frequently. * Please download the latest Coverity Build tool from https://scan.coverity.com/download * The old Coverity Build tool will still continue to work, but it may not be able to find some security and quality defects that could be found using our new and improved checkers as a part of 7.6 upgrade. * Important note for projects that uses automation or a script to submit build to Coverity Scan: The old URL to upload build on scan5.coverity.com is no longer supported. It is applicable to and used by some of the old projects on Coverity Scan. * Please sign-in to Coverity Scan to find the updated URL under automation section of Submit Build. * Finally, don't forget to nominate your favorite defects to receive special gifts like a Samsung Gear 2 Smartwatch, Code Black Drone or Tile for iOS and Android every month! Post your technical questions at https://communities.coverity.com/community/scan-(open-source)/content Please email us at scan-admin(a)coverity.com if you have any question or concerns, and we would be happy to help you. Thanks Dakshesh Vyas | Technical Manager - Coverity Scan Office: 415.935.2957 | dvyas(a)coverity.com https://scan.coverity.com/ Coverity by Synopsys To manage Coverity Scan email notifications, click https://scan.coverity.com/subscriptions/edit?email=guido%40python.org&token… [View Less]

2 1

Clarification of PEP 476 "opting out" section
by Nick Coghlan May 12, 2015

May 12, 2015

Hi folks, This is just a note to highlight the fact that I tweaked the "Opting out" section in PEP 476 based on various discussions I've had over the past few months: https://hg.python.org/peps/rev/dfd96ee9d6a8 The notable changes: * the example monkeypatching code handles AttributeError when looking up "ssl._create_unverified_context", in order to accommodate older versions of Python that don't have PEP 476 implemented * new paragraph making it clearer that while the intended use case for … [View More]

8 41

Re: [Python-Dev] anomaly
by Mark Rosenblitt-Janssen May 12, 2015

May 12, 2015

In case the example given at the start of the thread wasn't interesting enough, it also works in the other direction: >>> class str(int): pass >>> str('2') 2 #<----- an integer!!! Mark

3 2

What's missing in PEP-484 (Type hints)
by Dima Tisnek May 12, 2015

May 12, 2015

# Syntactic sugar "Beautiful is better than ugly, " thus nice syntax is needed. Current syntax is very mechanical. Syntactic sugar is needed on top of current PEP. # internal vs external @intify def foo() -> int: b = "42" return b # check 1 x = foo() // 2 # check 2 Does the return type apply to implementation (str) or decorated callable (int)? How can same annotation or a pair of annotations be used to: * validate return statement type * validate subsequent use * look reasonable … [View More]

4 6

Unicode literals in Python 2.7
by Adam Bartoš May 12, 2015

May 12, 2015

Hello, is it possible to somehow tell Python 2.7 to compile a code entered in the interactive session with the flag PyCF_SOURCE_IS_UTF8 set? I'm considering adding support for Python 2 in my package ( https://github.com/Drekin/win-unicode-console) and I have run into the fact that when u"α" is entered in the interactive session, it results in u"\xce\xb1" rather than u"\u03b1". As this seems to be a highly specialized question, I'm asking it here. Regards, Drekin

10 23

Free lists
by Serhiy Storchaka May 11, 2015

May 11, 2015

Here is a statistic for most called PyObject_INIT or PyObject_INIT_VAR for types (collected during running Python tests on 32-bit Linux). type count % acc.% builtin_function_or_method 116012007 36.29% 36.29% method 52465386 16.41% 52.70% int 42828741 13.40% 66.09% str 37017098 11.58% 77.67% generator 14026583 4.39% 82.06% … [View More]list_iterator 8731329 2.73% 84.79% bytes 7217934 2.26% 87.04% tuple_iterator 5042563 1.58% 88.62% float 4672980 1.46% 90.08% set 3319699 1.04% 91.12% _io.StringIO 3000369 0.94% 92.06% str_iterator 2126838 0.67% 92.73% list 2031059 0.64% 93.36% dict 1691993 0.53% 93.89% method-wrapper 1573139 0.49% 94.38% function 1472062 0.46% 94.84% traceback 1388278 0.43% 95.28% tuple 1132071 0.35% 95.63% memoryview 1092173 0.34% 95.97% cell 1049496 0.33% 96.30% managedbuffer 1036889 0.32% 96.63% bytearray 711969 0.22% 96.85% range_iterator 496924 0.16% 97.00% range 483971 0.15% 97.15% super 472447 0.15% 97.30% map 449567 0.14% 97.44% frame 427320 0.13% 97.58% set_iterator 423392 0.13% 97.71% Leaf 398705 0.12% 97.83% symtable 374412 0.12% 97.95% Types for which free lists already are used: builtin_function_or_method, method, float, tuple, list, dict, frame. Some free list implementations (e.g. for tuple) don't call PyObject_INIT/PyObject_INIT_VAR. That is why numbers are such low for tuples. Perhaps it is worth to add free lists for other types: int, str, bytes, generator, list and tuple iterators? Shortened tables for variable-sized objects (that calls PyObject_INIT_VAR): int 42828741 13.40% 0 425353 0.99% 0.99% 1 21399290 49.96% 50.96% 2 10496856 24.51% 75.47% 3 4873346 11.38% 86.85% 4 1021563 2.39% 89.23% 5 1246444 2.91% 92.14% 6 733676 1.71% 93.85% 7 123074 0.29% 94.14% 8 139203 0.33% 94.47% ... bytes 7217934 2.26% 0 842 0.01% 0.01% 1 179469 2.49% 2.50% 2 473306 6.56% 9.06% 3 254968 3.53% 12.59% 4 1169164 16.20% 28.79% 5 72806 1.01% 29.79% 6 128668 1.78% 31.58% 7 169694 2.35% 33.93% 8 155154 2.15% 36.08% 9 67320 0.93% 37.01% 10 51703 0.72% 37.73% 11 42574 0.59% 38.32% 12 108947 1.51% 39.83% 13 40812 0.57% 40.39% 14 126783 1.76% 42.15% 15 37873 0.52% 42.67% 16 447482 6.20% 48.87% 17 194320 2.69% 51.56% 18 251685 3.49% 55.05% 19 159435 2.21% 57.26% 20 212521 2.94% 60.20% ... 31 18751 0.26% 67.32% 32 159781 2.21% 69.54% 33 8332 0.12% 69.65% ... 63 19841 0.27% 79.21% 64 144982 2.01% 81.22% 65 5216 0.07% 81.29% ... 127 1354 0.02% 85.44% 128 376539 5.22% 90.66% 129 17468 0.24% 90.90% ... 255 178 0.00% 92.39% 256 11993 0.17% 92.55% 257 124 0.00% 92.56% ... [View Less]

4 7

Re: [Python-Dev] [Python-checkins] cpython (3.4): asyncio: async() function is deprecated in favour of ensure_future().
by Paul Moore May 11, 2015

May 11, 2015

On 11 May 2015 at 19:50, yury.selivanov <python-checkins(a)python.org> wrote: > https://hg.python.org/cpython/rev/b78127eafad7 > changeset: 95956:b78127eafad7 > branch: 3.4 > parent: 95953:a983d63e3321 > user: Yury Selivanov <yselivanov(a)sprymix.com> > date: Mon May 11 14:48:38 2015 -0400 > summary: > asyncio: async() function is deprecated in favour of ensure_future(). > > files: > Lib/asyncio/base_events.py … [View More]

2 2

[RELEASE] Python 2.7.10 release candidate 1
by Benjamin Peterson May 11, 2015

May 11, 2015

It is my privilege to announce the first release candidate of 2.7.10, the next bugfix release in the 2.7 series. Downloads are at https://www.python.org/downloads/release/python-2710rc1/ The full changelog is at https://hg.python.org/cpython/raw-file/80ccce248ba2/Misc/NEWS Please consider testing 2.7.10rc1 with your application and reporting bugs to https://bugs.python.org Regards, Benjamin

1 0

anomaly
by Mark Rosenblitt-Janssen May 11, 2015

May 11, 2015

Here's something that might be wrong in Python (tried on v2.7): >>> class int(str): pass >>> int(3) '3' Mark

2 1

Is it kosher to use a buffer after release?
by Larry Hastings May 10, 2015

May 10, 2015

In Python's argument parsing code (convertsimple in Python/getargs.c), a couple of format units* accept "read-only bytes-like objects", aka read-only buffer objects. They call a helper function called convertbuffer() which uses the buffer protocol to extract a pointer to the memory. Here's the relevant bit of code: static Py_ssize_t convertbuffer(PyObject *arg, void **p, char **errmsg) { Py_buffer view; ... if (getbuffer(arg, &view, errmsg) < 0) … [View More]

2 1