Mailman 3 August 2015 - Python-ideas

PEP 501 - i18n with marked strings
by Mike Miller Aug. 22, 2015

Aug. 22, 2015

Hi, I haven't done i18n recently, so bare with me. I'm not sure about bolting this on to "format strings", in that it feels like an orthogonal concept. However, what if we had i18n strings as well, not instead of: i'Hello there, $name {age}.' and that they were complimentary to f'', each handling their different duties: fi'Hello there, $name {age}.' Different syntax would probably be needed for each, is that correct? Since each have different requirements, e.g. Barry's … [View More]

19 50

Re: [Python-ideas] PEP 448
by Balakrishnan B Aug. 22, 2015

Aug. 22, 2015

Re-sending after subscribing. On Fri, Aug 21, 2015 at 9:47 PM, Balakrishnan Balasubramanian <balakrishnan.erode(a)gmail.com> wrote: > I tried out the new python3.5 rc1. I feel there is an inconsistency in > unpacking generalizations. *iterable is considered error but *iterable, > is a tuple. Should we make *iterable a list instead? This will be a > nice shortcut to expand an iterable? > > (p35) [balki@antmin p35]$ python > Python 3.5.0rc1 (default, Aug 21 … [View More]

1 0

Is this group via google groups read only?
by Thomas Güttler Aug. 22, 2015

Aug. 22, 2015

Hi, I wrote a message to this group via google groups yesterday. This message did not arrive here. Now I write as a subscriber to the mailman mailing list. My post is visible via google groups here: https://groups.google.com/forum/#!topic/python-ideas/28DuXfuCYFY Is the google group interface to this group read only? If yes. It is confusing that you can post via google groups. Regards, Thomas PS: this message is about the google groups interface. I write the python question in a … [View More]

6 9

pip list shows "name meta info of the package" which is of no use
by shiva prasanth Aug. 21, 2015

Aug. 21, 2015

i just learned decorators and i'm in a verge of asking why no decorators for objects thanks for helping me understand the concept of decorators. it was very helpful. suppose let us say we installed pyjnius using pip. when i'm trying to import pyjnius it shows >>>import pyjnius >>>`ImportError:` No module named pyjnius pip list does shows that pyjnius but there is no info about how it should be imported. i think we should be adding that functionality so that we dont have to … [View More]

4 4

Re: [Python-ideas] Is this group via google groups read only?
by Thomas Güttler Aug. 21, 2015

Aug. 21, 2015

Am 21.08.2015 um 13:26 schrieb Rustom Mody: > I think you will find (at least I did) that GG will not post if you are not an email-member > Now that you are being able to send via email you should be able to use th GG web-interface Yes, good idea. Up to now I use two different mail adresses. But if they are the same, it should work. Thank you for this hint. Regards, Thomas Güttler

2 1

why is there no decoration for objects
by shiva prasanth Aug. 21, 2015

Aug. 21, 2015

clearly we write decorators for classes and functions and now why not for objects suppose def increment(a): return a+1 a=5 @increment a should modify the value of a to 6 but instead it is giving an error i think we should add decorators for objects also since when you are reviewing the same code @increment is easier to understand than a=a+1

4 3

Learning from the shell in supporting asyncio background calls
by Nick Coghlan Aug. 21, 2015

Aug. 21, 2015

Hi folks, Based on the recent discussions Sven kicked off regarding the complexity of interacting with asyncio from otherwise synchronous code, I came up with an API design that I like inspired by the way background and foreground tasks in the POSIX shell work. My blog post about this design is at http://www.curiousefficiency.org/posts/2015/07/asyncio-background-calls.html, but the essential components are the following two APIs: def run_in_background(target, *, loop=None): """… [View More]Schedules target as a background task Returns the scheduled task. If target is a future or coroutine, equivalent to asyncio.ensure_future If target is a callable, it is scheduled in the default executor """ ... def run_in_foreground(task, *, loop=None): """Runs event loop in current thread until the given task completes Returns the result of the task. For more complex conditions, combine with asyncio.wait() To include a timeout, combine with asyncio.wait_for() """ ... run_in_background is akin to invoking a shell command with a trailing "&" - it puts the operation into the background, leaving the current thread to move on to the next operation (or wait for input at the REPL). When coroutines are scheduled, they won't start running until you start a foreground task, while callables delegated to the default executor will start running immediately. To actually get the *results* of that task, you have to run it in the foreground of the current thread using run_in_foreground - this is akin to bringing a background process to the foreground of a shell session using "fg". To relate this idea back to some of the examples Sven was discussing, here's how translating some old serialised synchronous code to use those APIs might look in practice: # Serial synchronous data loading def load_and_process_data(): data1 = load_remote_data_set1() data2 = load_remote_data_set2() return process_data(data1, data2) # Parallel asynchronous data loading def load_and_process_data(): future1 = asyncio.run_in_background(load_remote_data_set1_async()) future2 = asyncio.run_in_background(load_remote_data_set2_async()) data1 = asyncio.run_in_foreground(future1) data2 = asyncio.run_in_foreground(future2) return process_data(data1, data2) The application remains fundamentally synchronous, but the asyncio event loop is exploited to obtain some local concurrency in waiting for client IO operations. Regards, Nick. P.S. time.sleep() and asyncio.sleep() are rather handy as standins for blocking and non-blocking IO operations. I wish I'd remembered that earlier :) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia [View Less]

8 16

Re: [Python-ideas] fork
by Sven R. Kunze Aug. 21, 2015

Aug. 21, 2015

Thanks everybody for the feedback on 'fork'. Let me address the issues and specify it further: 1) Process vs. Thread vs. Coroutine From my understanding, the main fallacy here is that the caller would be able to decide which type of pool is best suited. Take create_thumbnail as an example. You do not know whether this is cpu-bound or io-bound; you can just make a guess or try it out. But who knows then? I would say: the callee. create_thumbnail is cpu-bound when doing the work itself on … [View More]the machine. create_thumbnail is io-bound when delegating the work to, say, a web service. SAME FUNCTIONALITY, SAME NAME, SAME API, DIFFERENT POOLS REQUIRED. This said, I would propose something like a marking solution: @cpu_bound def create_thumbnail(image): # impl @io_bound def create_thumbnail(image): # impl (coroutines are already marked as such) From this, the Python interpreter should be able to infer which type of pool is appropriate. 2) Pool size Do lists have a fixed length? Do I need to define their lengths right from the start? Do I know them in advance? I think the answers to these questions are obvious. I don't understand why it should be different for the size of the pools. They could grow and shrink depending on the workload and the available resources. 3) Pool Management in General There is a reason why I hesitate to explicitly manage pools. Our code runs on a plethora of platforms ranging from few to many hardware threads. We actually do not want to integrate platform-specific properties right into the source. The point of having parallelism and concurrency is to squeeze out more of the machines and get better response times. Anything else wouldn't be honest in my opinion (besides from researching and experimenting). Thus, a practical solution needs to be simple and universal. Explicitly setting the size of the pool is not universal and definitely not easy. It doesn't need to be perfect. Even if a first draft implementation would simply define pools having exactly 4 processes/threads/coroutines, that would be awesome. Even cutting execution time into half would be an amazing accomplishment. Maybe, even 'fork' is too complicated. It could work without it given the decorators above. But then, we could not decide whether to run things in parallel or sequentially. I think I do not like that. 4) Keyword 'fork' Well, first shot. If you have a better one, I am all in for it (4 letters or shorter only ;) )... Or maybe something like 'par' for parallel or 'con' for concurrent. 5) Awaiting the Completion of Something As Andrew proposed, using the return value should result in blocking. What if there is no result to wait for? That one is harder but I think another keyword like 'wait' or 'await' should work here fine. for image in images: fork create_thumbnail(image) wait print(get_size_of_thumbnail_dir()) 6) Exceptions As close to sequential execution as possible. That is, when some function is forked out and raises an exception, it should behave as if it were a normal function call. for image in images: fork create_thumbnail(image) # I would like to see that in my stacktrace Also true for expressions. '+=' might raise an exception because, say, huge_calculation returns 'None'. Although the actually evaluation of the sum needs to take place only at the print statement, I would like to see the exception raised at the highlighted place: end_result = 0 for items in items_list: end_result += fork huge_calculation(items) # stacktrace for '+=' should be here print(end_result) # not here Best, Sven ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT [View Less]

7 38

template strings
by Yury Selivanov Aug. 20, 2015

Aug. 20, 2015

In ECMAScript 6 there is a concept of Template Strings [1]. What if we add something similar in Python? Some key ideas -------------- 1. Template Strings (TS) will be built on top of PEP 498 machinery (if accepted). 2. The syntax will match the following: {python identifier}{optional whitespace}{string literal} where "python identifier" can be any valid python name *except* r, u, b, or f. Some examples of valid TS: ## _'foo {bar}' ## sql = db.escape sql """ … [View More]

11 29

More "ensure*" packages
by Steve Dower Aug. 19, 2015

Aug. 19, 2015

I'd like to propose expanding the list of 3rd-party packages we bundle and install by default. (Obviously this does not apply to platforms that repackage Python and can do whatever they want, but on Windows and Mac we are fully responsible for these.) Currently, we bundle pip (and some of its dependencies - let's avoid that particular discussion right now please, it's on python-dev) and install it by default in a way that lets users easily update to the latest version. Including pip in … [View More]the standard library would lock users into a specific version for the lifetime of that Python version, which would be a bad thing. From my point-of-view, this has been very successful in Python 2.7, 3.4 and will also be successful in 3.5. For Python 3.6, I'd like to do a similar thing with: * requests * tkinter (including tcl/tk, IDLE, and other dependencies) Given the language summit discussion at PyCon this year, I think requests is easy to justify. (Quick summary for those who weren't there: we'd love to include requests in the stdlib, but it's too important and needs much more frequent updates.) Preinstalling a given version in a way that allows updates (and maybe attempting an update on installation) sounds great to me. tkinter is worth more discussion :) For the remainder of this email, I'll use "tkinter" as shorthand to refer to Tcl, Tk, Tix, _tkinter, tkinter, idlelib/IDLE, PyDoc, turtledemo and any other dependencies or dependents that I missed. In my experience, few Python scripts depend on or assume tkinter is available. tkinter is already an optional item in the Windows installer (maybe Mac too? I don't know) and there are certainly installations of Python out there that don't have it. From this side, nothing would actually change by installing tkinter into site-packages rather than Lib. (One impact may be the start menu shortcuts for IDLE and PyDoc, but provided the entry points into those tools are kept stable we can continue adding shortcuts from the installer. People who omit tkinter and then install it later would not get shortcuts. But since they omitted it from the installer, they probably don't want them - they likely just got a package that has tkinter as a dependency.) IDLE is already allowed to make enhancements in maintenance branches (https://www.python.org/dev/peps/pep-0434/), and we have recently received patches that are to be applied to *four* branches. The freedom to enhance IDLE is greatly improved by making it a PyPI installable package and disconnecting it from the stdlib's schedule. How this would actually be structured is up for discussion. I believe the change can be made without sacrificing anything, and the resulting flexibility will be worth it. Thoughts? Cheers, Steve [View Less]

15 32