Mailman 3 September 2014 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley 16 Dec '20

16 Dec '20

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann 21 Feb '20

21 Feb '20

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int array of the same size (8 bytes per number, so it occupies about 48 GB memory). At the moment I am extending an array in chunks of several million items at a time at a time, which is slow and not elegant. The function below also initializes each item in the array to a given value (0 by default). Is there a reason why there the array.array constructor does not allow to simply specify the number of items that should be allocated? (I do not really care about the contents.) Would this be a worthwhile addition to / modification of the array module? My suggestions is to modify array generation in such a way that you could pass an iterator (as now) as second argument, but if you pass a single integer value, it should be treated as the number of items to allocate. Here is my current workaround (which is slow): def filled_array(typecode, n, value=0, bsize=(1<<22)): """returns a new array with given typecode (eg, "l" for long int, as in the array module) with n entries, initialized to the given value (default 0) """ a = array.array(typecode, [value]*bsize) x = array.array(typecode) r = n while r >= bsize: x.extend(a) r -= bsize x.extend([value]*r) return x

14 20

Implicit string literal concatenation considered harmful?
by Guido van Rossum 14 Mar '18

14 Mar '18

I just spent a few minutes staring at a bug caused by a missing comma -- I got a mysterious argument count error because instead of foo('a', 'b') I had written foo('a' 'b'). This is a fairly common mistake, and IIRC at Google we even had a lint rule against this (there was also a Python dialect used for some specific purpose where this was explicitly forbidden). Now, with modern compiler technology, we can (and in fact do) evaluate compile-time string literal concatenation with the '+' operator, so there's really no reason to support 'a' 'b' any more. (The reason was always rather flimsy; I copied it from C but the reason why it's needed there doesn't really apply to Python, as it is mostly useful inside macros.) Would it be reasonable to start deprecating this and eventually remove it from the language? -- --Guido van Rossum (python.org/~guido)

51 165

including psutil in the standard library?
by Stefano Borini 11 Nov '14

11 Nov '14

I am wondering if it would be possible to include psutil (https://pypi.python.org/pypi/psutil ) in the standard library, and if not, what would be needed. I am not a developer of it, but I am using psutil at work with good success. it provides a good deal of services for querying and managing processes in a cross platform way. Any thoughts?

12 15

Negative limit for traceback.*
by Thomas Allen 11 Oct '14

11 Oct '14

I'd like to propose adding the ability to extract last n stack trace entries from a traceback using functions from traceback module. Simply put, passing limit=-n would make functions to return (or print or yield) last abs(n) entries. No-brainer implementation for extract_tb: extracted = list(_extract_tb_iter(tb, limit=(limit, None)[limit < 0])) if limit is not None and limit < 0: return extracted[limit:] return extracted The motivation: http://stackoverflow.com/q/25472412/2301450

3 3

Better integration of multiprocessing with asyncio
by Dan O'Reilly 08 Oct '14

08 Oct '14

I think it would be helpful for folks using the asyncio module to be able to make non-blocking calls to objects in the multiprocessing module more easily. While some use-cases for using multiprocessing can be replaced with ProcessPoolExecutor/run_in_executor, there are others that cannot; more advanced usages of multiprocessing.Pool aren't supported by ProcessPoolExecutor (initializer/initargs, contexts, etc.), and other multiprocessing classes like Lock and Queue have blocking methods that could be made into coroutines. Consider this (extremely contrived, but use your imagination) example of a asyncio-friendly Queue: import asyncio import time def do_proc_work(q, val, val2): time.sleep(3) # Imagine this is some expensive CPU work. ok = val + val2 print("Passing {} to parent".format(ok)) q.put(ok) # The Queue can be used with the normal blocking API, too. item = q.get() print("got {} back from parent".format(item)) def do_some_async_io_task(): # Imagine there's some kind of asynchronous I/O # going on here that utilizes asyncio. asyncio.sleep(5) @asyncio.coroutine def do_work(q): loop.run_in_executor(ProcessPoolExecutor(), do_proc_work, q, 1, 2) do_some_async_io_task() item = yield from q.coro_get() # Non-blocking get that won't affect our io_task print("Got {} from worker".format(item)) item = item + 25 yield from q.coro_put(item) if __name__ == "__main__": q = AsyncProcessQueue() # This is our new asyncio-friendly version of multiprocessing.Queue loop = asyncio.get_event_loop() loop.run_until_complete(do_work(q)) I have seen some rumblings about a desire to do this kind of integration on the bug tracker (http://bugs.python.org/issue10037#msg162497 and http://bugs.python.org/issue9248#msg221963) though that discussion is specifically tied to merging the enhancements from the Billiard library into multiprocessing.Pool. Are there still plans to do that? If so, should asyncio integration with multiprocessing be rolled into those plans, or does it make sense to pursue it separately? Even more generally, do people think this kind of integration is a good idea to begin with? I know using asyncio is primarily about *avoiding* the headaches of concurrent threads/processes, but there are always going to be cases where CPU-intensive work is going to be required in a primarily I/O-bound application. The easier it is to for developers to handle those use-cases, the better, IMO. Note that the same sort of integration could be done with the threading module, though I think there's a fairly limited use-case for that; most times you'd want to use threads over processes, you could probably just use non-blocking I/O instead. Thanks, Dan

4 10

Python 2's re module should take longs
by Ryan Gonzalez 01 Oct '14

01 Oct '14

This works: re.search('(abc)', 'abc').group(1) but this doesn't: re.search('(abc)', 'abc').group(1L) The latter raises "IndexError: no such group". Shouldn't that technically work? -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/

9 11

Implicit submodule imports
by Thomas Gläßle 30 Sep '14

30 Sep '14

Hey folks, What do you think about making it easier to use packages by automatically importing submodules on attribute access. Consider this example: >>> import matplotlib >>> figure = matplotlib.figure.Figure() AttributeError: 'module' object has no attribute 'figure' For the newcomer (like me some months ago) it's not obvious that the solution is to import matplotlib.figure. Worse even: it may sometimes/later on work, if the submodule has been imported from another place. How, I'd like it to behave instead (in pseudo code, since `package` is not a python class right now): class package: def __getattr__(self, name): try: return self.__dict__[name] except KeyError: # either try to import `name` or raise a nicer error message The automatic import feature could also play nicely when porting a package with submodules to or from a simple module with namespaces (as suggested in [1]), making this transition seemless to any user. I'm not sure about potential problems from auto-importing. I currently see the following issues: - harmless looking attribute access can lead to significant code execution including side effects. On the other hand, that could always be the case. - you can't use attribute access anymore to test whether a submodule is imported (must use sys.modules instead, I guess) In principle one can already make this feature happen today, by replacing the object in sys.modules - which is kind of ugly and has probably more flaws. This would also be made easier if there were a module.__getattr__ ([2]) or "metaclass" like feature for modules (which would be just a class then, I guess). Sorry, if this has come up before and I missed it. Anyhow, just interested if anyone else considers this a nice feature. Best regards, Thomas [1] https://mail.python.org/pipermail/python-ideas/2014-September/029341.html [2] https://mail.python.org/pipermail/python-ideas/2012-April/014957.html

19 58

`numbers.Natural`
by Ram Rachum 28 Sep '14

28 Sep '14

I wish the `numbers` module would include a `Natural` class that would simply check whether the number is integral and positive.

10 24

use gmtime(0) epoch in functions that use mktime()
by Akira Li 25 Sep '14

25 Sep '14

Python uses "seconds since the epoch" term to describe time.time() return value. POSIX term is "seconds since the Epoch" (notice the capitalization) where Epoch is 1970-01-01 00:00:00+00:00. C99 term is "calendar time" -- the encoding of the calendar time returned by the time() function is unspecified. Python documentation defines `epoch` as: The :dfn:`epoch` is the point where the time starts. On January 1st of that year, at 0 hours, the "time since the epoch" is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at ``gmtime(0)``. time module documentation specifies calendar.timegm() as the inverse of time.gmtime() while timegm() uses the fixed 1970 Epoch instead of gmtime(0) epoch. datetime.astimezone() (local_timezone()) passes Unix timestamp [1970] to time.localtime() that may expect timestamp with different epoch [gmtime(0)]. email.util.mktime_tz() uses both mktime() [gmtime(0)] and timegm() [1970]. mailbox.py uses both time.time() [gmtime(0)] and timegm() [1970]. http.cookiejar uses both EPOCH_YEAR=1970 and datetime.utcfromtimestamp() [gmtime(0) epoch] for "seconds since epoch". It seems 1970 Epoch is used for file times on Windows (os.stat()) but os.path.getatime() refers to "seconds since epoch" [gmtime(0) epoch]. date{,time}.{,utc}fromtimestamp(), datetime.timestamp() docs equates "POSIX timestamp" [1970 Epoch] and time.time()'s returned value [gmtime(0) epoch]. datetime.timestamp() is inconsistent if gmtime(0) is not 1970. It uses mktime() for naive datetime objects [gmtime(0) epoch]. But it uses POSIX Epoch for aware datetime objects. Correct me if I'm wrong here. --- Possible fixes: Say in the `epoch` definition that stdlib doesn't support gmtime(0).tm_year != 1970. OR don't use mktime() if 1970 Epoch is used e.g., create an aware datetime object in the local timezone instead and use it to compute the result with 1970 Epoch. OR add *analog* of TZ=UTC time.mktime() and use it in stdlib where necessary. Looking at previous attempts (e.g., [1], [2]) to implement timegm(), the problem seems over-constrained. A different name could be used, to avoid wrong expectations e.g., datetime could use `(aware_datetime_object - gmtime0_epoch) // sec` [1] http://bugs.python.org/issue6280, [2] http://bugs.python.org/issue1667546 OR set EPOCH_YEAR=gmtime(0).tm_year instead of 1970 in calendar.timegm(). It may break backward compatibility if there is a system with non-1970 epoch. Deal on a case-by-case basis with other places where 1970 Epoch is used. And drop "POSIX timestamp" [1970 Epoch] and use "seconds since the epoch" [gmtime(0) epoch] in the datetime documentation. Change internal EPOCH year accordingly. What is Python-ideas opinion about it? -- Akira

6 9

"continue with" for dynamic iterable injection
by Cathal Garvey 25 Sep '14

25 Sep '14

Hello all, First time post, so go gentle. :) During a twitter conversation with @simeonvisser, an idea emerged that he suggested I share here. The conversation began with me complaining that I'd like a third mode of explicit flow control in Python for-loops; the ability to repeat a loop iteration in whole. The reason for this was that I was parsing data where a datapoint indicated the end of a preceding sub-group, so the datapoint was both a data structure indicator *and* data in its own right. So I'd like to have iterated over the line once, branching into the flow control management part of an if/else, and then again to branch into the data management part of the same if/else. Yes, this is unnecessary and just a convenience for parsing that I'd like to see. During the discussion though, a much more versatile solution presented itself: repurposing the `continue` keyword to `continue with`, similarly to the repurposing of `yield` with `yield from`. This would avoid keyword bloat, but it would be explicit and intuitive to use, and would allow a pretty interesting extension of iteration with the for-loop. The idea is that `continue with` would allow injection of any datatype or variable, which becomes the next iterated item. So, saying `continue with 5` means that the next *x* in a loop structured as `for x in..` would be 5. This would satisfy my original, niche-y desire to re-iterate over something, but would also more broadly allow dynamic injection of *any* value into a for-loop iteration. As an extension to the language, it would present new and exciting ways to iterate infinitely by accident. It would also present new and exciting ways for people to trip up on mutable data; one way to misuse this is to iterate over data, modifying the data, then iterating over it again. The intention, rather, is that the repeated iteration allows re-iteration over unaltered data in response to a mid-iteration change in state (i.e., in my case, parsing a token, changing parser state, and then parsing the token again because it also carries informational content). However, bad data hygiene has always been part of Python, because it's a natural consequence of the pan-mutability that makes it such a great language. So, given that the same practices that an experienced Python dev learns to use would apply in this case, I don't think it adds anything that an experienced dev would trip over. As a language extension, I've never seen something like "continue with" in another language. You can mimic it with recursive functions and `cons`-ing the injection, but as a flow-control system for an imperative language, nope..and Python doesn't encourage or facilitate recursion anyway (no TCE). I'd love thoughts on this. It's unnecessary; but then, once something's declared turing complete you can accuse any additional feature of being unnecessary. I feel, more to the point, that it's in keeping with the Python philosophy and would add a novel twist to the language not seen elsewhere. best, Cathal -- Twitter: @onetruecathal, @formabiolabs Phone: +353876363185 Blog: http://indiebiotech.com miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM

6 8

Idea: Named code blocks / inline module declarations
by Tennessee Leeuwenburg 25 Sep '14

25 Sep '14

I would like to be able to use named sections to organise my code, much an inline submodules, bit without using classes or functions to organise them. I would use this if I had a group of related functions which were not written in an object-oriented-style, possibly due to not needing any shared state. Rather than break these out into a new file, I would like to just be able to use internal structure to declare the relationship. I've used the keyword 'block' to indicate the start of a named block. For example, block signin: def handle_new_user(): do_it() def handle_existing_user(): do_it() while True: try: signin.handle_existing_user(): except: signin.handle_new_user() do_other_stuff() At the moment, I would have to either break out into more files, or somewhat clumsily co-opt things like functions or staticmethods. I think that supporting named blocks or inline module declarations would really help me organise some of my code much better. It could also provide a more seamless way to decide to break out into a new file. Once a named block got big enough, I could easily create a new file and import those functions into the same namespace. I hope this makes sense and that I'm not overlooking anything obvious. Cheers, -Tennessee

9 11

proposal: os.path.joinuser()
by Tarek Ziadé 24 Sep '14

24 Sep '14

Hello I realize I am using a lot this pattern: >>> os.path.join(os.path.expanduser('~'), 'something', 'here') '/Users/tarek/something/here' It's quite complicated, and not really intuitive. What about adding in os.path a "joinuser()" equivalent function, e.g. >>> os.path.joinuser('something', here') '/Users/tarek/something/here' With an optional "user" argument when you want to specify the ~user >>> os.path.joinuser('something', here', user="foo") '/Users/bill/something/here' That would be, in my opinion, much more explicit & readable. If there's already something like that in the stdlib, forgive my ignorance! Cheers Tarek

7 13

Putting `blist` into collections module
by Ram Rachum 22 Sep '14

22 Sep '14

Hi everybody, In 2007, this PEP was created that suggested integrating Daniel Stutzbach's blist into Python: http://legacy.python.org/dev/peps/pep-3128/ The PEP was rejected, but Raymond Hettinger made a note that "after a few months, I intend to poll comp.lang.python for BList success stories. If they exist, then I have no problem with inclusion in the collections module." I realize that way more than a few months have passed, but I'd still like to give my input. I really wish that `blist` would be made available in the `collections` module. I'm working on an open-source project right now that needs to use it and I'm really reluctant to include `blist` as a dependency, given that it would basically mean my package wouldn't be pip-installable on Windows machines. Thanks, Ram.

13 22

Fwd: Putting `blist` into collections module
by Nick Coghlan 22 Sep '14

22 Sep '14

And forwarding to the list because Google Groups is still broken as a mailing list mirror. ---------- Forwarded message ---------- From: Nick Coghlan <ncoghlan(a)gmail.com> Date: 21 September 2014 22:26 Subject: Re: [Python-ideas] Putting `blist` into collections module To: Ram Rachum <ram.rachum(a)gmail.com> Cc: "python-ideas(a)googlegroups.com" <python-ideas(a)googlegroups.com> On 21 September 2014 01:18, Ram Rachum <ram.rachum(a)gmail.com> wrote: > I realize that way more than a few months have passed, but I'd still like to > give my input. I really wish that `blist` would be made available in the > `collections` module. I'm working on an open-source project right now that > needs to use it and I'm really reluctant to include `blist` as a dependency, > given that it would basically mean my package wouldn't be pip-installable on > Windows machines. I didn't originally notice that your main concern was with installation on Windows. For that particular concern, I suggest filing an RFE with the blist project, requesting that they publish wheel files for Windows. Offering to help in building them would likely be appreciated, as many projects may not have access to systems that allow them to build Windows binaries (alternatively, if Daniel approached the PSF for assistance in providing Windows binaries, we can generally provide some help in situations like that, especially to folks that have already been accepted as CPython core developers). "Compilation can be hard on Windows" is no longer a factor that is taken into account when deciding whether or not to add things to the standard library - we're taking other steps to deal with that problem as part of the packaging toolchain, and one of the key ones is allowing publication of binary wheels for Mac OS X and Windows on PyPI. (Further down the track, we'd like to offer a build farm as part of PyPI, but we're still a *long* way from reaching a point where such a proposal can be seriously considered) Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

7 12

Building wheels on AppVeyor (was: Putting `blist` into collections module)
by Paul Moore 22 Sep '14

22 Sep '14

On 21 September 2014 23:18, Paul Moore <p.f.moore(a)gmail.com> wrote: > Also, I've yet to work out how to get AppVeyor to do 32-bit and 64-bit > builds. But I'm looking into it... AppVeyor has Python 2.7, 3.3 and 3.4 32-bit, and Visual Studio Express, installed on builders by default. I've put in a request to get the 64-bit versions of Python installed as well, and the details added to the "List of installed software" page (http://www.appveyor.com/docs/installed-software). They seem very responsive to such requests. Paul

1 0

keyword for introducing generators
by Neil Girdhar 20 Sep '14

20 Sep '14

I'm sure this has been suggested before, but I just spent two days trying to figure out why a method wasn't being called only to find that I'd accidentally pasted a yield into the function. What is the argument against a different keyword for introducing generator functions/methods? If it's backward compatibility, then my suggestion to have a from __future__ and then make it real in Python 4. Neil

5 6

Re: [Python-ideas] What math.floor(inf) should return? Was: Make `float('inf') //1 == float('inf')`
by Alexander Belopolsky 19 Sep '14

19 Sep '14

On Thu, Sep 18, 2014 at 6:57 PM, Case Van Horsen <casevh(a)gmail.com> wrote: > > > I don't think there is any dispute over what math.floor(inf) should return. > > POSIX, C99, IEEE and probably many other standards agree that inf should be > > returned as long as the resulting type can represent it. > > I dispute that there is no dispute over what math.floor(inf) should return. ;-) > I am changing the subject so that we don't mix making new decisions with a critique and defense of the decisions that were made in the past. I wrote: "inf should be returned as long as the resulting type can represent it". This is the part that I still believe is not disputed. No one has suggested that math.floor(inf) should return nan, for example. > All the standards specify a result type can represent +-Inf and +-0. A > standards compliant version should return +-Inf and +-0. lrint() and llrint() > are defined to return long or long long, respectively. It would be fine if > they raised an exception. The current math.floor() actually behaves more > like llrint() than floor(). > POSIX does not preclude raising an exception: "If the correct value would cause overflow, a range error shall occur" ( http://pubs.opengroup.org/onlinepubs/009695399/functions/floor.html). > > I accept that having math.floor() return an integer (and raise an exception > for +-Inf) may be useful in many cases but it is different from the standard. > Other floating-point libraries still return a floating-point value. The standards are influenced by the limitation inherent in many languages where ints have finite range and cannot represent floor() of many finite floating point values. Python does not have this limitation. (Granted - PEP 3141 could do a better job explaining why floor, ceil, round, //, etc. should return Integer rather than Real.)

4 5

Introduce `start=1` argument to `math.factorial`
by Ram Rachum 19 Sep '14

19 Sep '14

I suggest introducing a `start=1` argument to `math.factorial`, so the result would be (the C-optimized version of) `product(range(start, x+1), start=1)`. This'll be useful for combinatorical calculations.

11 13

Fwd: Make `float('inf') //1 == float('inf')`
by Ian Cordasco 19 Sep '14

19 Sep '14

---------- Forwarded message ---------- From: Ian Cordasco <graffatcolmingov(a)gmail.com> Date: Wed, Sep 17, 2014 at 4:51 PM Subject: Re: [Python-ideas] Make `float('inf') //1 == float('inf')` To: Ram Rachum <ram.rachum(a)gmail.com> Cc: "python-ideas(a)googlegroups.com" <python-ideas(a)googlegroups.com> On Wed, Sep 17, 2014 at 11:42 AM, Ram Rachum <ram.rachum(a)gmail.com> wrote: > Please see this discussion on python-list: > > https://groups.google.com/forum/#!topic/comp.lang.python/maDZoc-n4bA > > Currently `float('inf') //1` is equal to NaN. I think that this is really > weird. If I understand correctly it's to maintain the invariant `div*y + mod > == x`. The question is, do we really care more about maintaining this > invariant rather than providing a mathematically reasonable value for floor > division? Actually there are 2 things here: 1. Mathematically speaking, infinity is a real number and modulo arithmetic is algebraically not defined for it. So the "mathematically reasonable value" is NaN. Is it intuitive for someone who hasn't studied abstract algebra? Probably not. Is it functional for the scientific python community? Almost certainly although I won't pretend to speak on their behalf 2. Changing this behaviour is not something I think we should do in a minor version of 3.4 or in 3.5 (or really 3.x).

10 22

The stdlib++ user experience (Was: Introduce `start=1` argument to `math.factorial`)
by Paul Moore 19 Sep '14

19 Sep '14

On 18 September 2014 18:01, Andrew Barnert <abarnert(a)yahoo.com.dmarc.invalid> wrote: > On Sep 17, 2014, at 23:15, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > >> However, now that CPython ships with pip by default, we may want to >> consider providing more explicit pointers to such "If you want more >> advanced functionality than the standard library provides" libraries. > > I love this idea, but there's one big potential problem, and one smaller one. > > Many of the most popular and useful packages require C extensions. In itself, > that doesn't have to be a problem; if you provide wheels for the official 3.4+ Win32, > Win64, and Mac64 CPython builds, it can still be as simple as `pip install spam` > for most users, including the ones with the least ability to figure it out for themselves. OK, the key thing to look at here is the user experience for someone who has Python installed, and has a job to do, but needs to branch out into external packages because the stdlib doesn't provide enough functionality. To make this example concrete, I'll focus on a specific use case, which I believe is relatively common, although I can't back this up with hard data. Assume: * A user who is comfortable with Python, or with scripting languages in general * No licensing or connectivity issues to worry about * An existing manual process that the user wants to automate In my line of work, this constitutes the vast bulk of Python use - informal, simple automation scripts. So I'm writing this script, and I discover I need to do something that the stdlib doesn't cover, but I feel like it should be available "out there", and it's sufficiently fiddly that I'd prefer not to write it myself. Examples I've come across in the past: * A console progress bar * Scraping some data off a web page * Writing data into an Excel spreadsheet with formatting * Querying an Oracle database Every time an issue like this comes up, I know that I'm looking to do "pip install XXX". It's working out what XXX is that's the problem. So I go and ask Google. A quick check on the progress bar case gets me to a StackOverflow article that offers me a lot of "write it yourself" solutions, and pointers to a couple of libraries. Further down there are a few pointers to python-progressbar, which was mentioned in the StackOverflow article, which in turn leads me to the PyPI page for it. The latest version (2.3-dev) is not hosted on PyPI, so I hit all the fun of --allow-external. Ironically, "pip install tqdm" gives me what I want instantly. But it never came up via Google. The rest of the cases are similar, lots of Google searching, often combined with evaluating multiple options, followed by more or less pain installing the software. Things that aren't Python 3 or Windows compatible suck me into the "shall I patch it and submit a PR" minefield. For the last case (an Oracle driver), where I need a C extension and access to external libraries, ironically it's pretty easy. There's no real competition to cx_Oracle, and the PyPI page has what I need, although they ship wininst exes rather than wheels, which means I need to do a download then a wheel convert then a pip install, so it's not ideal, but doable. >From this example, I'd like to see the following improvements to the process: 1. Somewhere I can go to find useful modules, that's better than Google. 2. Someone else choosing the "best option" - I don't want to evaluate 3 different progressbar modules, I just want to write "57% complete" and a few dots! 3. C extensions aren't a huge problem to me on Windows, although I'm looking forward to the day when everyone distributes wheels (wheel convert is good enough for now though). [1] 4. Much more community pressure for projects to host their code on PyPI. Some projects have genuine issues with hosting on PyPI, and there are changes being looked at to support them, but for most projects it seems to just be history and inertia. [1] A Linux/OS X user might have more more issues with C extensions. Maybe this can't be solved in any meaningful sense, and maybe it's not something the "Python project" should take responsibility for, but without any doubt, it's the single most significant improvement that could be made to my experience with PyPI. Paul. PS I should also note that even in its current state, PyPI is streets ahead of the 3rd party module story I've experienced for any other language - C/C++, Lua, Powershell, and Java are all far worse. Perl/CPAN may be as good or better, it's so long since I used Perl that I don't really know these days.

10 24

Stop displaying elements of bytes objects as printable ASCII characters in CPython 3
by Chris Lasher 19 Sep '14

19 Sep '14

Why did the CPython core developers decide to force the display of ASCII characters in the printable representation of bytes objects in CPython 3? For example >>> import struct >>> # In go bytes for four floats: >>> my_packed_bytes = struct.pack('ffff', 3.544294848931151e-12, 1.853266900760489e+25, 1.6215185358725202e-19, 0.9742483496665955) >>> # And out comes a speciously human-readable representation of those bytes >>> my_packed_bytes b'Why, Guido? Why?' >>> >>> # But it's just an illusion; it's truly bytes underneath! >>> a_reasonable_representation = bytes((0x57, 0x68, 0x79, 0x2c, 0x20, 0x47, 0x75, 0x69, 0x64, 0x6f, 0x3f, 0x20, 0x57, 0x68, 0x79, 0x3f)) >>> my_packed_bytes == a_reasonable_reperesentation True >>> >>> this_also_seems_reasonable = b'\x57\x68\x79\x2c\x20\x47\x75\x69\x64\x6f\x3f\x20\x57\x68\x79\x3f' >>> my_packed_bytes == this_also_seems_reasonable True I understand bytes literals were brought in to Python 3 to aid the transition from Python 2 to Python 3 [1], but this did not imply that `repr()` on a bytes object ought to display bytes mapping to ASCII characters as ASCII characters. I have not yet found a PEP describing why this decision was made. I am now seeking to put forth a PEP to change printable representation of bytes to be simple, consistent, and easy to understand. The current behavior printing of elements of bytes with a mapping to printable ASCII characters as those characters seems to violate multiple tenants of the Zen of Python [2] * "Explicit is better than implicit." This display happens without the user's explicit request. * "Simple is better than complex." The printable representation of bytes is complex, surprising, and unintuitive: Elements of bytes shall be displayed as their hexadecimal value, unless such a value maps to a printable ASCII character, in which case, the character shall be displayed instead of the hexadecimal value. The underlying values of each element, however, are always integers. The printable representation of an element of a byte will always be an integer representation. The simple thing is to show the hex value for every byte, unconditionally. * "Special cases aren't special enough to break the rules." Implicit decoding of bytes to ASCII characters comes in handy only some of the time. * "In the face of ambiguity, refuse the temptation to guess." Python is guessing that I want to see some bytes as ASCII characters. In the example above, though, what I gave Python was bytes from four floating point numbers. * "There should be one-- and preferably only one --obvious way to do it." `bytes.decode('ascii', errors='backslashreplace')` already provides users the means to display ASCII characters among bytes, as a real string. To be fair, there are two tenants of the Zen of Python that support the implicit display of ASCII characters in bytes: * "Readability counts." * "Although practicality beats purity." In counterargument, though, I would say that the extra readability and practicality are only served boosted in special cases (which are not special enough). Much ado was (and continues to be) raised over Python 3 enforcing distinction between (Unicode) strings and bytes. A lot of this resentment comes from Python programmers who do not yet appreciate the difference between bytes and text†, or from those who remain apathetic and prefer Python 2's it-works-'til-it-doesn't strings. This implicit displaying of ASCII characters in bytes ends up conflating the two data types even deeper in novice programmers' minds. In the example above, `my_packed_bytes` looks like a string. It reads like a string. But it is not a string. The ASCII characters are a lie, as evidenced when trying to access elements of a bytes instance: >>> b'Why, Guido? Why?'[0] 87 >>> # Oh, perhaps you were expecting b'W'? I find this behavior harmful to Python 3 advocacy, and novices and those accustomed to Python 2 find this yet another deterrent in the way of Python 3 adoption. I would like to gauge the feasibility of a PEP to change the printable representation of bytes in CPython 3 to display all elements by their hexadecimal values, and only by their hexadecimal values. Thanks, Chris L. † I write this as someone who, himself, didn't appreciate nor understand the difference between bytes, strings, and Unicode. I have Ned Batchelder [3] to thank and his illuminating "Pragmatic Unicode" presentation [4] for getting me on the right path. [1]: http://legacy.python.org/dev/peps/pep-3112/#rationale [2]: http://legacy.python.org/dev/peps/pep-0020/ [3]: http://nedbatchelder.com/ [4]: http://nedbatchelder.com/text/unipain.html

20 67

Make `float('inf') //1 == float('inf')`
by Ram Rachum 17 Sep '14

17 Sep '14

Please see this discussion on python-list: https://groups.google.com/forum/#!topic/comp.lang.python/maDZoc-n4bA Currently `float('inf') //1` is equal to NaN. I think that this is really weird. If I understand correctly it's to maintain the invariant `div*y + mod == x`. The question is, do we really care more about maintaining this invariant rather than providing a mathematically reasonable value for floor division? Thanks, Ram.

1 0

Re: [Python-ideas] float comparison in doctes
by Kevin Davies 17 Sep '14

17 Sep '14

It seems that this didn't reach the list directly (see https://mail.python.org/pipermail/python-ideas/2014-August/028956.html), so I'm resending: Erik Bray (the author of the +FLOAT_CMP extension in Astropy), Bruce Leban, and I had a short off-thread email discussion. Here are the points: - [Bruce]: ALMOST_EQUAL is the best flag name. - [Erik]: If there's agreement on this, Erik will develop a patch as soon as he can. - [Erik]: There's no way to adjust the tolerance because there seems to be no easy way to parameterize doctest flags. Ideas are welcome. - [Erik]: Still, "This +FLOAT_CMP flag enabled removing tons of ellipses from the test outputs [of Astropy], and restoring the full outputs which certainly read better in the docs... For more complete unit tests of course we use assert_almost_equal type functions. - [Erik]: This PR is a better link than the one I gave: https://github.com/astropy/astropy/pull/2087 - [Erik]: Most of the code is from the SymPy project with improvements. Erik had started on a similar feature when he found that their implementation was further developed. Kevin

5 4

Fwd: Yielding from the command line
by Martin Teichmann 17 Sep '14

17 Sep '14

Hi Andrew, Hi List, > [ some discussion about calling yield from from the command line skipped ] > > I would love to see this. I'm not sure if I'd love it in practice or not, but until > someone implements it and I can play with it I'm not sure how I'd become sure. > > So... You just volunteered, right? Go build it and put it on PyPI, I want it and > I'll be your best friend forever and ever no takebacks if you do it. :) Well, so I did, I wrote an IPython extension that does it and put it up on https://github.com/tecki/ipython-yf It's more a mock-up of how it should actually look like, but it is a functioning mock-up. So now you can write on the command line stuff like: >>> %load_ext yf >>> from asyncio import sleep, async >>> def f(): ... yield from sleep(3) ... print("done") >>> yield from f() #[wait three seconds] done >>> async(f()) >>> #[wait three seconds, or type other commands] done So as you see, the event loop runs while you are typing commands, and while they are executed. Greetings Martin

1 0

Special-case 3.x 'print x' SyntaxError
by Terry Reedy 15 Sep '14

15 Sep '14

One of the problems with new Python programmers using 3.x is that they first read 'print x' in 2.x based material, try 'print x' in 3.x, get "SyntaxError: invalid syntax" (note the uninformative redundant message), and go "huh?" or worse. Would it be possible to add detect this particular error and print a more useful message? I am thinking of something of something like SyntaxError: calling the 'print' function requires ()s, as in "print(x)" or maybe SyntaxError: did you mean "print(...)"? I was 'inspired' by a recent SO question https://stackoverflow.com/questions/24273599/idle-gui-is-unable-to-give-out… which was closed as a duplicate of the 2009 question https://stackoverflow.com/questions/826948/syntax-error-on-print-with-pytho… I imagine that there have been other duplicates. The same question (and answer) has appeared multiple times on python-list also. If we do this, I am sure someone will ask why we do not automatically 'fix' the error. One answer would be that the closing ) is needed to determine the intended end of the call. A longer version would be that if we insert (, we are just guessing that the insertion is correct and we still would not know, without guessing, where to put the ). -- Terry Jan Reedy

5 8

Bring namedtuple's __str__ and __repr__ behavior to regular classes
by John Wong 14 Sep '14

14 Sep '14

Hi, >>> from collections import namedtuple >>> A = namedtuple("A", ["foo"]) >>> print(A(foo=1)) A(foo=1) >>> str(A(foo=1)) 'A(foo=1)' >>> repr(A(foo=1)) 'A(foo=1)' The relevant code is https://hg.python.org/cpython/file/2.7/Lib/collections.py#l356 I propose we bring the behavior to regular classes. Instead of >>> class A(object): ... def __init__(self): ... self.foo = 1 ... >>> repr(A()) '<__main__.A object at 0x1090c0990>' We should be able to see the current values to the display. >>> repr(A()) 'A(foo=1)' Reasons: 1. Helps debugging (via pdb, print and logging). We no longer have to do A().foo to find out. 2. I don't know how often people actually rely on repr(A()) or str(A()) and parse the string so breaking compatibility is, probably low. 3. People who wish to define their own repr and str is welcome. Django model for example has a more explicit representation by default (although many Django users do redefine the representation on their own). datetime.datetime by default, as a library, is also explicit. So customization will come. The main challenge: Where and how do we actually look for what attributes are relevant? namedtuple can do it because it has __slot__ and we know in advance how many attributes are set. In regular class, we deal with dynamic attribute setting, single and inheritances. I don't have an answer for this simply because I lack of experience. We can certainly start with the attributes set in the main instance and one level up in the inheritance chain. Other issues: 1. What if there are too many attributes? I don't think the number will explode beyond 30. I choose this number out of thin air. I can do more research on this. It doesn't actually hurt to see everything. If you do have a class with so many attribute (whether you have this many to begin with, or because you allow aritbary numbers of attributes to be set -- for example, a document from a collection in NoSQL like MongoDB), that's still very useful. We could limit by default up to how many. 2. How do we order them? We can order them in unsorted or sorted order. I prefer the sorted order.

4 4

Re: [Python-ideas] Yielding from the command line
by Martin Teichmann 14 Sep '14

14 Sep '14

Hi everyone, since there seemed to be some interest in my idea of a asyncio-enabled command line, I just sat down and wrote it. I submitted the parts that would need to go into CPython as Issue 22412 to the Python bug tracker. I added a simple command line interpreter, based on code.InteractiveConsole, which will allow for uses like >>> from asyncio import sleep >>> yield from sleep(10) The following code is mostly a copy of InteractiveConsole, with the appropriate yield froms stuck in (and comments removed. Yeah!) Greeting Martin Code follows: from asyncio import get_event_loop, coroutine, input from code import InteractiveConsole import sys class AsyncConsole(InteractiveConsole): def __init__(self, locals=None, filename="<console>"): super().__init__(locals, filename) self.compile.compiler.flags |= 0x1000 @coroutine def runsource(self, source, filename="<input>", symbol="single"): try: code = self.compile(source, filename, symbol) except (OverflowError, SyntaxError, ValueError): self.showsyntaxerror(filename) return False if code is None: return True yield from self.runcode(code) return False @coroutine def runcode(self, code): try: yield from eval(code, self.locals) except SystemExit: raise except: self.showtraceback() @coroutine def push(self, line): self.buffer.append(line) source = "\n".join(self.buffer) more = yield from self.runsource(source, self.filename) if not more: self.resetbuffer() return more @coroutine def interact(self, banner=None): try: sys.ps1 except AttributeError: sys.ps1 = ">>> " try: sys.ps2 except AttributeError: sys.ps2 = "... " cprt = 'Type "help", "copyright", "credits" or "license" for more information.' if banner is None: self.write("Python %s on %s\n%s\n(%s)\n" % (sys.version, sys.platform, cprt, self.__class__.__name__)) elif banner: self.write("%s\n" % str(banner)) more = 0 while 1: try: if more: prompt = sys.ps2 else: prompt = sys.ps1 try: line = yield from input(prompt) except EOFError: self.write("\n") break else: more = yield from self.push(line) except KeyboardInterrupt: self.write("\nKeyboardInterrupt\n") self.resetbuffer() more = 0 except SystemExit: return if __name__ == "__main__": console = AsyncConsole() get_event_loop().run_until_complete(console.interact())

1 0

Re: [Python-ideas] Yielding from the command line
by Martin Teichmann 13 Sep '14

13 Sep '14

Hi Terry, Hi List, > I presume full behavior requires the call to root.mainloop(). This has two > problems for continued interaction. First, the call blocks until the window > is closed, making further entry impossible through normal means. If that > were solved with a 'noblock' option, there would still be the problem of > getting shell input to a callback that could, on demand, execute to code to > modify the tk app. The solution would have to be different for the console > interpreter, there tkinter is running in the same process and Idle, where > tkinter is running is a separate process. You just gave a good reasoning for the advantages of asyncio. Because once we have an asyncio-aware version of tkinter - and an asyncio-aware command line, this is what I am proposing - all the problems you just described disappear. So, I would call that a good use case for my idea. A tkinter-aware commandline would then just look like: set_event_loop(TKInterEventLoop()) async(commandline()) # i.e. the coroutine defined in my last post get_event_loop().run_forever() # this calls root.mainloop() Greetings Martin

8 9

Yielding from the command line
by Martin Teichmann 11 Sep '14

11 Sep '14

Hi List, I'm currently trying to convince my company that asyncio is a great thing. After a lot of critique, the newest thing is, people complain: I cannot test my code on the command line! And indeed they are right, a simple a = yield from some_coroutine() is not possible on the command line, and doesn't make sense. Wait a minute, really? Well, it could make sense, in an asyncio-based command line. I am thinking about a python interpreter whose internal loop is something like @coroutine def commandline(): while True: cmd = yield from input_async() code = compile(cmd, "<stdin>", "generator") yield from exec(code) A new compile mode would allow to directly, always create a generator, and exec should be certainly be able to handle this. I think this would not only make people happy that want to test code on the command line, but also all those people developing command line-GUI combinations (IPython comes to mind), which have to keep several event loops in sync. Greetings Martin

4 4

Abstract metaclasses?
by Erik Bray 10 Sep '14

10 Sep '14

Hi all, I recently ran across an interesting (mis?)-feature at least in CPython that I couldn't find any specific justification for or against. The issue is that abstract *types*, while technically possible, don't behave as abstract classes. To exemplify, say I wanted to create a metaclass which itself has ABCMeta as a metaclass, and which has some abstract classmethod defined: >>> import abc >>> class Meta(type, metaclass=abc.ABCMeta): ... @abc.abstractmethod ... def foo(cls): pass ... Now for all intents and purposes Meta *is* an abstract type: >>> import inspect >>> inspect.isabstract(Meta) True >>> Meta.__abstractmethods__ frozenset({'foo'}) However, nothing prevents Meta from being used as a metaclass for another class, despite it being "abstract": >>> class A(metaclass=Meta): pass ... >>> A <class '__main__.A'> This is simply because the check for the Py_TYPFLAGS_IS_ABSTRACT flag is implemented in object_new, which is overridden by type_new for type subclasses. type_new does not perform this check. I'm perfectly fine if this is dismissed as too abstract or too academic to be useful, but I will mention that this came up in a real use case. The use case is in a hierarchy of metaclasses involved in a syntactic-sugary class factory framework involving creation of new classes via operators. So I just wonder if this is a bug that should be fixed, or at the very least a feature request. The IS_ABSTRACT flag check is cheap and easy to add to type_new, in principle. In the meantime a workaround, which doesn't seem too terrible, is simply to define something I called AbstractableType: >>> class AbstractableType(type): ... def __new__(mcls, name, bases, members): ... if inspect.isabstract(mcls): ... raise TypeError( ... "Can't instantiate abstract type {0} with " ... "abstract methods {1}".format( ... mcls.__name__, ', '.join(sorted(mcls.__abstractmethods__)))) ... return super(AbstractableType, mcls).__new__(mcls, name, bases, members) ... Now create an abstract metaclass with (meta-)metaclass abc.ABCMeta: >>> class AbstractMeta(AbstractableType, metaclass=abc.ABCMeta): ... @abc.abstractmethod ... def foo(cls): pass ... Creating a class with metaclass AbstractMeta fails as it should: >>> class A(metaclass=AbstractMeta): pass ... Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 7, in __new__ TypeError: Can't instantiate abstract type AbstractMeta with abstract methods foo However, AbstractMeta can be subclassed with a concrete implementation: >>> class ConcreteMeta(AbstractMeta): ... def foo(cls): print("Concrete method") ... >>> class A(metaclass=ConcreteMeta): pass ... >>> A.foo() Concrete method Thanks, Erik

2 5

Proposal: New syntax for OrderedDict, maybe built-in
by Norman Hooper 10 Sep '14

10 Sep '14

Hi there, I'd like to propose that the OrderedDict get a more readable syntax, the way the syntax for set changed from set(['spam', 'ham', 'eggs']) to {'spam', 'ham', 'eggs'} when it became a built-in type in Python 2.4. The way set is unordered like the keys of a dict, similarly list is ordered like the keys of an OrderedDict. In that sense, what {'ham', 'eggs'} is to {'ham': 'spam', 'eggs': 'spam'}, so ['ham', 'eggs'] is to ... my proposal of a cleaner OrderedDict syntax ... ['ham': 'spam', 'eggs': 'spam']. So a "dict" is like a "set" (hence curly braces) of key-value pairs. And an "OrderedDict" is like a "list" (hence square braces) of key-value pairs. (Of course, I am ignoring how lists can have duplicate items. An ordered set would carry the analogy further, but it wouldn't help illustrate my syntax proposal.) I find "['ham': 'spam', 'eggs': 'spam']"" unambiguous, and more readable than "OrderedDict([('ham', 'spam'), ('eggs', 'spam')])". I work with OrderedDict a lot, because JSON represents an OrderedDict and I need to work with JSON a lot. In an attempt to make the OrderedDicts that I work with more readable, I wrote a module to parse a string representation of an OrderedDict that uses my proposed syntax. You can find it here: https://github.com/kaapstorm/listdict With the ubiquity of JSON, it may also be time to promote OrderedDict to a built-in type too. Kind regards, Norman

5 6

Re: [Python-ideas] yield from __setitem__ and __setattr__
by Martin Teichmann 10 Sep '14

10 Sep '14

Hi Guido, Hi List > I think it's too soon to start inventing new syntax to address these; instead, I strongly > recommend changing your APIs to use explicit method calls instead of the special > syntax you so favor. Even __getitem__() returning a Future feels awkward to me > (unless it's clear that the container you have in front of you is a container full of Futures). > [...] > But again I would like to establish asyncio as the de-factor standard for asynchronous work > before trying to tweak the language more I agree that first we need to settle a bit and look how everything works, but hey, this is python-ideas, the list for "discussing speculative language ideas". Limiting all APIs to just use explicit method calls unfortunately leads to a very Java-like language that misses all the cool features of python. And this is not limited only to low-level stuff, but also high level interfaces. Right now I am actually working on a distributed framework, where users which are not professional programmers are supposed to write their own plugins. My boss is constantly bugging me "all that yield from stuff looks complicated, can't you just put it in a function the user calls so they don't see it anymore?" Well, as you know, I cannot. Even in the highest level of abstraction, every function that needs to do I/O has to be yielded from. Imagine the client side of a Big Data service like google earth, what syntax do you prefer, "yield from map.get_section(long1, long2, long_step, lat1, lat2, lat_step)", or simply "yield from map[long1:long2:long_step, lat1:lat2:lat_step]"? Until now, a yield from was just a rather rare case used only on special occasions. But once asyncio becomes more wide spread, it will simply be everywhere. It will be so ubiquitous that I even thought it should not be spelled out anymore at all - every expression evaluating to a coroutine should automatically be yielded from. But that would actually kill the advantange of this construct - the cooperative multitasking we are doing with yield from. The programmer of a piece of code would not know anymore where other tasks step in, so all the problems with race conditions re-appear. Given that it will be used very often in the future, I thought we could even use a special character to represent the yield from, say, a $. Then code like the following would be possible, please don't hate me for the Perl-look: for a, $b, c in some_iterator(): $ob.foo = $calculate(a + b, c) which would be equivalent to for a, _b, c in some_iterator(): b = yield from _b yield from ob.__setattr__("foo", yield from calculate(a + b, c)) But I guess with that I am just way too speculative... Greetings Martin

2 2

yield from __setitem__ and __setattr__
by Martin Teichmann 09 Sep '14

09 Sep '14

Hi list, I am a happy user of yield from, especially while also using asyncio. A great feature is that one can seamlessly convert synchronous code into asynchronous code by adding the appropriate yield froms and coroutine statements at the proper place, including special methods like __getitem__, as in "yield from something[7]". But we cannot yield from the special methods __setattr__ and __setitem__. That is unfortunate, as I am programming a proxy object for something remote over the network, and also __setitem__ might take some time. So I got the idea that yield from might also be used on the left side of an assigment, as in yield from o[3], yield from o.something = "a", "b" which should be equivalent to yield from o.__setitem__(3, "a") yield from o.__setattr__("something", "b") I know that with this proposal I am probably far up on the list of most ugly syntax proposed ever, so maybe someone has a better idea. As a side note: with asyncio I am using yield from a lot, and I think it is a pity that it is so long an clumsy a keyword-couple. Couln't it be shortened? I'm thinking about just using "from", especially in an asyncio context, "from sleep(3)" sounds bad to me, but still better than "yield from sleep(3)". Or maybe we could have an auto-yielder, by just declaring that every expression that evaluates to a coroutine is automatically yielded from, as long as the calling function is a coroutine itself. Greetings Martin

2 1

Have ConfigParser handle sectionless config files by default
by Kernc 08 Sep '14

08 Sep '14

Hi all, I recently opened this bug report [1] stating that ConfigParser not handling configuration files without sections (or those that have options above first section definition) is an issue. ConfigParser* should be able to parse "POSIX" config files (key=value, no sections). I'd like to lobby even for it being the default behavior without requiring a strict=False argument. If interested, please have a look at the bug report for some further arguments. Thanks, [1]: http://bugs.python.org/issue22253 * It's called ConfigParser, not IniParser.

1 0

My apologies
by Norman Hooper 04 Sep '14

04 Sep '14

I completely missed the same proposal made by Anthony Towns in March this year. Kind regards Norman

1 0

Subprocess: Add an encoding argument
by Paul Moore 03 Sep '14

03 Sep '14

At the moment, subprocess offers two options for handlingthe standard IO streams of the child. By default, the streams are binary, or you can set universal_newlines to get text-mode streams with universal newline handling enabled. With universal_newlines, the encoding of the streams is the default value for the environment (whatever locale.getpreferredencoding() returns). However, there can be cases where you want finer control over the encoding to use (for example, if you run Python in a subprocess and set PYTHONIOENCODING). I propose adding an "encoding" parameter to subprocess.Popen (and the various wrapper routines) to allow specifying the actual encoding to use. Obviously, you can simply wrap the binary streams yourself - the main use for this facility would be in the higher level functions like check_output and communicate. Does this seem like a reasonable suggestion? Paul

8 20