Mailman 3 February 2011 - Python-ideas

Support for regular expression syntax
by Alexander 27 Feb '11

27 Feb '11

Hello. Maybe this topic has been discussed. I would like to have the support of alphabetic rules, such as \p{...}, in re module.

4 3

Re: [Python-ideas] [Python-Dev] Let's get PEP 380 into Python 3.3
by Joao S. O. Bueno 26 Feb '11

26 Feb '11

On Fri, Feb 25, 2011 at 8:01 PM, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > From: Guido van Rossum > >> (OTOH I am not much enamored with cofunctions, PEP 3152.) > > That's okay, I don't like it much myself in its current form. > I plan to revisit it at some point, but there's no hurry. I've just gone through PEP 3152 - and the first though that occurred me is that a decorator is perfectly usable instead of the new proposed keyword "codef". (It would need to be able to set special attributes in the function to indicate its nature) Besides not adding a new keyword, it would allow for different (concurrently running? ) types of co-functions to be created and benefit from the other mechanisms. But maybe considerations about this should be take place on python-ideas only? > -- > Greg >

1 0

Cleaner separation of help() and interactive help.
by Ron Adam 24 Feb '11

24 Feb '11

Currently any call to help() uses the pager in pydoc. Because of that, you can't do some things (easily) like... >>> result = help(thing) It also can be annoying (to me) when I use help and the result is cleared after the pager is done with it. That requires me to re-do the same help requests to recheck details rather than simply scroll back in the current console window. The alternative is to keep another console open just for using help. That's not always good when you already have multiple windows open for doing other things. In python 3.3, I would like to have help() return the results as a string, and only use the pager if you are actually in interactive-help mode. >>> help(thing) # return a help string of a thing. >>> help() # enter interactive help mode where the pager is used. Separating these even more might be good, ... help() and ihelp(). In this case, the current help() function could just be renamed to ihelp(), and a new help() function would return a result as a string. The default might be help(thing='help'). The help on 'help' would refer to 'ihelp' for the interactive help. Sometime later, I want to look into moving the pager in pydoc to the cmd module as cmd.pager(). (I think it fits well there.) And related to that... I am going to look into re-implementing pydocs interactive help with the cmd module. I think it will remove some duplication, and both modules will benefit. Cheers, Ron

10 21

Cleanup, uniformization and documentation of stdlib module reactions to `python -m <module>`
by Masklinn 20 Feb '11

20 Feb '11

There are three ways a Python module can react to `-m`: do nothing, selftest (via doctests or via python code) and do something "useful" (for Python users). The former is fine, but the latter two have more issues: For modules which selftest, the self-tests/sanity check are generally undocumented and potentially long-running or destructive. It would be nice if those were protected behind an argument (e.g. `-x` for `—execute`) just in case For "useful" modules, the issues are far more complex: 1. Many (if not most) are under- or un-documented, no information being available in their module documentation, and/or via the command-line (ftplib, modulefinder, dis), this makes them into little more than easter eggs. Some are documented in the standard library documentation but not the command-line (http.server), others are documented on the command-line but not in their module documentation (smtpd). It would be nice if all of these tools were documented in both places, but the bare minimum would be for all of them to provide CLI help (one which explains at the very least what the command does, here again some of the commands providing a "cli help" give little more information than a list of options: no information on the command itself, and no documentation of what the various options do). 2. The arguments parsing is inconsistent, I've seen all of manual parsing (ftplib, http.server, pstats), getopt (smtpd, timeit, trace, webbrowser), optparse (calendar, cProfile, uu) and argparse (compileall, nntplib), and the reactions to standard flags (e.g. `-h`/`—help`) is a crapshoot, modules may or may not crash completely or display parse errors (when provided with a `-h` flag). All modules should use the same arguments parsing library (argparse), which would automatically yield a correct reaction to `-h` across the board. Even modules not using options themselves (e.g. http.server) should do so, so they can react correctly to `-h`. There are many hidden gems in the stdlib, and CLI usage of modules is one of them: some are pretty well-known (timeit, http.server), others are more rarely known (urllib, cProfiler) but I'd wager the vast majority are almost never used because the vast majority of Python developers have no idea they can be used that way.

1 0

wsgiref.simple_server should mount and serve a provided WSGI application script
by Masklinn 20 Feb '11

20 Feb '11

Many (most?) WSGI servers use WSGI application scripts (a Python script with a `.py` or `.wsgi` extension generally, providing a global `application` variable) to setup and mount applications. Currently, `python -m wsgiref.simple_server` mounts a trivial "hello world" application and opens it in the web browser. It would be nice if `python -m wsgiref.simple_server file` mounted and served the application set up by the script instead.

1 0

Re: [Python-ideas] adding possibility for declaring a function in Matlab's way
by Géza 14 Feb '11

14 Feb '11

All, Thank you for the constructive remarks, especially Bruce Leban for pointing out the TOOWTDI principle, which is why it wouldn't fit into the Python philosophy, and Stephen J. Turnbull for the idea of doing it with decorators. I could actually implement something similar to what I wanted with decorators, although it still needs improvement. All the best, Géza P.S. This is somewhat off-topic, but if someone has ideas on improving it, personal replies are welcome. Two things that are not really nice about it: one, you need to specify the variable names between quotes, two, you may get "unused variable" warnings for the return variables. See the code below. (I intentionally did not try to initialize the local variables to None, as I realized that this is the behavior of Matlab, too, which makes sense: You should be told if you forget to calculate the value of a return variable.) ''' MtFn.py version 1.0 Uses code from persistent_locals2 by Pietro Berkes and Andrea Maffezzoli. @author: Geza Kiss ''' import sys class MtFn: def __init__(self, sRetVars): self.lRetVars=[s.strip() for s in sRetVars.split(',')] self._locals = {} def __call__(self, function): def Mt2PyFn(*args): def tracer(frame, event, arg): if event=='return': self._locals = frame.f_locals.copy() prev_tracer=sys.setprofile(tracer) try: res=function(*args) finally: sys.setprofile(prev_tracer) if res: raise ValueError("You must not return a value in Matlab-like (@MtFn) function '%s'." % (function.__name__)) try: return tuple([self._locals[var] for var in self.lRetVars]) except KeyError as exc: raise KeyError("Return value '%s' is not set in Matlab-like (@MtFn) function '%s'." % (exc.args[0], function.__name__)) return Mt2PyFn ---------------- ''' MtFnTest.py ''' from MtFn import MtFn @MtFn('a,b') def fun(x,y): a=x+y b=x-y print fun(5,6)

1 0

Re: [Python-ideas] Alternative formatting styles for logging events in Python 3.3
by Nick Coghlan 13 Feb '11

13 Feb '11

On Fri, Feb 11, 2011 at 3:21 AM, Vinay Sajip <vinay_sajip(a)yahoo.co.uk> wrote: > Perhaps this style could be emphasised in the stdlib documentation. The > XXXMessage classes could be brought into stdlib (not something I'm particularly > advocating, mind you). Given that the ability to pass in something other than a %-formatting format string isn't even *mentioned* in the API documentation for logging.debug [1][2] this trick could definitely use some additional exposure. While this existing capability definitely makes the per-event part of my suggestion redundant, I think the per-logger part of it still has some merit. If loggers are defined as inheriting their formatting style from their parent loggers when an explicit style isn't provided, then an application or library that wants to use an alternate formatting style only needs to set it up once on their primary logger and away they go. (Creating the root logger with a formatting style other than '%' would obviously be a bad idea, so it may be worth issuing an explicit warning when someone does that) Cheers, Nick. [1] http://docs.python.org/dev/library/logging#logging.Logger.debug [2] http://docs.python.org/dev/library/logging#logging.debug -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

2 2

adding possibility for declaring a function in Matlab's way
by Géza 13 Feb '11

13 Feb '11

It would be nice if you could write a function header like this (besides, of course, the current way): def result=functionname(params): ... result=something This would suffice for most functions, since you usually return one type of value, and it can be very convenient in certain cases. This is the way it is done e.g. in Matlab, which also has a huge user base. Some more details to the idea: - The return values are initialized to None. - Setting the return values does not need to be the last line in the function. - You can use the "return" statement just as before, but without arguments, to return from anywhere in the code. - If you specify arguments to the "return" statement, Python stops with an exception. - The return value can be a tuple: def (result1, result2, result3)=functionname(parameters) Some advantages: - You can easily see what the function returns, without having to read the function body, or hoping to find it in the comments. - You can initialize the return values (if None is not good enough), and then care about the cases where they change. - If you change the setup of the return value (e.g. insert a new item into the tuple), you do not need to change the "return" statement at possibly several places in the function body. - It is very easy to write the function call prototype: just copy the function declaration without the "def" and final colon. Python GUIs will be able to do the same, thus not only giving you the function parameter template automatically, but also the return value template. Some disadvantages: - I suggest it as an addition to the current way, so there isn't any serious disadvantage. One person may decide to use one way, one the other. - Of course, if you mix the two types of function declarations in your software, you may need to look at the function header to see which one you used in the specific case. - You need to be aware of both ways when reading someone else's code --- which is not hard, as both ways are quite easy to read. The idea at this stage of Python development may be surprising, but I hope that nevertheless you will consider it seriously. There has been a lot of experience and developlment regarding this in connection with Matlab, and I am sure that many of you know better than me how it would fit into Python's philosophy, and what consequences adding it may have. Thanks for your time, and best regard! Géza

6 5

Re: [Python-ideas] Python-ideas Digest, Vol 51, Issue 16
by Arthur 12 Feb '11

12 Feb '11

You can return a tuple instead change the syntax... def res1, res2 = foo(): #code here can be def foo(): #code here return (res1,res2) Até mais! Ass.: Arthur Julião ------------------------------------------------------------------------------------------------ "Quero que a estrada venha sempre até você e que o vento esteja sempre a seu favor, quero que haja sempre uma cerveja em sua mão e que esteja ao seu lado seu grande amor." (Tempo Ruim - A Arte do Insulto - Matanza) 2011/2/12 <python-ideas-request(a)python.org> > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. adding possibility for declaring a function in Matlab's way (G?za) > 2. Re: adding possibility for declaring a function in Matlab's > way (Terry Reedy) > 3. Re: adding possibility for declaring a function in Matlab's > way (Bruce Leban) > 4. adding possibility for declaring a function in Matlab's way > (Stephen J. Turnbull) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 11 Feb 2011 19:48:38 -0800 > From: G?za <kgeza7(a)gmail.com> > To: "python-ideas" <python-ideas(a)python.org> > Subject: [Python-ideas] adding possibility for declaring a function in > Matlab's way > Message-ID: <7C2FD842074A470387F4F83B280C22A3@GezaVAIO> > Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; > reply-type=original > > It would be nice if you could write a function header like this (besides, > of > course, the current way): > > def result=functionname(params): > ... > result=something > > This would suffice for most functions, since you usually return one type of > value, and it can be very convenient in certain cases. This is the way it > is > done e.g. in Matlab, which also has a huge user base. > > Some more details to the idea: > - The return values are initialized to None. > - Setting the return values does not need to be the last line in the > function. > - You can use the "return" statement just as before, but without arguments, > to return from anywhere in the code. > - If you specify arguments to the "return" statement, Python stops with an > exception. > - The return value can be a tuple: def (result1, result2, > result3)=functionname(parameters) > > Some advantages: > - You can easily see what the function returns, without having to read the > function body, or hoping to find it in the comments. > - You can initialize the return values (if None is not good enough), and > then care about the cases where they change. > - If you change the setup of the return value (e.g. insert a new item into > the tuple), you do not need to change the "return" statement at possibly > several places in the function body. > - It is very easy to write the function call prototype: just copy the > function declaration without the "def" and final colon. Python GUIs will be > able to do the same, thus not only giving you the function parameter > template automatically, but also the return value template. > > Some disadvantages: > - I suggest it as an addition to the current way, so there isn't any > serious > disadvantage. One person may decide to use one way, one the other. > - Of course, if you mix the two types of function declarations in your > software, you may need to look at the function header to see which one you > used in the specific case. > - You need to be aware of both ways when reading someone else's code --- > which is not hard, as both ways are quite easy to read. > > The idea at this stage of Python development may be surprising, but I hope > that nevertheless you will consider it seriously. > There has been a lot of experience and developlment regarding this in > connection with Matlab, > and I am sure that many of you know better than me how it would fit into > Python's philosophy, and what consequences adding it may have. > > Thanks for your time, and best regard! > G?za > > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 23:05:20 -0500 > From: Terry Reedy <tjreedy(a)udel.edu> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] adding possibility for declaring a > function in Matlab's way > Message-ID: <ij50tv$tmn$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/11/2011 10:48 PM, G?za wrote: > > It would be nice if you could write a function header like this > > (besides, of course, the current way): > > > > def result=functionname(params): > > ... > > result=something > > > > This would suffice for most functions, since you usually return one type > > of value, and it can be very convenient in certain cases. This is the > > way it is done e.g. in Matlab, which also has a huge user base. > > Perhaps you should also suggest to the Matlab people that they add > Python-style declarations to Matlab;-! After all, Python also has a huge > user base. > > > Some disadvantages: > > - I suggest it as an addition to the current way, so there isn't any > > serious disadvantage. One person may decide to use one way, one the > other. > > This is a huge disadvantage. Everyone would have to learn two equivalent > syntaxes instead of one, which would make the language much more > difficult to learn. > > Python's syntax is essentially frozen except for possible minor > additions that show some real gain. > > -- > Terry Jan Reedy > > > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 20:10:30 -0800 > From: Bruce Leban <bruce(a)leapyear.org> > To: G?za <kgeza7(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] adding possibility for declaring a > function in Matlab's way > Message-ID: > <AANLkTikZ=mdhsKwqO3DhBzBXPZKCDo5zn80RVy=BH4Mz(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Before suggesting "improvements" to Python (or anything else for that > matter), it's helpful to identify exactly what problem you are trying to > solve. I don't see one. And having multiple entirely different ways to do > things for no good reason mean code is harder to read. Google TOOWTDI for > more info. > > If you love this paradigm I suggest you write it this way: > > def foo(): > global result > result = None > if bar() is not None: > raise UnnecessaryException > return result > def bar(): > pass # real code goes here > > > --- Bruce > New Puzzazz newsletter: http://j.mp/puzzazz-news-2011-02 > > > > On Fri, Feb 11, 2011 at 7:48 PM, G?za <kgeza7(a)gmail.com> wrote: > > > It would be nice if you could write a function header like this (besides, > > of course, the current way): > > > > def result=functionname(params): > > ... > > result=something > > > > This would suffice for most functions, since you usually return one type > of > > value, and it can be very convenient in certain cases. This is the way it > is > > done e.g. in Matlab, which also has a huge user base. > > > > Some more details to the idea: > > - The return values are initialized to None. > > - Setting the return values does not need to be the last line in the > > function. > > - You can use the "return" statement just as before, but without > arguments, > > to return from anywhere in the code. > > - If you specify arguments to the "return" statement, Python stops with > an > > exception. > > - The return value can be a tuple: def (result1, result2, > > result3)=functionname(parameters) > > > > Some advantages: > > - You can easily see what the function returns, without having to read > the > > function body, or hoping to find it in the comments. > > - You can initialize the return values (if None is not good enough), and > > then care about the cases where they change. > > - If you change the setup of the return value (e.g. insert a new item > into > > the tuple), you do not need to change the "return" statement at possibly > > several places in the function body. > > - It is very easy to write the function call prototype: just copy the > > function declaration without the "def" and final colon. Python GUIs will > be > > able to do the same, thus not only giving you the function parameter > > template automatically, but also the return value template. > > > > Some disadvantages: > > - I suggest it as an addition to the current way, so there isn't any > > serious disadvantage. One person may decide to use one way, one the > other. > > - Of course, if you mix the two types of function declarations in your > > software, you may need to look at the function header to see which one > you > > used in the specific case. > > - You need to be aware of both ways when reading someone else's code --- > > which is not hard, as both ways are quite easy to read. > > > > The idea at this stage of Python development may be surprising, but I > hope > > that nevertheless you will consider it seriously. > > There has been a lot of experience and developlment regarding this in > > connection with Matlab, > > and I am sure that many of you know better than me how it would fit into > > Python's philosophy, and what consequences adding it may have. > > > > Thanks for your time, and best regard! > > G?za > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas(a)python.org > > http://mail.python.org/mailman/listinfo/python-ideas > > >

1 0

Changing the name of __pycache__
by Raymond Hettinger 10 Feb '11

10 Feb '11

It would be great if there was some way to change the name to .pycache so that it doesn't pollute directory listings. The dot-naming convention seems to be widely used (.bashrc, .emacs, .hgignore, etc.). Ideally, we should follow that convention also or at least provide a way to make the change locally (perhaps an environment variable). Raymond

16 41