Re: [Matplotlib] Ploting an exponential distribution frequency curve
Mario Figueiredo wrote: >Other than replacing the random module with the probability density >function for the exponential distribution, do you have a suggestion of >how I could smooth the curve? Moving average. Try: def movingaverage(interval, window_size): window= numpy.ones(int(window_size))/float(window_size) return numpy.convolve(interval, window, 'same') y_av = movingaverage(y,10) Note that you'd get problems at the start and end of the curve if it's non-zero there, which is difficult to avoid with noise-reduction. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Matplotlib] Ploting an exponential distribution frequency curve
On Sun, 26 Apr 2015 11:17:07 +0100, Dave Farrance wrote: > >Moving average. Try: > >def movingaverage(interval, window_size): >window= numpy.ones(int(window_size))/float(window_size) >return numpy.convolve(interval, window, 'same') > >y_av = movingaverage(y,10) > >Note that you'd get problems at the start and end of the curve if it's >non-zero there, which is difficult to avoid with noise-reduction. Thanks for the suggestion, Dave. I'm also considering the interpolation sub-package in SciPy. http://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html I was a bit surprised that matplotlib didn't offer me interpolation out-of-the-box like gnuplot's `smooth csplines` option. -- https://mail.python.org/mailman/listinfo/python-list
Best GUI for Python
I want to use a GUI for Python. When searching I found (beside some others) Tkinter and wxPython. From what I found it looks like Tkinter is slightly better. What would be the pros/cons of these two? Would there be a compelling reason to use another GUI? -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Library import succeeds with nose, fails elsewhere
On Saturday, April 25, 2015 at 7:53:27 PM UTC-4, Chris Angelico wrote: > On Sun, Apr 26, 2015 at 9:36 AM, wrote: > > The solution ended up being editing the top-level __init__.py: > > > > import awesome > > > > and then *when in a subdirectory*: > > > > import awesome_lib as awesome > > > > and *when in a different top-level file*: > > > > import awesome. > > > > IOW (from what I can tell) I made importing the package the same as > > importing this one file. When in a subdirectory import via the package, > > when in a sibling file import the file directly. > > > > This certainly feels odd, and I did find some (likely preferred) different > > ways I could handle it. My intent was that now I can refer to > > awesome.util.helper regardless of where I am (outside the package, within > > different directories, etc). My guess is that doing things like importing > > 'helper' directly and referring to it as 'helper' (no awesome.util prefix) > > is the python way of doing things, just didn't ring true with my background. > > > > Give "from . import helper" a try; you may find that it works just as > well as "import helper" does, but more explicitly saying that you want > it from the current package. Other than that, I think you have > something that'll work fine. > > ChrisA Just to follow up - could not get "from . import awesome" to work when in helper.py. Thanks for your help though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Question Installing latest Python
On Mon, 27 Apr 2015 01:00 am, Φώντας Λαδοπρακόπουλος wrote: > Hello, > > Can you please tell me how to install latest Python 3.4.x without > disturbing the other default python v2.7.5 intallation that i currently > have on my VPS server and access it as Python 3? > > Thank you. Not unless you tell us more about your setup. What operating system? Linux, OS X, Unix, Windows? 32-bit or 64-bit OS? Do you have root/Administrator access to the machine? If you are running Windows, do you have a C compiler? Have you read the instructions on the Python web site? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote: > I want to use a GUI for Python. When searching I found (beside some > others) Tkinter and wxPython. From what I found it looks like Tkinter > is slightly better. What would be the pros/cons of these two? Would > there be a compelling reason to use another GUI? Tkinter is easier to use, as it is standard with Python. So long as you have Tk/Tcl installed on your computer, Tkinter should work fine. However, Tkinter probably looks a bit more old fashioned. wxPython probably looks a bit more modern and may be a bit more powerful, but it will require a large extra library. It's also a lot harder to learn to use wxPython unless you are comfortable with C++ programming. Have you seen this? https://wiki.python.org/moin/GuiProgramming -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
Op Sunday 26 Apr 2015 15:02 CEST schreef Cecil Westerhof: > I want to use a GUI for Python. When searching I found (beside some > others) Tkinter and wxPython. From what I found it looks like > Tkinter is slightly better. What would be the pros/cons of these > two? Would there be a compelling reason to use another GUI? It is important to tell which version of Python I use, because wxPython does not work with Python 3. At the moment I am still working with Python 2.7.8 and am not planning to update to 3 in the near future. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano: > On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote: > >> I want to use a GUI for Python. When searching I found (beside some >> others) Tkinter and wxPython. From what I found it looks like >> Tkinter is slightly better. What would be the pros/cons of these >> two? Would there be a compelling reason to use another GUI? > > Tkinter is easier to use, as it is standard with Python. So long as > you have Tk/Tcl installed on your computer, Tkinter should work > fine. > > However, Tkinter probably looks a bit more old fashioned. > > wxPython probably looks a bit more modern and may be a bit more > powerful, but it will require a large extra library. It's also a lot > harder to learn to use wxPython unless you are comfortable with C++ > programming. Well, I did my share of C++ programming. ;-) > Have you seen this? > > https://wiki.python.org/moin/GuiProgramming Dabo looks interesting, but also a little bit dead. Well, maybe I just should evaluate Tkinter and wxPython both. Now wxPython looks more interesting. But it is easier to make a reasonable decision when I have a little more information. :-D For the moment I limit it to Tkinter and wxPython. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On 26/04/2015 17:16, Cecil Westerhof wrote: Op Sunday 26 Apr 2015 15:02 CEST schreef Cecil Westerhof: I want to use a GUI for Python. When searching I found (beside some others) Tkinter and wxPython. From what I found it looks like Tkinter is slightly better. What would be the pros/cons of these two? Would there be a compelling reason to use another GUI? It is important to tell which version of Python I use, because wxPython does not work with Python 3. The development version of wxpython for Python 3 here http://wxpython.org/Phoenix/snapshot-builds/ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On 04/26/2015 09:32 AM, Cecil Westerhof wrote: Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano: On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote: I want to use a GUI for Python. When searching I found (beside some others) Tkinter and wxPython. From what I found it looks like Tkinter is slightly better. What would be the pros/cons of these two? Would there be a compelling reason to use another GUI? Tkinter is easier to use, as it is standard with Python. So long as you have Tk/Tcl installed on your computer, Tkinter should work fine. However, Tkinter probably looks a bit more old fashioned. wxPython probably looks a bit more modern and may be a bit more powerful, but it will require a large extra library. It's also a lot harder to learn to use wxPython unless you are comfortable with C++ programming. Well, I did my share of C++ programming. ;-) Have you seen this? https://wiki.python.org/moin/GuiProgramming Dabo looks interesting, but also a little bit dead. Well, maybe I just should evaluate Tkinter and wxPython both. Now wxPython looks more interesting. But it is easier to make a reasonable decision when I have a little more information. :-D For the moment I limit it to Tkinter and wxPython. I wouldn't recommend limiting yourself like that. I've used both successively (years ago), then pyGTK for a batch of projects, followed by pyglet for some years and many projects, and most recently PyQt. They are all worthy GUI programming libraries, and each of them is cross platform (as I required to develop on Linux, but deploy occasionally on Windows). -- Dr. Gary Herron Department of Computer Science DigiPen Institute of Technology (425) 895-4418 -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
Op Sunday 26 Apr 2015 19:12 CEST schreef Gary Herron: > On 04/26/2015 09:32 AM, Cecil Westerhof wrote: >> Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano: >> >>> On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote: >>> I want to use a GUI for Python. When searching I found (beside some others) Tkinter and wxPython. From what I found it looks like Tkinter is slightly better. What would be the pros/cons of these two? Would there be a compelling reason to use another GUI? >>> Tkinter is easier to use, as it is standard with Python. So long >>> as you have Tk/Tcl installed on your computer, Tkinter should work >>> fine. >>> >>> However, Tkinter probably looks a bit more old fashioned. >>> >>> wxPython probably looks a bit more modern and may be a bit more >>> powerful, but it will require a large extra library. It's also a >>> lot harder to learn to use wxPython unless you are comfortable >>> with C++ programming. >> Well, I did my share of C++ programming. ;-) >> >> >>> Have you seen this? >>> >>> https://wiki.python.org/moin/GuiProgramming >> Dabo looks interesting, but also a little bit dead. Well, maybe I >> just should evaluate Tkinter and wxPython both. Now wxPython looks >> more interesting. But it is easier to make a reasonable decision >> when I have a little more information. :-D >> >> For the moment I limit it to Tkinter and wxPython. > > I wouldn't recommend limiting yourself like that. I've used both > successively (years ago), then pyGTK for a batch of projects, > followed by pyglet for some years and many projects, and most > recently PyQt. They are all worthy GUI programming libraries, and > each of them is cross platform (as I required to develop on Linux, > but deploy occasionally on Windows). I did say for the moment. ;-) But just curious: what is the reason you use five different kinds of GUI? It seems like it makes think difficult for you. I mean the question as enlightenment for myself. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof -- https://mail.python.org/mailman/listinfo/python-list
Re: [Matplotlib] Ploting an exponential distribution frequency curve
On Sat, 25 Apr 2015 23:33:10 +0100, Mario Figueiredo wrote: > plot(list(results.keys()), list(results.values())) I found multiple plots in matplotlib. You need to specify which one you're using. The first thing you need to do is create a small self contained example of your problem. State the problem: Plot does not create the output you expect. Give an example: plot( [1,11], [5,5] ) Explain what you expect the output to be: You expect a line to be plotted from (1,5) to (11,5) Explain what you actually see: ??? Note that it may be possible to correlate the data values and the output of the simple case in a way that shows you that you have in some way fundamentally misunderstood how the arguments should be passed to the plot function. If this is the case, work out what you need to do to fix the simple case, and then apply the same solution to your more complex data set. If, for example, you see a line from (1,11) to (5,5) instead of a line from (1,5) to (11,5), then it might be that you need to combine the two lists into a single list of co-ordinate tuples, using eg: plot(zip(list(results.keys()), list(results.values( -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
> > But just curious: what is the reason you use five different kinds of > GUI? It seems like it makes think difficult for you. I mean the > question as enlightenment for myself. A good question :). Most of this comes from the openness to create binding for many projects. Tkinter is a binding of Tk. pyGTK is a binding of GTK, which is written in c++, the same is true of PyQt/PySide, which binds Qt. wxPython binds wxWidgets. I find the variation good, because it means there are more choices. I use PyQt, because I wanted very cross platform code, other choose pyGTK because they want to closely integrate with the GTK environment. Your choice of GUI library depends on what you are targeting. -- https://mail.python.org/mailman/listinfo/python-list
Re: [Matplotlib] Ploting an exponential distribution frequency curve
On Sun, 26 Apr 2015 18:55:27 + (UTC), Denis McMahon wrote: >The first thing you need to do is create a small self contained example >of your problem. > >State the problem: Plot does not create the output you expect. > >Give an example: > >plot( [1,11], [5,5] ) > >Explain what you expect the output to be: > >You expect a line to be plotted from (1,5) to (11,5) > >Explain what you actually see: ??? > I think you missed several posts in this thread, including my reply to your earlier post. This problem was never about anythiong of that sort. It is also solved. I suggest, since this is a NNTP group, that you use a desktop or web newsreader that is capable of displaying treaded messages, or set your email client to organize emails from comp.lang.python in a threaded way. I suspect you are using flat list email and that may be inadequate if you wish to participate in any discussion in here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On 04/26/2015 11:07 AM, Cecil Westerhof wrote: Op Sunday 26 Apr 2015 19:12 CEST schreef Gary Herron: On 04/26/2015 09:32 AM, Cecil Westerhof wrote: Op Sunday 26 Apr 2015 17:09 CEST schreef Steven D'Aprano: On Sun, 26 Apr 2015 11:02 pm, Cecil Westerhof wrote: I want to use a GUI for Python. When searching I found (beside some others) Tkinter and wxPython. From what I found it looks like Tkinter is slightly better. What would be the pros/cons of these two? Would there be a compelling reason to use another GUI? Tkinter is easier to use, as it is standard with Python. So long as you have Tk/Tcl installed on your computer, Tkinter should work fine. However, Tkinter probably looks a bit more old fashioned. wxPython probably looks a bit more modern and may be a bit more powerful, but it will require a large extra library. It's also a lot harder to learn to use wxPython unless you are comfortable with C++ programming. Well, I did my share of C++ programming. ;-) Have you seen this? https://wiki.python.org/moin/GuiProgramming Dabo looks interesting, but also a little bit dead. Well, maybe I just should evaluate Tkinter and wxPython both. Now wxPython looks more interesting. But it is easier to make a reasonable decision when I have a little more information. :-D For the moment I limit it to Tkinter and wxPython. I wouldn't recommend limiting yourself like that. I've used both successively (years ago), then pyGTK for a batch of projects, followed by pyglet for some years and many projects, and most recently PyQt. They are all worthy GUI programming libraries, and each of them is cross platform (as I required to develop on Linux, but deploy occasionally on Windows). I did say for the moment. ;-) But just curious: what is the reason you use five different kinds of GUI? It seems like it makes think difficult for you. I mean the question as enlightenment for myself. Yikes, Stated like that it does sound excessive but in reality it's spread over about 20 years of Python and graphics/GUI programming. Experimenting with a new GUI every 5 years or so just keeps the interest levels up. -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
Steven D'Aprano writes: > Tkinter is easier to use, as it is standard with Python. So long as > you have Tk/Tcl installed on your computer, Tkinter should work fine. > > However, Tkinter probably looks a bit more old fashioned. It doesn't have to. By using the newer ‘tkinter.ttk’ library https://docs.python.org/3/library/tkinter.ttk.html>, the GUI will use native look-and-feel widgets. Why not by default? To preserve backward compatibility. There are some old GUI programs using basic Tkinter, and breaking the GUI is not a good thing to do to programs which are otherwise working fine. So you only get the newer widgets by asking for them explicitly. -- \“Members of the general public commonly find copyright rules | `\implausible, and simply disbelieve them.” —Jessica Litman, | _o__) _Digital Copyright_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Tit for tat
https://www.youtube.com/watch?v=48EWLj3gIJ8 Anyone here worked on trying a better strategy? -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney wrote: > Steven D'Aprano writes: > >> Tkinter is easier to use, as it is standard with Python. So long as >> you have Tk/Tcl installed on your computer, Tkinter should work fine. >> >> However, Tkinter probably looks a bit more old fashioned. > > It doesn't have to. By using the newer ‘tkinter.ttk’ library > https://docs.python.org/3/library/tkinter.ttk.html>, the GUI will > use native look-and-feel widgets. > > Why not by default? To preserve backward compatibility. There are some > old GUI programs using basic Tkinter, and breaking the GUI is not a good > thing to do to programs which are otherwise working fine. So you only > get the newer widgets by asking for them explicitly. Does the new library also deal with the ongoing issues with Unicode support? AIUI there's some fundamental problem with Tkinter which means that (possibly only on Windows?) non-BMP characters simply can't be displayed. To me, that's a pretty bad flaw - we should be aiming new projects at complete Unicode support, which means Python 3 and a good GUI toolkit. PyGTK is a bit clunky in some areas, but I have GTK experience from other languages, so that's the one I personally use. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Tit for tat
Seymore4Head writes: > Anyone here worked on trying a better strategy? If you want us to spend the time visiting a link, please spend the time yourself to summarise why it's relevant here. Do so in the initial post with the link. -- \ “Some mornings, it's just not worth chewing through the leather | `\ straps.” —Emo Philips | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Tit for tat
On Mon, 27 Apr 2015 09:40:04 +1000, Ben Finney wrote: >Seymore4Head writes: > >> Anyone here worked on trying a better strategy? > >If you want us to spend the time visiting a link, please spend the time >yourself to summarise why it's relevant here. Do so in the initial post >with the link. Richard Dawkins explains with passion the idea of game theory and tit for tat, or why cooperation with strangers is often a strong strategy. He talks of a computer program tournament. I don't know what I could say that would be more interesting than just watching the video. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tit for tat
On Monday, April 27, 2015 at 7:11:08 AM UTC+5:30, Seymore4Head wrote: > On Mon, 27 Apr 2015 09:40:04 +1000, Ben Finney wrote: > > >Seymore4Head writes: > > > >> Anyone here worked on trying a better strategy? > > > >If you want us to spend the time visiting a link, please spend the time > >yourself to summarise why it's relevant here. Do so in the initial post > >with the link. > > Richard Dawkins explains with passion the idea of game theory and tit > for tat, or why cooperation with strangers is often a strong strategy. > > He talks of a computer program tournament. I don't know what I could > say that would be more interesting than just watching the video. That's a good summary. Many people would not click on any-ol video -- https://mail.python.org/mailman/listinfo/python-list
Function decorator having arguments is complicated
I want to ask Python experts about function decorator which has arguments. I feel that function decorator having arguments is complicated, because three 'def' are nested: def multiply(n): def deco(func): def newfunc(*args, **kwargs): return n * func(*args, **kwargs) return newfunc return deco @multiply(4) def f1(x, y): return x+y print(f1(2, 3)) #=> 20 (= 4 * (2+3)) If function decorator notation could take arguments, decorator definition would be more simple: def multiply(func, n): def newfunc(*args, **kwargs): return n * func(*args, **kwargs) return newfunc @multiply 4 # ex: @decorator arg1, arg2, arg3 def f1(x, y): return x+y How do you think about this idea? -- regards, makoto kuwata -- https://mail.python.org/mailman/listinfo/python-list
Re: Tit for tat
Seymore4Head writes: > Richard Dawkins explains with passion the idea of game theory and tit > for tat, or why cooperation with strangers is often a strong strategy. > > He talks of a computer program tournament. Thanks! That is what would be great to have when you present the link in the first message. That way we know *why* we should go visit an otherwise context-free link. -- \ “The basic fact about human existence is not that it is a | `\tragedy, but that it is a bore.” —Henry L. Mencken | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
On Mon, Apr 27, 2015 at 12:37 PM, Makoto Kuwata wrote: > If function decorator notation could take arguments, > decorator definition would be more simple: > > def multiply(func, n): > def newfunc(*args, **kwargs): > return n * func(*args, **kwargs) > return newfunc > > @multiply 4 # ex: @decorator arg1, arg2, arg3 > def f1(x, y): > return x+y > I agree it would be nice to have extra parameters directly handled, but before you go further with the proposal, I suggest having a read of the original PEP that introduced decorators: https://www.python.org/dev/peps/pep-0318/ There are a *lot* of different ways that decorators could have been done. Currently, decorators use a restricted subset of expression syntax; the bit after the @ is guaranteed [1] to be a valid expression which results in a callable which is passed one argument (the function) and whose return value replaces the function. What you propose would no longer be a valid expression, and may introduce parsing problems for the interpreter and/or for humans. But if the writing of decorators is hard and common for you, you can always use a bit of metaprogramming to simplify it. (Since decorators are already metaprogramming, this would be metametaprogramming, I guess.) Something like: import functools def decorator(deco): """Make a function into an argument-accepting decorator""" @functools.wraps(deco) def outer(*a, **kw): def inner(func): return deco(func, *a, **kw) return inner return outer @decorator def multiply(func, n): @functools.wraps(func) def newfunc(*a, **kw): return n * func(*a, **kw) return newfunc @multiply(4) def f1(x, y): return x+y print(f1(2, 3)) #=> 20 (= 4 * (2+3)) (Note that I'm using functools.wraps here so docstrings and stuff get carried over) And if you're writing a lot of functions that call the original and then do something with the result, you could push that part into the decorator too: import functools def modifier(deco): """Make a function into an argument-accepting decorator""" @functools.wraps(deco) def outer(*a1, **kw1): def middle(func): def inner(*a2, **kw2): return deco(func(*a2, **kw2), *a1, **kw1) return inner return middle return outer @modifier def multiply(result, n): return n * result @multiply(4) def f1(x, y): return x+y print(f1(2, 3)) #=> 20 (= 4 * (2+3)) Python lets you be as insane as you like :) There are a lot of places in Python code (actually, in code generally) where usage is clean and implementation is horrific, and this can be one of them. The modifier() function's implemenation is deeply nested, but it's beautifully easy to use. A namedtuple is really convenient to use (just subscript it or use attribute lookup!), creating a new namedtuple type is reasonably alright, but the implementation of namedtuple() itself is scary. Nested and complicated, I got no problem with, long as she does it quiet-like! Can you do everything you need with a metadecorator? Either way, it's worth working on as part of a plan for parameterized decorators. Either you can say "here's this new syntax, and it's equivalent to this massive block of code" (look at the definition of "yield from" in PEP 380 - sure, you *can* manage without it, but getting the edge cases right is messy), or you can say "here's this new syntax, and it allows us to do this, this, and this, which otherwise wouldn't be possible". Given how common parameterized decorators are, it's likely there'll be some support for at least the broad concept of the proposal. ChrisA [1] At least, I'm pretty sure it is; I may be wrong. -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
On 04/27, Makoto Kuwata wrote: > > I feel that function decorator having arguments is complicated, > because three 'def' are nested: > > def multiply(n): > def deco(func): > def newfunc(*args, **kwargs): > return n * func(*args, **kwargs) > return newfunc > return deco When I have to write an argument-taking decorator, I use a class: class multiply(object): # don't need 'object in 3.x' def __init__(self, n): self.n = n def __call__(self, func): def newfunc(*args, **kwargs): return self.n * func(*args, **kwargs) return newfunc > @multiply(4) > def f1(x, y): > return x+y > > print(f1(2, 3)) #=> 20 (= 4 * (2+3)) This all works the same. > > > If function decorator notation could take arguments, > decorator definition would be more simple: > > def multiply(func, n): > def newfunc(*args, **kwargs): > return n * func(*args, **kwargs) > return newfunc > > @multiply 4 # ex: @decorator arg1, arg2, arg3 > def f1(x, y): > return x+y > > > How do you think about this idea? It's unnecessary, just use a class instead of a function to get more clarity. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
On Mon, Apr 27, 2015 at 2:24 PM, Ethan Furman wrote: > On 04/27, Makoto Kuwata wrote: >> >> I feel that function decorator having arguments is complicated, >> because three 'def' are nested: >> >> def multiply(n): >> def deco(func): >> def newfunc(*args, **kwargs): >> return n * func(*args, **kwargs) >> return newfunc >> return deco > > When I have to write an argument-taking decorator, I use a class: > > class multiply(object): # don't need 'object in 3.x' > > def __init__(self, n): > self.n = n > > def __call__(self, func): > def newfunc(*args, **kwargs): > return self.n * func(*args, **kwargs) > return newfunc What's the advantage of that over a simple closure? You have the same number of nesting levels, plus a lot more boiler-plate repetition - instead of just referencing names from the outer scope, you have to explicitly capture them all with "self.n=n" for each one. I'm not sure you really even gain much clarity. In a way, a closure is a short-hand for an object with a __call__ method that auto-captures all its local variables. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
On 04/27, Chris Angelico wrote: > On Mon, Apr 27, 2015 at 2:24 PM, Ethan Furman wrote: > > On 04/27, Makoto Kuwata wrote: > >> > >> I feel that function decorator having arguments is complicated, > >> because three 'def' are nested: > >> > >> def multiply(n): > >> def deco(func): > >> def newfunc(*args, **kwargs): > >> return n * func(*args, **kwargs) > >> return newfunc > >> return deco > > > > When I have to write an argument-taking decorator, I use a class: > > > > class multiply(object): # don't need 'object in 3.x' > > > > def __init__(self, n): > > self.n = n > > > > def __call__(self, func): > > def newfunc(*args, **kwargs): > > return self.n * func(*args, **kwargs) > > return newfunc > > What's the advantage of that over a simple closure? You have the same > number of nesting levels, plus a lot more boiler-plate repetition - > instead of just referencing names from the outer scope, you have to > explicitly capture them all with "self.n=n" for each one. I'm not sure > you really even gain much clarity. > > In a way, a closure is a short-hand for an object with a __call__ > method that auto-captures all its local variables. I find it much easier to keep track of what is going on, especially in those cases where there is pre-, post-, or both, processing going on. YMMV. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
On Mon, Apr 27, 2015 at 2:45 PM, Ethan Furman wrote: >> What's the advantage of that over a simple closure? You have the same >> number of nesting levels, plus a lot more boiler-plate repetition - >> instead of just referencing names from the outer scope, you have to >> explicitly capture them all with "self.n=n" for each one. I'm not sure >> you really even gain much clarity. >> >> In a way, a closure is a short-hand for an object with a __call__ >> method that auto-captures all its local variables. > > I find it much easier to keep track of what is going on, especially in > those cases where there is pre-, post-, or both, processing going on. > > YMMV. Perhaps in the complicated cases, but in the common and simple case that the OP's talking about (where the purpose of the outermost function is solely to capture arguments for the next level in), I wouldn't bother with a class. But as you say, YMMV. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Function decorator having arguments is complicated
(Redirecting to the list - hope you don't mind) On Mon, Apr 27, 2015 at 2:36 PM, Makoto Kuwata wrote: > > > On Mon, Apr 27, 2015 at 12:20 PM, Chris Angelico wrote: >> >> >> I agree it would be nice to have extra parameters directly handled, >> but before you go further with the proposal, I suggest having a read >> of the original PEP that introduced decorators: >> >> https://www.python.org/dev/peps/pep-0318/ >> > > Thanks, it is an useful link. > But I can't find any sentence related to the problem what I argued. Correct, it doesn't specifically say you can't propose this; I'm just saying it's good to know how we got here before proposing to go further. > I found the following example code in PEP318: > >> def accepts(*types): >> def check_accepts(f): >> assert len(types) == f.func_code.co_argcount >> def new_f(*args, **kwds): >> for (a, t) in zip(args, types): >> assert isinstance(a, t), \ >>"arg %r does not match %s" % (a,t) >> return f(*args, **kwds) >> new_f.func_name = f.func_name >> return new_f >> return check_accepts > > But nobody seems to mention the complication of the above code. > > >> >> There are a *lot* of different ways that decorators could have been >> done. Currently, decorators use a restricted subset of expression >> syntax; the bit after the @ is guaranteed [1] to be a valid expression >> which results in a callable which is passed one argument (the >> function) and whose return value replaces the function. What you >> propose would no longer be a valid expression, and may introduce >> parsing problems for the interpreter and/or for humans. > > > Do you mean that it is too difficult to extend python syntax? Yes; not impossible, but any change to syntax has to be very strongly justified. >> But if the writing of decorators is hard and common for you, you can >> always use a bit of metaprogramming to simplify it. > > > It is not so hard for me to read/write complicated decorator, > but it is hard for young Python programmer those who I'm teaching Python. > (And it is hard for me to explain them about complicated decorator.) > > It would be very good for both me and young Python programmer > if decorator having arguments could be described in non-complicated code. > > # Meta decorator programming is not the solution I hope. > # It introduces another complex. Maybe, but you could just give your students a black-box module that makes life easier for them - the "modify" or "decorator" function could be in there. Or you could do what I do with my students, and simply start from the simplest decorators and build up. It's usually not hard to describe a simple hard-coded decorator (always does the same thing), then a simple wrapping decorator (calls the original function, returns a wrapper), and then add parameters after that. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Tit for tat
On Sunday, April 26, 2015 at 6:41:08 PM UTC-7, Seymore4Head wrote: > Richard Dawkins explains with passion the idea of game theory and tit > for tat, or why cooperation with strangers is often a strong strategy. > > He talks of a computer program tournament. I don't know what I could > say that would be more interesting than just watching the video. Well, I'm not sure sure what any of this has to do with Python -- but since I know something about the subject, I'll reply. That Richard Dawkins video is quite old -- it would appear to be from the middle 1980's. Douglas Hofstadter's 1985 book, _Metamagical_Themas_, covered this exact same material. A game called the "Iterated Prisoner's Dilemma" is played (I'll abbreviate it as IPD). Humans can play, of course, but in this case it is played by algorithms. An algorithm called "Tit for Tat" is surprisingly simple and robust. When meeting a new contestant, Tit for Tat plays nice in round 1; and on every subsequent round, it plays however that opponent played the last time. Evolutionary biologists like Dawkins point to the success of Tit for Tat in IPD as a model of how cooperation could emerge in a population of selfish organisms. Now, in a round-robin IPD game, Tit for Tat wins pretty handily. But in some other scenarios, as I recall, Tit for Tat is not a runaway winner. Suppose that instead of each strategy playing EVERY other, each strategy inhabits a "territory" in a space, and each strategy only plays its neighbors. In "rough neighborhoods", Tit for Tat can lose out to more punitive strategies. If Tit for Tat is around more cooperative strategies, it thrives. The boundaries between good neighborhoods and bad are chaotic. Tit for Tat more or less holds the borders, but usually can't clean out a bad neighborhood. This finding came out many years after the Hofstadter and Dawkins reports, so it's not covered in the video. My reference to the idea is a 1997 paper entitled "The Undecidability of the Spatialized Prisoner's Dilemma," by Patrick Grim (http://link.springer.com/article/10.1023%2FA%3A1004959623042). -- https://mail.python.org/mailman/listinfo/python-list
Re: Tit for tat
Following up to myself... Here's a link to Patrick Grim's results that you can actually download (Springer really retains a 1997 research paper behind a paywall?): http://www.pgrim.org/pgrim/SPATIALP.HTM -- https://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for Python
Am 27.04.15 um 01:06 schrieb Chris Angelico: On Mon, Apr 27, 2015 at 6:26 AM, Ben Finney wrote: It doesn't have to. By using the newer ‘tkinter.ttk’ library https://docs.python.org/3/library/tkinter.ttk.html>, the GUI will use native look-and-feel widgets. Does the new library also deal with the ongoing issues with Unicode support? AIUI there's some fundamental problem with Tkinter which means that (possibly only on Windows?) non-BMP characters simply can't be displayed. No. That is a fundamental limit in Tcl 8 (it uses UCS-2 to store strings), and will probably only addressed in Tcl 9. ttk addresses mostly the theming issue and is now "8 years new" (Tk 8.5a6) with a precursor (Tile) from ten years ago. To me, that's a pretty bad flaw - we should be aiming new projects at complete Unicode support, which means Python 3 and a good GUI toolkit. YMMV. Is non-BMP needed for any living non-esoteric language? I agree that it is a big flaw, but still is useful for very many projects. Christian -- https://mail.python.org/mailman/listinfo/python-list
