Re: bash command, get stdErr
Il Thu, 25 Aug 2011 01:52:25 -0700, Chris Rebert ha scritto:
> On Thu, Aug 25, 2011 at 1:25 AM, Tracubik wrote:
>> Hi all!
cut
> Untested:
>
> from subprocess import Popen, PIPE sudo = Popen("sudo las", shell=True,
> stderr=PIPE)
> tee = Popen(["tee", "/dev/stderr"], stdin=sudo.stderr, stdout=PIPE)
> # Read from tee.stdout to get any error messages
>
> Further info: http://en.wikipedia.org/wiki/Tee_%28command%29
>
> Cheers,
> Chris
mmm, it doesn't seem to work... any other hints guys?
--
http://mail.python.org/mailman/listinfo/python-list
Re: bash command, get stdErr
On Fri, Aug 26, 2011 at 12:56 AM, Tracubik wrote:
> Il Thu, 25 Aug 2011 01:52:25 -0700, Chris Rebert ha scritto:
>> On Thu, Aug 25, 2011 at 1:25 AM, Tracubik wrote:
>>> Hi all!
>
> cut
>
>> Untested:
>>
>> from subprocess import Popen, PIPE sudo = Popen("sudo las", shell=True,
>> stderr=PIPE)
>> tee = Popen(["tee", "/dev/stderr"], stdin=sudo.stderr, stdout=PIPE)
>> # Read from tee.stdout to get any error messages
>>
>> Further info: http://en.wikipedia.org/wiki/Tee_%28command%29
>
> mmm, it doesn't seem to work...
How so? Seems to work in an admittedly dirt simple test where I do
tee.stdout.read().
You might need to fiddle with buffering settings depending on how
you're processing the output.
Cheers,
Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: bash command, get stdErr
Il Thu, 25 Aug 2011 08:25:59 +, Tracubik ha scritto:
> Hi all!
> i'ld like to execute via Python this simple bash command:
>
> sudo las
>
> las is intended to be a typo for "ls"
>
> the point is that i want to see in the terminal the stderr message (that
> is "sorry, try again" if i insert the wrong password or "sudo: las:
> command not found" otherwise)
>
> i can simply do it with subprocess.POpen() or subprocess.Call() but as
> far as i know i have two choice:
> 1) s = subprocess.Popen('sudo las', shell=True, stderr=subprocess.PIPE)
>
> in this way i catch the stderr messages BUT they are not "printed" in
> the terminal
>
> 2) s = subprocess.Popen('sudo las', shell=True, stderr=none)
> in this way i "print" the message in the terminal but i can retrieve
> they (the error messages) when the command is executed
maybe i've solved it:
sudo las 2>&1 | tee tmp.txt
in this way i redirect stderr to stdout (the terminal) and i tee it in
tmp.txt.
The only problem is the output and error messages are joined togheter but
i think i can deal with it.
:-D
MedeoTL
--
http://mail.python.org/mailman/listinfo/python-list
How to handle application level errors
Hi Guys, Not sure if this is the place to ask, but I am trying find out a way to handle application level errors from a global config. Any help would be really appreciated. Regards, Nav -- http://mail.python.org/mailman/listinfo/python-list
Re: bash command, get stdErr
Il Fri, 26 Aug 2011 01:20:02 -0700, Chris Rebert ha scritto:
> On Fri, Aug 26, 2011 at 12:56 AM, Tracubik wrote:
>> Il Thu, 25 Aug 2011 01:52:25 -0700, Chris Rebert ha scritto:
>>> On Thu, Aug 25, 2011 at 1:25 AM, Tracubik wrote:
Hi all!
>>
>> cut
>>
>>> Untested:
>>>
>>> from subprocess import Popen, PIPE sudo = Popen("sudo las",
>>> shell=True,
>>> stderr=PIPE)
>>> tee = Popen(["tee", "/dev/stderr"], stdin=sudo.stderr, stdout=PIPE)
>>> # Read from tee.stdout to get any error messages
>>>
>>> Further info: http://en.wikipedia.org/wiki/Tee_%28command%29
>>
>> mmm, it doesn't seem to work...
>
> How so? Seems to work in an admittedly dirt simple test where I do
> tee.stdout.read().
> You might need to fiddle with buffering settings depending on how you're
> processing the output.
oh, yeah! now it work thanks!
don't really know why it wasn't working yesterday, i've retried today and
it work very well :-D
MedeoTL
--
http://mail.python.org/mailman/listinfo/python-list
Re: PUT with proxy-support
Running pycurl-7.19.0/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-2ZCa8v/pycurl-7.19.0/egg-dist-tmp-DyHFls
Using curl-config (libcurl 7.12.1)
src/pycurl.c:42:20: Python.h: No such file or directory
src/pycurl.c:43:22: pythread.h: No such file or directory
src/pycurl.c:58:4: #error "Need Python version 2.2 or greater to
compile pycurl."
src/pycurl.c:61:4: #error "Need libcurl version 7.19.0 or greater to
compile pycurl."
[... Error Clipped]
error: Setup script exited with error: command '/usr/bin/gcc' failed
with exit status 1
I'm not familiar with red hat. But looks like this is now a sysadmin
problem. I could install pycurl under freebsd and ubuntu too.
I have some code that might be able to PUT through a proxy for you.
Please look at the attached file.
You can setup a proxy this way:
import MozzillaEmulator
MozzillaEmulator.DEFAULT_PROXIES = {
'http':'http://user:passw...@proxy.host.com:3128',
'https':'http://user:passw...@proxy.host.com:3128',
}
And here is how you use it:
dl = MozillaEmulator.MozillaEmulator()
put_url = "http://some_url_to_put_to";
headers = {'Content-Type':'application/xml;charset=UTF-8'}
data = open("some_file","rb").read()
response = dl.download(put_url,data,headers,put_method=True)
If you don't set the put_method flag, then it will POST instead. (But in
that case, post data must be a valid post data field fields and values.)
If you don't give post_data then it will GET. The PUT method was tested
without a proxy, and the GET and POST methods were tested with and
without proxy.
Actually I have tried to do PUT through a proxy, but it didn't work. But
it was a restriction on the proxy side. (As far as I can recall, the
error message came from the proxy server, something about unsupported
request?). So it *might* work for you, with the right proxy server that
supports PUT requests.
Also be aware that this version uses urllib2. Although it can use https
protocol, it doesn't check the server's certificate.
Good luck,
Laszlo
#--
#
# Author: Laszlo Nagy
#
# Copyright: (c) 2005 by Szoftver Messias Bt.
# Licence: BSD style
#
# Setup urllib so it will use Mozilla user agent settings.
#
#
#--
import os
import hashlib
import urllib
import urllib2
import mimetypes
#from gzip import GzipFile
import cStringIO
from cPickle import loads,dumps
import cookielib
DEFAULT_PROXIES = None
class MozillaCacher(object):
"""A dictionary like object, that can cache results on a storage device."""
def __init__(self,cachedir='.cache'):
self.cachedir = cachedir
if not os.path.isdir(cachedir):
os.mkdir(cachedir)
def name2fname(self,name):
return os.path.join(self.cachedir,name)
def __getitem__(self,name):
if not isinstance(name,str):
raise TypeError()
fname = self.name2fname(name)
if os.path.isfile(fname):
return file(fname,'rb').read()
else:
raise IndexError()
def __setitem__(self,name,value):
if not isinstance(name,str):
raise TypeError()
fname = self.name2fname(name)
if os.path.isfile(fname):
os.unlink(fname)
f = file(fname,'wb+')
try:
f.write(value)
finally:
f.close()
def __delitem__(self,name):
if not isinstance(name,str):
raise TypeError()
fname = self.name2fname(name)
if os.path.isfile(fname):
os.unlink(fname)
def __iter__(self):
raise NotImplementedError()
def has_key(self,name):
return os.path.isfile(self.name2fname(name))
class MozillaEmulator(object):
def __init__(self,cacher={},trycount=0,proxies=None):
"""Create a new MozillaEmulator object.
@param cacher: A dictionary like object, that can cache search results on a storage device.
You can use a simple dictionary here, but it is not recommended.
You can also put None here to disable caching completely.
@param trycount: The download() method will retry the operation if it fails. You can specify -1 for infinite retrying.
A value of 0 means no retrying. A value of 1 means one retry. etc.
:param proxies: It must be a dict like this:
{
'http': 'http://user:pas...@www.example.com:3128/',
'https': 'http://user:pas...@www.example.com:3128/',
}
If you pass None then DEFAULT_PROXIES will be used. To force
direct connection, use an empty dict.
This is a simplified version of urllib2 proxy handling.
To use direct connection, call with proxies=None.
Look at the example here:
http://docs.python.org/release/2.5.2/lib/urllib2-examp
Re: is there any principle when writing python function
In article , t...@thsu.org wrote: > On Aug 23, 7:59 am, smith jack wrote: > > i have heard that function invocation in python is expensive, but make > > lots of functions are a good design habit in many other languages, so > > is there any principle when writing python function? > > for example, how many lines should form a function? > > My suggestion is to think how you would test the function, in order to > get 100% code coverage. I'm not convinced 100% code coverage is an achievable goal for any major project. I was once involved in a serious code coverage program. We had a large body of code (100's of KLOC of C++) which we were licensing to somebody else. The customer was insisting that we do code coverage testing and set a standard of something like 80% coverage. There was a dedicated team of about 4 people working on this for the better part of a year. They never came close to 80%. More like 60%, and that was after radical surgery to eliminate dead code and branches that couldn't be reached. The hard parts are testing the code that deals with unusual error conditions caused by interfaces to the external world. The problem is, it's just damn hard to simulate all the different kinds of errors that can occur. This was network intensive code. Every call that touches the network can fail in all sorts of ways that are near impossible to simulate. We also had lots of code that tried to deal with memory exhaustion. Again, that's hard to simulate. I'm not saying code coverage testing is a bad thing. Many of the issues I mention above could have been solved with additional abstraction layers, but that adds complexity of its own. Certainly, designing a body of code to be testable from the get-go is a far superior to trying to retrofit tests to an existing code base (which is what we were doing). > The parts of the function that are difficult > to test, those are the parts that you want to pull out into their own > separate function. > > For example, a block of code within a conditional statement, where the > test condition cannot be passed in, is a prime example of a block of > code that should be pulled out into a separate function. Maybe. In general, it's certainly true that a bunch of smallish functions, each of which performs exactly one job, is easier to work with than a huge ball of spaghetti code. On the other hand, interfaces are a common cause of bugs. When you pull a hunk of code out into its own function, you create a new interface. Sometimes that adds complexity (and bugs) of its own. > Obviously, there are times where this is not practical - exception > handling comes to mind - but that should be your rule of thumb. If a > block of code is hard to test, pull it out into it's own function, so > that it's easier to test. In general, that's good advice. You'll also usually find that code which is easy to test is also easy to understand and easy to modify. -- http://mail.python.org/mailman/listinfo/python-list
Mastering Python... Best Resources?
I know the Python syntax pretty well. I know a lot of the libraries and tools. When I see professional Python programmer's code, I am often blown away with the code. I realized that even though I know the language, I know nothing about using it effectively. I would like to start using Python more in my professional career. Where can I find resources that will take my skills to the next level? I would prefer to watch a streaming video series, if possible. I've read quite a few books about Python. They cover a lot of topics, but none of them covered common conventions or hacks. I mean, I got good at C++ reading books by Scott Meyers, who concentrated on common idioms, things to avoid, the proper way to do things, etc. Right now, I am at that point where I know how to do write just about anything in the language. However, I still have that hesitation I get when I'm just not sure what's the right way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Fri, Aug 26, 2011 at 10:33 PM, Travis Parks wrote: > I know the Python syntax pretty well. I know a lot of the libraries > and tools. When I see professional Python programmer's code, I am > often blown away with the code. I realized that even though I know the > language, I know nothing about using it effectively. I would say that there are three aspects to using Python effectively: 1) Understanding the syntax, which you've mastered. 2) Understanding the philosophy 3) Knowing algorithms. The second is more or less what you're asking for, but the language-independent third may be more useful to you. This is correct Python syntax (#1), and decently Pythonic style (#2), but a hopelessly flawed algorithm (#3): def fib(x): return fib(x-1) + fib(x-2) if x>2 else 1 Or: def fib(x): if x<3: return 1 return fib(x-1) + fib(x-2) Both versions are clean and easy to read, but neither would be what I'd call brilliant code. You can get books on algorithms from all sorts of places, and with a very few exceptions, everything you learn with apply to Python and also to every other language you use. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: PUT with proxy-support
On Fri, Aug 26, 2011 at 3:15 PM, Laszlo Nagy wrote:
> Running pycurl-7.19.0/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-2ZCa8v/**pycurl-7.19.0/egg-dist-tmp-**DyHFls
>
>> Using curl-config (libcurl 7.12.1)
>> src/pycurl.c:42:20: Python.h: No such file or directory
>> src/pycurl.c:43:22: pythread.h: No such file or directory
>> src/pycurl.c:58:4: #error "Need Python version 2.2 or greater to compile
>> pycurl."
>> src/pycurl.c:61:4: #error "Need libcurl version 7.19.0 or greater to
>> compile pycurl."
>> [... Error Clipped]
>> error: Setup script exited with error: command '/usr/bin/gcc' failed with
>> exit status 1
>>
> I'm not familiar with red hat. But looks like this is now a sysadmin
> problem. I could install pycurl under freebsd and ubuntu too.
>
> I have some code that might be able to PUT through a proxy for you. Please
> look at the attached file.
>
> You can setup a proxy this way:
>
> import MozzillaEmulator
> MozzillaEmulator.DEFAULT_**PROXIES = {
>
> 'http':'http://user:password@**proxy.host.com:3128
> ',
>
> 'https':'http://user:password@**proxy.host.com:3128
> ',
> }
>
> And here is how you use it:
>
> dl = MozillaEmulator.**MozillaEmulator()
> put_url = "http://some_url_to_put_to";
> headers = {'Content-Type':'application/**xml;charset=UTF-8'}
> data = open("some_file","rb").read()
> response = dl.download(put_url,data,**headers,put_method=True)
>
> If you don't set the put_method flag, then it will POST instead. (But in
> that case, post data must be a valid post data field fields and values.) If
> you don't give post_data then it will GET. The PUT method was tested without
> a proxy, and the GET and POST methods were tested with and without proxy.
>
> Actually I have tried to do PUT through a proxy, but it didn't work. But it
> was a restriction on the proxy side. (As far as I can recall, the error
> message came from the proxy server, something about unsupported request?).
> So it *might* work for you, with the right proxy server that supports PUT
> requests.
>
> Also be aware that this version uses urllib2. Although it can use https
> protocol, it doesn't check the server's certificate.
>
>
>
Mozilla Emulator works like a charm.
Also managed to install pycurl and the same works too.
Thanks. :)
~Shashwat
--
http://mail.python.org/mailman/listinfo/python-list
Re: Learning python reading software source code
Thanks Michael :) . I will keep your suggestions in mind. On Fri, Aug 26, 2011 at 9:01 AM, Chetan Harjani wrote: > Hello friends, > > I have learned the basic syntax of python through the book HOW TO THINK > LIKE A COMPUTER SCIENTIST n by reading first 10-11 chapters of > Apress-BEGINNING PROGRAMMING FROM NOVICE TO PROFESSIONAL. > (btw it was really very boring) > > I am looking forward to learn further by understanding source code of > applications built in python. I guess i will begin with reading the source > code of MIRO http://www.getmiro.com/ . > > So I am looking for suggestions on how one can understand the code better. > Any specific references I should look in as I stumble upon libraries n > functions while reading or just the python official docs would be enough? > > thanking you > -- > Chetan H Harjani > > > -- Chetan H Harjani -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
Chris Angelico wrote: [ ... ] > You can get books on algorithms from all sorts of places, and with a > very few exceptions, everything you learn with apply to Python and > also to every other language you use. I liked _Programming Pearls_ by Jon Bentley. No reference to Python -- that would be the O.P.'s job. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Aug 26, 8:44 am, Chris Angelico wrote: > On Fri, Aug 26, 2011 at 10:33 PM, Travis Parks wrote: > > I know the Python syntax pretty well. I know a lot of the libraries > > and tools. When I see professional Python programmer's code, I am > > often blown away with the code. I realized that even though I know the > > language, I know nothing about using it effectively. > > I would say that there are three aspects to using Python effectively: > > 1) Understanding the syntax, which you've mastered. > 2) Understanding the philosophy > 3) Knowing algorithms. > > The second is more or less what you're asking for, but the > language-independent third may be more useful to you. This is correct > Python syntax (#1), and decently Pythonic style (#2), but a hopelessly > flawed algorithm (#3): > > def fib(x): > return fib(x-1) + fib(x-2) if x>2 else 1 > > Or: > > def fib(x): > if x<3: return 1 > return fib(x-1) + fib(x-2) > > Both versions are clean and easy to read, but neither would be what > I'd call brilliant code. > > You can get books on algorithms from all sorts of places, and with a > very few exceptions, everything you learn with apply to Python and > also to every other language you use. > > ChrisA > > Well, I think I am going more for #2. I know about things like data structures and algorithms... in your case memoization. Here is a good example of what I am talking about. Someone took the time to write quicksort in a single line of code: def qsortr(list): return [] if list==[] else qsortr([x for x in list[1:] if x < list[0]]) + [list[0]] + qsortr([x for x in list[1:] if x >= list[0]]) I would never even think to use list comprehensions and splicing like that. I would write this code the same way I'd write it in C++/C#. I'm aware that writing code like the above example is probably bad practice (and that the implementation here has some major inefficiencies), but it is the "mentality" that goes into it. I haven't gotten to the point where I can truly use the language features to my full advantage. I haven't seen enough "tricks" to be effective. I feel like there is so much of the language I am not utilizing because I'm still thinking in terms of a less powerful language. I was hoping to find a series that would familiarize me with how real Python programmers get things done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Fri, Aug 26, 2011 at 10:58 PM, Travis Parks wrote: > I haven't gotten to the point where I can truly use the language > features to my full advantage. I haven't seen enough "tricks" to be > effective. I feel like there is so much of the language I am not > utilizing because I'm still thinking in terms of a less powerful > language. I was hoping to find a series that would familiarize me with > how real Python programmers get things done. > Ah! Then I recommend poking around with the standard library. No guarantees that it's ALL good code, but it probably will be. In any case, it sounds like you're well able to evaluate code in your own head and recognize the good from the ugly. In the source distribution (I'm looking at the latest straight from hg, but presumably it's the same everywhere), there's a whole lot of .py files in ./Lib - there's sure to be some good examples in there somewhere. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Fri, Aug 26, 2011 at 2:28 PM, Chris Angelico wrote: > On Fri, Aug 26, 2011 at 10:58 PM, Travis Parks > wrote: > > I haven't gotten to the point where I can truly use the language > > features to my full advantage. I haven't seen enough "tricks" to be > > effective. I feel like there is so much of the language I am not > > utilizing because I'm still thinking in terms of a less powerful > > language. I was hoping to find a series that would familiarize me with > > how real Python programmers get things done. > > > > Ah! Then I recommend poking around with the standard library. No > guarantees that it's ALL good code, but it probably will be. In any > case, it sounds like you're well able to evaluate code in your own > head and recognize the good from the ugly. > > In the source distribution (I'm looking at the latest straight from > hg, but presumably it's the same everywhere), there's a whole lot of > .py files in ./Lib - there's sure to be some good examples in there > somewhere. > > ChrisA > As a rule of thumb, I have learnt to always make the python source my best resource. > -- > http://mail.python.org/mailman/listinfo/python-list > -- Odeyemi 'Kayode O. http://www.sinati.com. t: @charyorde -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Aug 26, 9:28 am, Chris Angelico wrote: > On Fri, Aug 26, 2011 at 10:58 PM, Travis Parks wrote: > > I haven't gotten to the point where I can truly use the language > > features to my full advantage. I haven't seen enough "tricks" to be > > effective. I feel like there is so much of the language I am not > > utilizing because I'm still thinking in terms of a less powerful > > language. I was hoping to find a series that would familiarize me with > > how real Python programmers get things done. > > Ah! Then I recommend poking around with the standard library. No > guarantees that it's ALL good code, but it probably will be. In any > case, it sounds like you're well able to evaluate code in your own > head and recognize the good from the ugly. > > In the source distribution (I'm looking at the latest straight from > hg, but presumably it's the same everywhere), there's a whole lot of > .py files in ./Lib - there's sure to be some good examples in there > somewhere. > > ChrisA > > I've been thinking about going through the docs on the main website. Cool thing is it has links to the actual lib files. I was checking out string.py yesterday. I was searching all over youtube for good videos of some type. Google has an intro course, but it didn't really do much for me. Microsoft has these series called 'Going Deep' that occasionally runs something super in-depth. The videos on C++ and the STL are really excellent. I was hoping someone had taken the time to create a similar series for Python. I can't help but remember my one professor in college, who really made pointers, bitwise arithmetic and low level OS operations make sense. He explained to us a lot about how the STL worked and showed us tons of C++/STL hacks. I probably learned more in the 2 years I had classes with him than I have in all the time I've programmed. To get that type of insight into another language, like Python, would be the ultimate gift for someone like me. Personally, I am tired of working in languages that don't strongly support functional paradigms. -- http://mail.python.org/mailman/listinfo/python-list
Python IDE/Eclipse
I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any suggestions? I use Eclipse for other projects and have no problem with using it for Python, except that I can't get PyDev to install. It takes forever, then produces an error that makes no sense. An error occurred while installing the items session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null --> [R]org.eclipse.cvs 1.0.400.v201002111343, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Cannot connect to keystore. This trust engine is read only. The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. Any suggestions on getting this to work? Thanks, Dave -- http://mail.python.org/mailman/listinfo/python-list
dpkg
I downloaded cx_oracle for installation to Ubuntu 11.04 64bit this morning, and the alien and dpkg operations worked fine, but on testing the import, the error msg shows that the oracle client lib is missing. I found a thread that mentioned installing the oracle instant client on 11.04 to resolve this, and alien and dpkg worked fine. Yet, when I go into python (runing 2.7) and import cx_Oracle, I get "ImportError: libclntsh.so.11.1: cannot open shared object file: No such file or directory. Looking for this with find / -name libclntsh.so.11.1 -print produces /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 I'm confused as to why Python doesn't see it... -- http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
In article
<2309ec4b-e9a3-4330-9983-1c621ac16...@ea4g2000vbb.googlegroups.com>,
Travis Parks wrote:
> I know the Python syntax pretty well. I know a lot of the libraries
> and tools. When I see professional Python programmer's code, I am
> often blown away with the code. I realized that even though I know the
> language, I know nothing about using it effectively.
In a sense, I'm in the same boat as you. I've been using Python since
before the 2.0 series, and I tend to think of the language in much the
same way as I did back then. Which is to say I don't use the language,
as it currently exists, as effectively as I might.
Here's some things I suggest you look at:
Iterators. This is such a powerful concept. When I started with the
language, iterators largely meant the difference between range() and
xrange(). Now we've got a whole ecosystem which has grown up around
them (x + " comprehension" for x in {'list', 'dictionary', 'set'}), not
to mention generators and generator expressions. And the itertools
library.
Decorators. Another powerful concept. We use these in our web servers
for all sorts of cool things. Adding cacheing. Imposing prerequisites
on route calls. I still don't think of using these immediately, but I
do see the notational convenience they provide for many things.
Context Managers. One of the (very few) things that I always found
lacking in Python compared to C++ was deterministic object destruction.
Context managers give you this. I'm still exploring all the neat things
you can do with them.
The full range of containers. I started with lists, tuples, and
dictionaries. Now we've got sets, frozensets, named tuples, deques,
Counters, defaultdicts (I love those), heaps, and I'm sure a few others
I've missed. List and dicts are such well designed containers, you can
do almost anything with just those two, but all the other new ones often
make things quicker, simpler, and more obvious.
The profiler. Most people obsess about performance early on and don't
realize that most of their guesses about what's fast and what's slow are
probably wrong. Learn to use the profiler and understand what it's
telling you.
Unittest. Testing is, in general, a neglected practice in most software
development shops, and that's a shame. Python has some really good
capabilities to support testing which you should get familiar with.
Unittest is just one of them. There's also doctest, nose, and a bunch
of other contributed modules. Look at them all, learn at least one of
them well, and use it for everything you write.
> I've read quite a few books about Python. They cover a lot of topics,
> but none of them covered common conventions or hacks. I mean, I got
> good at C++ reading books by Scott Meyers, who concentrated on common
> idioms, things to avoid, the proper way to do things, etc.
Ugh. The problem with Meyers's books is that they are needed in the
first place. C++ is such a horribly complicated language, you really
can't use it without making a serious study of it. There's too many
gotchas that you MUST know to avoid disaster with even the most basic
programs.
Python isn't that way. You can learn a small, basic subset of the
language and get a lot done. You may not be doing things the most
effective way, but you're also not going to be looking at memory
corruption because you didn't understand the details of object lifetimes
or how type promotion, function overloading, and implicit temporary
object construction all interact.
--
http://mail.python.org/mailman/listinfo/python-list
Re: dpkg
On Fri, Aug 26, 2011 at 10:43 AM, Verde Denim wrote: > Looking for this with find / -name libclntsh.so.11.1 -print produces > /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 > > I'm confused as to why Python doesn't see it... Try running "sudo ldconfig". -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
I've honestly always used either PyDev or IDLE. However, Python is pretty easy to usd without a big IDE slowing you down, so you could also use a developer's text editor like Notepad++ or gedit and still be good. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 6:15 am, Roy Smith wrote: > Maybe. In general, it's certainly true that a bunch of smallish > functions, each of which performs exactly one job, is easier to work > with than a huge ball of spaghetti code. Obviously you need to google the definition of "spaghetti code". When you move code out of one function and create another function you are contributing to the "spaghetti-ness" of the code. Think of plate of spaghetti and how the noodles are all intertwined and without order. Likewise when you go to one function and have to follow the trial of one or more helper functions you are creating a twisting and unordered progression of code -- sniff-sniff, do you smell what i smell? Furthermore: If you are moving code out of one function to ONLY be called by that ONE function then you are a bad programmer and should have your editor taken away for six months. You should ONLY create more func/methods if those func/methods will be called from two or more places in the code. The very essence of func/meths is the fact that they are reusable. It might still be spaghetti under that definition (of which ALL OOP code actually is!) however it will be as elegant as spaghetti can be. > On the other hand, interfaces > are a common cause of bugs. When you pull a hunk of code out into its > own function, you create a new interface. Sometimes that adds > complexity (and bugs) of its own. Which is it? You cannot have it both ways. You're straddling the fence here like a dirty politician. Yes, this subject IS black and white! -- http://mail.python.org/mailman/listinfo/python-list
Re: dpkg
On Fri, Aug 26, 2011 at 11:17 AM, Ken Watford wrote: > On Fri, Aug 26, 2011 at 10:43 AM, Verde Denim wrote: > > Looking for this with find / -name libclntsh.so.11.1 -print produces > > /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 > > > > I'm confused as to why Python doesn't see it... > > Try running "sudo ldconfig". > That was the missing link - thanks! works fine now. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
I like Aptana Studio http://www.aptana.com/products/studio3 2011/8/26 Dave Boland : > I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any > suggestions? > > I use Eclipse for other projects and have no problem with using it for > Python, except that I can't get PyDev to install. It takes forever, then > produces an error that makes no sense. > > An error occurred while installing the items > session context was:(profile=PlatformProfile, > phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, > operand=null --> [R]org.eclipse.cvs 1.0.400.v201002111343, > action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). > Cannot connect to keystore. > This trust engine is read only. > The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was > not found. > > > Any suggestions on getting this to work? > > Thanks, > Dave > -- > http://mail.python.org/mailman/listinfo/python-list > -- Atte. Moisés Alberto Lindo Gutarra Asesor - Desarrollador Java / Open Source Linux Registered User #431131 - http://counter.li.org/ Cel: (511) 995081720 - Rpm: *548913 EMail: mli...@gmail.com MSN: mli...@tumisolutions.com -- http://mail.python.org/mailman/listinfo/python-list
Unit test failing please help
Hi I am new to python I am at bit lost as to why my unit test is
failing below is the code and the unit test:
class Centipede(object):
legs, stomach
def __init__(self):
def __str__(self):
return ','.join(self.stomach)
def __call__(self,*args):
[self.stomach.append(arg) for arg in args]
#self.stomach.append(args)
def __repr__(self):
return ','.join(self.legs)
def __setattr__(self, key, value):
print("setting %s to %s" % (key, repr(value)))
if key in ([]):
self.legs.append(key)
super(Centipede, self).__setattr__(self, key,value)
unit test code:
import unittest
from centipede import Centipede
class TestBug(unittest.TestCase):
def test_stomach(self):
ralph = Centipede()
ralph('chocolate')
ralph('bbq')
ralph('cookies')
ralph('salad')
self.assertEquals(ralph.__str__(),
'chocolate,bbq,cookies,salad')
def test_legs(self):
ralph = Centipede()
ralph.friends = ['Steve', 'Daniel', 'Guido']
ralph.favorite_show = "Monty Python's Flying Circus"
ralph.age = '31'
self.assertEquals(ralph.__repr__(),'' )
if __name__ == "__main__":
unittest.main()
error message generated when running the test:
AttributeError: 'Centipede' object has no attribute 'legs'
AttributeError: 'Centipede' object has no attribute 'stomach'
Any suggestions as to where I am going wrong?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Mastering Python... Best Resources?
On Aug 26, 11:12 am, Roy Smith wrote:
> In article
> <2309ec4b-e9a3-4330-9983-1c621ac16...@ea4g2000vbb.googlegroups.com>,
> Travis Parks wrote:
>
> > I know the Python syntax pretty well. I know a lot of the libraries
> > and tools. When I see professional Python programmer's code, I am
> > often blown away with the code. I realized that even though I know the
> > language, I know nothing about using it effectively.
>
> In a sense, I'm in the same boat as you. I've been using Python since
> before the 2.0 series, and I tend to think of the language in much the
> same way as I did back then. Which is to say I don't use the language,
> as it currently exists, as effectively as I might.
>
> Here's some things I suggest you look at:
>
> Iterators. This is such a powerful concept. When I started with the
> language, iterators largely meant the difference between range() and
> xrange(). Now we've got a whole ecosystem which has grown up around
> them (x + " comprehension" for x in {'list', 'dictionary', 'set'}), not
> to mention generators and generator expressions. And the itertools
> library.
>
> Decorators. Another powerful concept. We use these in our web servers
> for all sorts of cool things. Adding cacheing. Imposing prerequisites
> on route calls. I still don't think of using these immediately, but I
> do see the notational convenience they provide for many things.
>
> Context Managers. One of the (very few) things that I always found
> lacking in Python compared to C++ was deterministic object destruction.
> Context managers give you this. I'm still exploring all the neat things
> you can do with them.
>
> The full range of containers. I started with lists, tuples, and
> dictionaries. Now we've got sets, frozensets, named tuples, deques,
> Counters, defaultdicts (I love those), heaps, and I'm sure a few others
> I've missed. List and dicts are such well designed containers, you can
> do almost anything with just those two, but all the other new ones often
> make things quicker, simpler, and more obvious.
>
> The profiler. Most people obsess about performance early on and don't
> realize that most of their guesses about what's fast and what's slow are
> probably wrong. Learn to use the profiler and understand what it's
> telling you.
>
> Unittest. Testing is, in general, a neglected practice in most software
> development shops, and that's a shame. Python has some really good
> capabilities to support testing which you should get familiar with.
> Unittest is just one of them. There's also doctest, nose, and a bunch
> of other contributed modules. Look at them all, learn at least one of
> them well, and use it for everything you write.
>
> > I've read quite a few books about Python. They cover a lot of topics,
> > but none of them covered common conventions or hacks. I mean, I got
> > good at C++ reading books by Scott Meyers, who concentrated on common
> > idioms, things to avoid, the proper way to do things, etc.
>
> Ugh. The problem with Meyers's books is that they are needed in the
> first place. C++ is such a horribly complicated language, you really
> can't use it without making a serious study of it. There's too many
> gotchas that you MUST know to avoid disaster with even the most basic
> programs.
>
> Python isn't that way. You can learn a small, basic subset of the
> language and get a lot done. You may not be doing things the most
> effective way, but you're also not going to be looking at memory
> corruption because you didn't understand the details of object lifetimes
> or how type promotion, function overloading, and implicit temporary
> object construction all interact.
>
>
Thanks for the input.
I had been writing my Compass project (http://compass.codeplex.com) in
Pythonese. I was planning on implementing a lot of the features of MS'
LINQ in Python iterators, too. I am surprised that there aren't a ton
of Python libraries for general purpose algorithms. "yield" is one of
my favorite keywords. :-)
I will take a look at decorators especially. I see them being used for
properties and other coolness. I started playing with unittest the
other day.
unittest.main(exit=False) <-- took me a while to find
I will look at the containers, too. I have been trying to push tuple
syntax support in C# for years now. Named tuples are so useful.
I agree that C++ is too complicated. Bjarne should have cared less
about backward compatibility with C and fixed some of the issues with
it. He should have also made some of the defaults more intuitive -
like ctor initializers being reorganized to the same order as the
backing fields... that'll getcha. Function argument order evaluation.
Oh no! It might run .1 seconds slower on a Sparc machine! I think
anal programmers like me gravitate towards C++ because we like to show
how smart we are by naming off some arbitrary fact. Sure, it doesn't
make development any better, but it gives us something to waste memory
with. I find my
Re: is there any principle when writing python function
In <7b47ca17-d3f1-4d91-91d1-98421e870...@ea4g2000vbb.googlegroups.com>
rantingrick writes:
> Furthermore: If you are moving code out of one function to ONLY be
> called by that ONE function then you are a bad programmer and should
> have your editor taken away for six months. You should ONLY create
> more func/methods if those func/methods will be called from two or
> more places in the code. The very essence of func/meths is the fact
> that they are reusable.
That's one very important aspect of functions, yes. But there's another:
abstraction.
If I'm writing a module that needs to fetch user details from an LDAP
server, it might be worthwhile to put all of the LDAP-specific code in
its own method, even if it's only used once. That way the main module
can just contain a line like this:
user_info = get_ldap_results("cn=john gordon,ou=people,dc=company,dc=com")
The main module keeps a high level of abstraction instead of descending
into dozens or even hundreds of lines of LDAP-specific code.
--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
On Aug 26, 2011 11:39 AM, "Moises Alberto Lindo Gutarra" wrote: > > I like Aptana Studio > http://www.aptana.com/products/studio3 > FYI, Aptana is just a set of extensions for Eclipse. Aptana Studio is just Eclipse with all of the Aptana extensions (including PyDev) preinstalled. > 2011/8/26 Dave Boland : > > I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any > > suggestions? > > > > I use Eclipse for other projects and have no problem with using it for > > Python, except that I can't get PyDev to install. It takes forever, then > > produces an error that makes no sense. > > > > An error occurred while installing the items > > session context was:(profile=PlatformProfile, > > phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, > > operand=null --> [R]org.eclipse.cvs 1.0.400.v201002111343, > > action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). > > Cannot connect to keystore. > > This trust engine is read only. > > The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was > > not found. > > > > > > Any suggestions on getting this to work? > > > > Thanks, > > Dave > > -- > > http://mail.python.org/mailman/listinfo/python-list > > > > > > -- > Atte. > Moisés Alberto Lindo Gutarra > Asesor - Desarrollador Java / Open Source > Linux Registered User #431131 - http://counter.li.org/ > Cel: (511) 995081720 - Rpm: *548913 > EMail: mli...@gmail.com > MSN: mli...@tumisolutions.com > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
Furthermore: If you are moving code out of one function to ONLY be called by that ONE function then you are a bad programmer and should have your editor taken away for six months. You should ONLY create more func/methods if those func/methods will be called from two or more places in the code. The very essence of func/meths is the fact that they are reusable. While I understand and agree with that basic tenet, I think that the capitalized 'ONLY' is too strong. I do split out code into function for readability, even when the function will only be called from the place from which I split it out. I don't think that this adds to the 'spaghetti' factor. It can make my life much easier when I go to debug my own code years later. In python, I use a small function to block out an idea as a sort of pseudo code, although it's valid python. Then I just define the supporting functions, and the task is done: def validate_registrants(): for dude in get_registrants(): id = get_id(dude) amount_paid = get_amount_paid(dude) amount_owed = get_amount_owed(dude) if amount_paid != amount_owed(): flag(dude) I get that this cries out for a 'dude' object, but I'm just making a point. When I go back to this code, I can very quickly see what the overall flow is, and jump to the problem area by function name. The above block might expand to a couple of hundred lines if I didn't split it out like this. -- http://mail.python.org/mailman/listinfo/python-list
Hot Bollwood Actresses and Hot Football Players of Spain Soccer Team
Hot Bollywood Actresses and Hot Football Players of Spain Nation Soccer Team. http://bollywoodactresseshotdresses.blogspot.com/ http://spainnationalfootballteamwallpapers.blogspot.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Unit test failing please help
In lblake
writes:
> Hi I am new to python I am at bit lost as to why my unit test is
> failing below is the code and the unit test:
> class Centipede(object):
> legs, stomach
You aren't assigning any values to "legs" or "stomach" here. From your
later code, it seems like you intend these items to start out as empty
lists. This code might work better:
class Centipede(object):
legs = []
stomach = []
(In fact, since you aren't *assigning* anything to legs or stomach but
you're simply *referencing them*, this code should have been an error
because those names do not yet exist.)
> def __init__(self):
This __init__() method does nothing at all. It doesn't even have a pass
statement, which means it isn't legal python. Your code should have
produced an error here.
> def __setattr__(self, key, value):
> print("setting %s to %s" % (key, repr(value)))
> if key in ([]):
> self.legs.append(key)
> super(Centipede, self).__setattr__(self, key,value)
How will this if statement ever be true? You're checking if 'key' is
a member of an empty list.
--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Design principles: no bool arguments
Ian Kelly wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Both variants work (even in Py3) if you only define [a named argument].
>> You have to define [a keyword argument, e.g. `kwargs'].
>>
>> so that
>>
>> data1.merge_with(data2, True);
>>
>> is a syntax error ("TypeError: merge_with() takes exactly 2 arguments (3
>> given)").
>>
>> IOW, this advantage of Python in readability is not only caused by API
>> definition, but also by how the API is used. It might turn into a
>> disadvantage if key lookups make the code expensive memory- and runtime
>> wise.
>>
>> And you will still have to know the underlying signature to name the
>> argument. Worse, with keyword arguments you *have to* look up the
>> documentation (i. e., it needs to be well-documented as well) to know its
>> name (as the compiler can only tell you "kwargs").
>
> Note though that Python 3 adds actual keyword-only arguments, which
> address all of your points:
>
> class Data:
> def merge_with(self, bar, *, overwrite_duplicates):
> pass
>
data1.merge_with(data2, True)
> TypeError: merge_with() takes exactly 2 positional arguments (3 given)
data1.merge_with(data2)
> TypeError: merge_with() needs keyword-only argument overwrite_duplicates
data1.merge_with(data2, overwrite_duplicates=True)
That's good to know. Thanks.
> Of course, in Python 2 that definition would be a syntax error, so you
> can't really take advantage of it if you need compatibility.
ACK.
Regards,
--
PointedEars
Bitte keine Kopien per E-Mail. / Please do not Cc: me.
--
http://mail.python.org/mailman/listinfo/python-list
Why PyImport_ExecCodeModule takes char*?
Hi, I'm wondering, why PyImport_ExecCodeModule function takes char* instead of const char*? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Sat, Aug 27, 2011 at 1:48 AM, Tobiah wrote: > While I understand and agree with that basic tenet, I think > that the capitalized 'ONLY' is too strong. I do split out > code into function for readability, even when the function > will only be called from the place from which I split it out. > This can be good and can be bad. It's good when it aids readability; it's bad when you need to pass practically the entire locals() as function arguments and/or return values. I would split the function only when both halves (caller and callee) can be given short and useful names - if you can't explain what a block of code does in a few words, it's probably a poor choice for splitting out into a function. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
You can get a lot done, if not everything, with a simple editor however for me an IDE is awesome for digging around in the django internals to see how it all works. I used PyDev initially then onto emacs but finally I settled on PyCharm - it's just like PyDev except that everything works. Stuart I like Aptana Studio http://www.aptana.com/products/studio3 2011/8/26 Dave Boland : I'm looking for a good IDE -- easy to setup, easy to use -- for Python. Any suggestions? I use Eclipse for other projects and have no problem with using it for Python, except that I can't get PyDev to install. It takes forever, then produces an error that makes no sense. An error occurred while installing the items session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null --> [R]org.eclipse.cvs 1.0.400.v201002111343, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). Cannot connect to keystore. This trust engine is read only. The artifact file for osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. Any suggestions on getting this to work? Thanks, Dave -- http://mail.python.org/mailman/listinfo/python-list -- Atte. Moisés Alberto Lindo Gutarra Asesor - Desarrollador Java / Open Source Linux Registered User #431131 - http://counter.li.org/ Cel: (511) 995081720 - Rpm: *548913 EMail: mli...@gmail.com MSN: mli...@tumisolutions.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Unit test failing please help
On Fri, 2011-08-26 at 08:35 -0700, lblake wrote: > Hi I am new to python I am at bit lost as to why my unit test is > failing below is the code and the unit test: > > class Centipede(object): > legs, stomach This doesn't do what you think it does. "legs, stomach" is a statement and is not defining any variables at all. Presumably you've also got variables named legs and stomach in the module's scope - as I'd expect to see a NameError : name 'legs' is not defined. (I'd also expect a SyntaxError from having an empty __init__ function body) You probably want do write something like this: class Centipede(object): def __init__(self): self.legs = [] self.stomach = [] -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE/Eclipse
Dave Boland wrote: > I'm looking for a good IDE -- easy to setup, easy to use -- for Python. > Any suggestions? PyDev (currently 2.2.1.2011073123, from the Aptana Studio 3.0.4 Plugin; but I can see that 2.2.2 has been released). > I use Eclipse for other projects and have no problem with using it for > Python, except that I can't get PyDev to install. It takes forever, > then produces an error that makes no sense. > > An error occurred while installing the items >session context was:(profile=PlatformProfile, > phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, > operand=null --> [R]org.eclipse.cvs 1.0.400.v201002111343, > action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction). >Cannot connect to keystore. >This trust engine is read only. >The artifact file for > osgi.bundle,org.eclipse.cvs,1.0.400.v201002111343 was not found. > > > Any suggestions on getting this to work? Your Eclipse version is apparently a bit old (note the build/sign date of the requested CVS package). Although PyDev is documented to work with Eclipse 3.2 to 3.7, try a newer version (but make a backup of your workspace before). Indigo (3.7) was released on 2011-06-22 CE. The corresponding CVS package version is (perhaps with updates) 3.3.400.I20110510-0800. If you use PyDev from Aptana, you have to uninstall standalone PyDev first. I can still recommend using Aptana for Eclipse 3.7 on GNU/Linux, where it is running without problems so far. However, in Eclipse 3.7 on Windows 7, after the latest Aptana update (3.0.4), PDT collided in their Content-Type settings with Aptana PHP Editor, so I had to uninstall the Aptana plugin in order to get any PHP editor working again. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
Tobiah wrote:
>
>> Furthermore: If you are moving code out of one function to ONLY be
>> called by that ONE function then you are a bad programmer and should
>> have your editor taken away for six months. You should ONLY create
>> more func/methods if those func/methods will be called from two or
>> more places in the code. The very essence of func/meths is the fact
>> that they are reusable.
>
> While I understand and agree with that basic tenet, I think
> that the capitalized 'ONLY' is too strong. I do split out
> code into function for readability, even when the function
> will only be called from the place from which I split it out.
In other words, you disagree. Which is good, because the text you quote is
terrible advice, and it is ironic that the person you quote judges others
as bad programmers when his advice is so bad.
I can think of at least five reasons apart from re-use why it might be
appropriate to pull out code into its own function or method even if it is
used in one place only:
(1) Extensibility. Just earlier today I turned one method into three:
def select(self):
response = input(self)
if response:
index = self.find(response)
else:
index = self.default
return self.menuitems[index-1]
turned into:
def choose(self, response):
if response:
index = self.find(response)
else:
index = self.default
return self.menuitems[index-1]
def raw_select(self):
return input(self)
def select(self):
return self.choose(self.raw_select())
I did this so that subclasses could override the behaviour of each component
individually, even though the caller is not expected to call raw_select or
choose directly. (I may even consider making them private.)
(2) Testing. It is very difficult to reach into the middle of a function and
test part of it. It is very difficult to get full test coverage of big
monolithic blocks of code: to ensure you test each path through a big
function, the number of test cases rises exponentially. By splitting it
into functions, you can test each part in isolation, which requires much
less work.
(3) Fault isolation. If you have a 100 line function that fails on line 73,
that failure may have been introduced way back in line 16. By splitting the
function up into smaller functions, you can more easily isolate where the
failure comes from, by checking for violated pre- and post-conditions.
(4) Maintainability. It's just easier to document and reason about a
function that does one thing, than one that tries to do everything. Which
would you rather work with, individual functions for:
buy_ingredients
clean_kitchen_work_area
wash_vegetables
prepare_ingredients
cook_main_course
fold_serviettes
make_desert
serve_meal
do_washing_up
etc., or one massive function:
prepare_and_serve_five_course_meal
Even if each function is only called once, maintenance is simpler if the
code is broken up into more easily understood pieces.
(5) Machine efficiency. This can go either way. Code takes up memory too,
and it may be easier for the compiler to work with 1000 small functions
than 1 big function. I've actually seen somebody write a single function so
big that Python couldn't import the module, because it ran out of memory
trying to compile it! (This function was *huge* -- the source code was many
megabytes in size.) I don't remember the details, but refactoring the
source code into smaller functions fixed it.
On the other hand, if you are tight for memory, 1 big function may have less
overhead than 1000 small functions; and these days, with even entry level
PCs often having a GB or more of memory, it is rare to come across a
function so big that the size of code matters. Even a 10,000 line function
is likely to be only a couple of hundred KB in size:
>>> text = '\n'.join('print x+i' for i in range(1, 10001))
>>> code = compile(text, '', 'exec')
>>> sys.getsizeof(code.co_code) # size in bytes
90028
So that's four really good reasons for splitting code into functions, and
one borderline one, other than code re-use. There may be others.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Record seperator
Is there an equivelent for the AWK RS in Python? as in RS='\n\n' will seperate a file at two blank line intervals -- maus . . ... NO CARRIER -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 10:40 am, John Gordon wrote:
> In <7b47ca17-d3f1-4d91-91d1-98421e870...@ea4g2000vbb.googlegroups.com>
> rantingrick writes:
>
> > Furthermore: If you are moving code out of one function to ONLY be
> > called by that ONE function then you are a bad programmer and should
> > have your editor taken away for six months. You should ONLY create
> > more func/methods if those func/methods will be called from two or
> > more places in the code. The very essence of func/meths is the fact
> > that they are reusable.
>
> That's one very important aspect of functions, yes. But there's another:
> abstraction.
> [...]
> The main module keeps a high level of abstraction instead of descending
> into dozens or even hundreds of lines of LDAP-specific code.
Exactly. I am not arguing against creating intuitive and
simplistically elegant interfaces. I mean, lists *could* have only one
method called apply(process, *args, **kw) which takes an argument like
("append", "value") or ("index", 42) and has a long block of logic to
handle the inputs however that would be a horrible interface.
So in that respect i agree. We must weigh the entire interface from an
empirical perspective. However i can be sure of one point: As you
increase the number of methods you also increase the mental load
required to understand that particular interface.
An interface with a small number of methods will not suffer too
terribly from one or two extra methods however at some point more
methods just equals more confusion. It is a delicate balancing act
that many programmers are not agile enough to juggle elegantly.
Take for instance the interface for Grep, Search, and Replace dialogs
in the idlelib which span two separate modules and have a mind numbing
number of methods for such remedial things as creating buttons and
entrys. All three dialogs look very similar and share many
similarities.
Now take a look at MY simple ONE module solution. It has JUST enough
methods and NOT a single more! Yes the create widgets method is fairly
long (weighing in at 80+ lines with comments!) however all of this
code needs to be contained in ONE and ONLY one method. Heck if i
wanted to get pendantic i could replace the five cb_*() methods with
partials however MY interface is so intuitive there is no need.
# START CODE
class FindReplaceDialog(object):
def __init__(self, textbox):
[...]
def create_widgets(self, type_):
# Create toplevel dialog window.
[...]
# Create widgets belonging to both
# search AND replace dialogs dialogs.
[...]
if type_ == 'replace':
# Add widgets unique to replace
# dialogs.
[...]
elif type_ == 'grep':
# Add widgets unique to grep
# dialogs.
[...]
# Load any initial values and states.
[...]
def show(self, type_='find'):
self.create_widgets(type_)
# Do any initial setup.
def close(self, event=None):
# destroy the dialog.
def find_again(self, event=None):
# Event callback bound to textbox.
def find(self, target):
# Search the buffer for target and
# hilight if found.
def replace(self, action='replace'):
# Fetch the old and new strings and
# mediate the work depending on the
# action.
[...]
if action == 'replace+find':
[...]
elif action == 'replaceall':
[...]
def grep():
[...]
def cb_grepbutton(self, event=None):
self.grep(target.entry.get())
def cb_findbutton(self, event=None):
self.find(target.entry.get())
def cb_replacebutton(self):
self.replace(action='replace')
def cb_replacefindbutton(self):
self.replace(action='replace+find')
def cb_replaceallbutton(self):
self.replace(action='replaceall')
# END CODE
Now look at the three modules in idlelib (Grep Dialog, Search Dialog,
and Replace Dialog) and ask yourself which is cleaner? Which is more
intuiitve? Which is more professional? Which would you rather debug?
*scholl-bell-rings*
--
http://mail.python.org/mailman/listinfo/python-list
Re: Record seperator
On 26 Aug 2011 18:39:07 GMT
greymaus wrote:
>
> Is there an equivelent for the AWK RS in Python?
>
>
> as in RS='\n\n'
> will seperate a file at two blank line intervals
open("file.txt").read().split("\n\n")
--
D'Arcy J.M. Cain | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
--
http://mail.python.org/mailman/listinfo/python-list
Catch and name an exception in Python 2.5 +
In Python 3, you can catch an exception and bind it to a name with: try: ... except ValueError, KeyError as error: pass In Python 2.5, that is written: try: ... except (ValueError, KeyError), error: pass and the "as error" form gives a SyntaxError. Python 2.6 and 2.7 accept either form. Is there any way to catch an exception and bind it to a name which will work across all Python versions from 2.5 onwards? I'm pretty sure there isn't, but I thought I'd ask just in case. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Catch and name an exception in Python 2.5 +
On 26/08/11 21:56, Steven D'Aprano wrote: > In Python 3, you can catch an exception and bind it to a name with: > > try: > ... > except ValueError, KeyError as error: > pass > > In Python 2.5, that is written: > > try: > ... > except (ValueError, KeyError), error: > pass > > and the "as error" form gives a SyntaxError. > > Python 2.6 and 2.7 accept either form. > > Is there any way to catch an exception and bind it to a name which will work > across all Python versions from 2.5 onwards? > > I'm pretty sure there isn't, but I thought I'd ask just in case. It's not elegant, and I haven't actually tested this, but this should work: try: ... except (ValueError, KeyError): error = sys.exc_info()[2] -- Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Sat, Aug 27, 2011 at 4:05 AM, rantingrick wrote: > Now take a look at MY simple ONE module solution. It has JUST enough > methods and NOT a single more! I disagree - create_widgets() is completely unnecessary in the presence of show(), unless it's possible to show the dialog, hide it, and then re-show it without recreating the widgets. On Sat, Aug 27, 2011 at 4:16 AM, Steven D'Aprano wrote: > I can think of at least five reasons apart from re-use why it might be > appropriate to pull out code into its own function or method even if it is > used in one place only: I'm glad you say "might be", because your five reasons aren't always reasons for refactoring. I'll play devil's advocate for a moment, because discussion is both fun and informative: :) > (1) Extensibility. Just earlier today I turned one method into three: > I did this so that subclasses could override the behaviour of each component > individually, even though the caller is not expected to call raw_select or > choose directly. (I may even consider making them private.) Definitely, but it's no value if you make every tiny thing into your own function. Sometimes the best way to code is to use lower-level functionality directly (not wrapping input() inside raw_select() for instance), and letting someone monkey-patch if they want to change your code. A judgment call. > (2) Testing. It is very difficult to reach into the middle of a function and > test part of it. ... By splitting it > into functions, you can test each part in isolation, which requires much > less work. Yes, but 100% coverage isn't that big a deal. If the function does precisely one logical thing, then you don't _need_ to test parts in isolation - you can treat it as a black box and just ensure that it's doing the right thing under various circumstances. However, this ties in nicely with your next point... > (3) Fault isolation. If you have a 100 line function that fails on line 73, > that failure may have been introduced way back in line 16. By splitting the > function up into smaller functions, you can more easily isolate where the > failure comes from, by checking for violated pre- and post-conditions. ... and here's where #2 really shines. If you break your function in two, the natural thing to do is to test each half separately, with the correct preconditions, and examine its output. If your fault was on line 16, your test for that half of the function has a chance of detecting it. I don't have a Devil's Advocate put-down for this one, save the rather weak comment that it's possible to check pre- and post-conditions without refactoring. :) > (4) Maintainability. It's just easier to document and reason about a > function that does one thing, than one that tries to do everything. Which > would you rather work with, individual functions for: > ... omnomnom ... > Even if each function is only called once, maintenance is simpler if the > code is broken up into more easily understood pieces. Yes, as long as you do the job intelligently. Goes back to what I said about naming functions - in your kitchen example, every function has a self-documenting name, which means you've broken it out more-or-less correctly. (I'd still want to have prepare_and_serve_five_course_meal() of course, but it would be calling on all the others.) Breaking something out illogically doesn't help maintainability at all - in fact, it'll make it worse. "So this function does what, exactly? And if I need to add a line of code, ought I to do it here, or over there? Does anyone else actually call this function? MIGHT someone be reaching into my module and calling this function directly? I'd better keep it... ugh." > (5) Machine efficiency. This can go either way. And that's the very best thing to say about efficiency. Ever. In C, I can write static functions and let the compiler inline them; in Java, I tried to do the same thing, and found ridiculous overheads. Ended up making a monolith rather than go through Java's overhead. But if I'd changed what VM I was running it on, that might well have changed. Profile, profile, profile. > So that's four really good reasons for splitting code into functions, and > one borderline one, other than code re-use. There may be others. I'm sure there are. But let's face it: We're programming in PYTHON. Not C, not Erlang, not Pike, not PHP. Python. If this has been the right choice, then we should assume that efficiency isn't king, but readability and maintainability probably are; so the important considerations are not "will it take two extra nanoseconds to execute" but "can my successor understand what the code's doing" and "will he, if he edits my code, have a reasonable expectation that he's not breaking stuff". These are always important. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
The RAISE_VARARGS opcode in Python 3
Hi all, Here is an extract from the dis module doc [1] """ RAISE_VARARGS(argc) Raises an exception. argc indicates the number of parameters to the raise statement, ranging from 0 to 3. The handler will find the traceback as TOS2, the parameter as TOS1, and the exception as TOS. """ OTOH, looking at PEP 3109: """ In Python 3, the grammar for raise statements will change from [2] raise_stmt: 'raise' [test [',' test [',' test]]] to raise_stmt: 'raise' [test] """ So it seems that RAISE_VARARGS's argument can only be 0 or 1 in Python 3, whereas it could be up to 3 in Python 2. Can anyone confirm that this is the case? In this case, I guess the dis docs need to be updated. Thank you, Arnaud [1] http://docs.python.org/py3k/library/dis.html#opcode-RAISE_VARARGS [2] http://www.python.org/dev/peps/pep-3109/#grammar-changes -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 4:45 pm, Chris Angelico wrote:
> On Sat, Aug 27, 2011 at 4:05 AM, rantingrick wrote:
> > Now take a look at MY simple ONE module solution. It has JUST enough
> > methods and NOT a single more!
>
> I disagree - create_widgets() is completely unnecessary in the
> presence of show(),
Well since you cannot see the underlying code i won't be too harsh on
you :), but yes, i can assure you that create widgets IS necessary for
readability. show() calls "self.create_widgets()" then adds a special
hit tag to the text widget and sets up a modal behavior of the dialog,
it's only 5-7 lines of setup code but i think the separation is
warranted.
Could i have rolled all the create_widgets() code into the show()
method? Of course, however i do see a good reason for separation here
for the sake of readability. Although i must admit, had the interface
been much larger i most assuredly would have rolled it together.
> unless it's possible to show the dialog, hide it,
> and then re-show it without recreating the widgets.
Yes the instance lives on between session to save state. Also the
"find_again" binding of the text widget calls the
SearchReplaceDialog.find_again() method when {CONTROL+G} event fires.
> I'm sure there are. But let's face it: We're programming in PYTHON.
> Not C, not Erlang, not Pike, not PHP. Python. If this has been the
> right choice, then we should assume that efficiency isn't king, but
> readability and maintainability probably are; so the important
> considerations are not "will it take two extra nanoseconds to
> execute" but "can my successor understand what the code's doing" and
> "will he, if he edits my code, have a reasonable expectation that
> he's not breaking stuff". These are always important.
Bravo! That has to be most lucid and intelligent statement from you to
date. And i must say the warm fuzzies i got from imagining the defeat
D'Aprano must have felt whist reading it left me with a nice feeling.
How do like them apples, D'Aprano? :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 26, 1:16 pm, Steven D'Aprano wrote: > (3) Fault isolation. If you have a 100 line function that fails on line 73, > that failure may have been introduced way back in line 16. By splitting the > function up into smaller functions, you can more easily isolate where the > failure comes from, by checking for violated pre- and post-conditions. What's wrong Steven, are track backs too complicated for you? # START DUMMY SCRIPT def very_long_function(): max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(object) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) max(range(5)) # print 'blah' print 'blah' print 'blah-blah' very_long_function() # END DUMMY SCRIPT Traceback (most recent call last): File "C:/Python27/test3.py", line 48, in very_long_function() File "C:/Python27/test3.py", line 26, in very_long_function max(object) TypeError: 'type' object is not iterable Oh the humanity! -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
Chris Angelico wrote: > On Sat, Aug 27, 2011 at 4:16 AM, Steven D'Aprano > wrote: >> I can think of at least five reasons apart from re-use why it might be >> appropriate to pull out code into its own function or method even if it >> is used in one place only: > > I'm glad you say "might be", because your five reasons aren't always > reasons for refactoring. I'll play devil's advocate for a moment, > because discussion is both fun and informative: :) Naturally :) I say "might be" because I mean it: these arguments have to be weighed up against the argument against breaking code out of functions. It's easy to imagine an extreme case where there are a billion *tiny* functions, each of which does one micro-operation: def f1(x): return x + 1 def f2(x): return 3*x def f3(x): return f2(f1(x)) # instead of 3*(x+1) ... If spaghetti code (GOTOs tangled all through the code with no structure) is bad, so is ravioli code (code bundled up into tiny parcels and then thrown together higgledy-piggledy). Both cases can lead to an unmaintainable mess. Nobody is arguing that "More Functions Is Always Good". Sensible coders understand that you should seek a happy medium and not introduce more functions just for the sake of having More! Functions!. But I'm not arguing with you, we're in agreement. One last comment though: [...] > Definitely, but it's no value if you make every tiny thing into your > own function. Sometimes the best way to code is to use lower-level > functionality directly (not wrapping input() inside raw_select() for > instance), and letting someone monkey-patch if they want to change > your code. A judgment call. I agree on the first part (don't split *everything* into functions) but I think that the monkey-patch idea is tricky and dangerous in practice. The first problem is, how do you know what needs to be monkey-patched? You may not have access to the source code to read, and it may not be as obvious as "oh, it gets input from the user, so it must be calling input()". Second, even if you know what to monkey-patch, it's really hard to isolate the modification to just the method you want. By their nature, monkey- patches apply globally to the module. And if you patch the builtins module, they apply *everywhere*. So while monkey-patching can work, it's tricky to get it right and it should be left as a last resort. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Sat, Aug 27, 2011 at 11:26 AM, Steven D'Aprano wrote: > I say "might be" because I mean it: these arguments have to be weighed up > against the argument against breaking code out of functions. It's easy to > imagine an extreme case where there are a billion *tiny* functions, each of > which does one micro-operation: > > def f1(x): return x + 1 > def f2(x): return 3*x > def f3(x): return f2(f1(x)) # instead of 3*(x+1) This fails the "give it a decent name" test. Can you name these functions according to what they do, as opposed to how they do it? For instance: def add_flagfall(x): return x + 1 # add a $1 flagfall to the price def add_tax(x): return 3*x # this is seriously nasty tax def real_price(x): return add_tax(add_flagfall(x)) # instead of 3*(x+1) This would be acceptable, because each micro-operation has real meaning. I'd prefer to do it as constants rather than functions, but at least they're justifying their names. And you're absolutely right about monkey-patching. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Catch and name an exception in Python 2.5 +
Thomas Jollans wrote: > On 26/08/11 21:56, Steven D'Aprano wrote: >> Is there any way to catch an exception and bind it to a name which will >> work across all Python versions from 2.5 onwards? >> >> I'm pretty sure there isn't, but I thought I'd ask just in case. > > It's not elegant, and I haven't actually tested this, but this should > work: > > try: > ... > except (ValueError, KeyError): > error = sys.exc_info()[2] Great! Thanks for that, except I think you want to use [1], not [2]. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The RAISE_VARARGS opcode in Python 3
Arnaud Delobelle wrote:
> Here is an extract from the dis module doc [1]
>
> """
> RAISE_VARARGS(argc)
> Raises an exception. argc indicates the number of parameters to the
> raise statement, ranging from 0 to 3. The handler will find the
> traceback as TOS2, the parameter as TOS1, and the exception as TOS.
> """
>
> OTOH, looking at PEP 3109:
>
> """
> In Python 3, the grammar for raise statements will change from [2]
>
> raise_stmt: 'raise' [test [',' test [',' test]]]
> to
>
> raise_stmt: 'raise' [test]
> """
>
> So it seems that RAISE_VARARGS's argument can only be 0 or 1 in Python
> 3, whereas it could be up to 3 in Python 2.
It can be up to 2 in Python 3,
>>> help("raise")
>>>
The ``raise`` statement
***
raise_stmt ::= "raise" [expression ["from" expression]]
...
confirmed by a quick look into ceval.c:
TARGET(RAISE_VARARGS)
v = w = NULL;
switch (oparg) {
case 2:
v = POP(); /* cause */
case 1:
w = POP(); /* exc */
case 0: /* Fallthrough */
why = do_raise(w, v);
break;
default:
PyErr_SetString(PyExc_SystemError,
"bad RAISE_VARARGS oparg");
why = WHY_EXCEPTION;
break;
}
break;
> Can anyone confirm that
> this is the case? In this case, I guess the dis docs need to be
> updated.
Indeed.
--
http://mail.python.org/mailman/listinfo/python-list
