Re: My first ever Python program, comments welcome
Lipska the Kat wrote:
> Greetings Pythoners
>
> A short while back I posted a message that described a task I had set
> myself. I wanted to implement the following bash shell script in Python
>
> Here's the script
>
> sort -nr $1 | head -${2:-10}
>
> this script takes a filename and an optional number of lines to display
> and sorts the lines in numerical order, printing them to standard out.
> if no optional number of lines are input the script prints 10 lines
>
> Here's the file.
>
> 50Parrots
> 12Storage Jars
> 6 Lemon Currys
> 2 Pythons
> 14Spam Fritters
> 23Flying Circuses
> 1 Meaning Of Life
> 123 Holy Grails
> 76Secret Policemans Balls
> 8 Something Completely Differents
> 12Lives of Brian
> 49Spatulas
>
>
> ... and here's my very first attempt at a Python program
> I'd be interested to know what you think, you can't hurt my feelings
> just be brutal (but fair). There is very little error checking as you
> can see and I'm sure you can crash the program easily.
> 'Better' implementations most welcome
> #! /usr/bin/env python3.2
>
> import fileinput
> from sys import argv
> from operator import itemgetter
>
> l=[]
> t = tuple
> filename=argv[1]
> lineCount=10
>
> with fileinput.input(files=(filename)) as f:
Note that (filename) is not a tuple, just a string surrounded by superfluous
parens.
>>> filename = "foo.bar"
>>> (filename)
'foo.bar'
>>> (filename,)
('foo.bar',)
>>> filename,
('foo.bar',)
You are lucky that FileInput() tests if its files argument is just a single
string.
> for line in f:
> t=(line.split('\t'))
> t[0]=int(t[0])
> l.append(t)
> l=sorted(l, key=itemgetter(0))
>
> try:
> inCount = int(argv[2])
> lineCount = inCount
> except IndexError:
> #just catch the error and continue
> None
>
> for c in range(lineCount):
> t=l[c]
> print(t[0], t[1], sep='\t', end='')
>
I prefer a more structured approach even for such a tiny program:
- process all commandline args
- read data
- sort
- clip extra lines
- write data
I'd break it into these functions:
def get_commmandline_args():
"""Recommended library: argparse.
Its FileType can deal with stdin/stdout.
"""
def get_quantity(line):
return int(line.split("\t", 1)[0])
def sorted_by_quantity(lines):
"""Leaves the lines intact, so you don't
have to reassemble them later on."""
return sorted(lines, key=get_quantity)
def head(lines, count):
"""Have a look at itertools.islice() for a more
general approach"""
return lines[:count]
if __name__ == "__main__":
# protecting the script body allows you to import
# the script as a library into other programs
# and reuse its functions and classes.
# Also: play nice with pydoc. Try
# $ python -m pydoc -w ./yourscript.py
args = get_commandline_args()
with args.infile as f:
lines = sorted_by_quantity(f)
with args.outfile as f:
f.writelines(head(lines, args.line_count))
Note that if you want to handle large files gracefully you need to recombine
sorted_by_quantity() and head() (have a look at heapq.nsmallest() which was
already mentioned in the other thread).
--
http://mail.python.org/mailman/listinfo/python-list
py2app bundling scikits-image etc.
Hey guys, didn't know where else to post so I thought I'd give this list a
shot. I've been googling a lot but hasn't been able to find any reasonable
answers.
I'm on a macbook running Lion trying to bundle a pretty extensive application
that's using:
* wxPython
* numpy
* scipy
* reportlab
I'm using python2.7 and py2app for the bundling and here's the setup.py file:
import ez_setup
ez_setup.use_setuptools()
from setuptools import setup
Plist={}
DATA_FILES = ['../rm_logo.jpg']
OPTIONS = {'argv_emulation': True,
'plist': Plist,
}
setup(
app=["../sasdm.py"],
data_files=DATA_FILES,
description="Description",
author="Author",
options={'py2app': OPTIONS},
setup_requires=["py2app"],
)
I've tried both
python setup.py py2app
and
sudo python setup.py py2app
The bundling always ends up failing with the message:
error: cannot copy tree
'/Library/Python/2.7/site-packages/skimage/data/chessboard_GRAY_U8.npz': not a
directory
I've confirmed that
"/Library/Python/2.7/site-packages/skimage/data/chessboard_GRAY_U8.npz" in fact
does exist.
I've installed the latest development version of scikits-image too but no
apparent difference there.
I appreciate any clues.
Regards
--
Nicklas Nordenmark
--
http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On 22/07/2012 03:55, rusi wrote: On Jul 22, 1:10 am, Dave Angel wrote: A totally off-the-wall query. Are you using a source control system, such as git ? It can make you much braver about refactoring a working program. Question in a similar vein: What development environment do you use? My impression is that the majority of pythonistas use a non-ide editor like vi or emacs Ive been using emacs for 20 years and python-mode of emacs is very useful but I am increasingly concerned that emacs is refusing to move with the times. Which is why I am particularly curious how an ol Java-head finds eclipse+python (http://pydev.org/ ) Wouldn't describe myself as "an ol Java-head" but I disliked eclipse 10 years ago. I tried it again earlier this year and still disliked it. It's like entering a legless cart horse for the Derby or the Grand National. YMMV. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On 21/07/12 21:10, Dave Angel wrote: On 07/21/2012 03:08 PM, Lipska the Kat wrote: Greetings Pythoners A short while back I posted a message that described a task I had set myself. I wanted to implement the following bash shell script in Python snip A totally off-the-wall query. Are you using a source control system, such as git ? It can make you much braver about refactoring a working program. Thanks for your comments, I've taken them on board, I'm most familiar with with cvs and svn for source control. I've also used Microsoft source safe. I generally just use what's given to me by whoever is paying me and don't worry too much about the details. Many in the Linux world seem to use git. Seeing as I've been using Linux at home since the early days of slackware I suppose I'd better look into it. Strangely enough I've never had a paid job using Linux. I've worked on multiuser UNIX systems and Sun Workstations but never Linux so I guess the need has never arisen. The Java world seems to largely use Maven to manage their code. It's a bit of a headbanger and I've never used it. Ant and FTP are my current faves at home. Primitive but good enough for my personal and business sites. Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On 7/22/2012 3:37 AM, Lipska the Kat wrote: > Many in > the Linux world seem to use git. Seeing as I've been using Linux at home > since the early days of slackware I suppose I'd better look into it. There are Mercurial (aka Hg) and Bazaar as well for DVCS. AFAIK, git, Mercurial, and Bazaar are all fine choices and the one to use will mainly boil down to personal preference. I prefer Mercurial myself. -- CPython 3.3.0b1 | Windows NT 6.1.7601.17803 -- http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On 22/07/12 03:55, rusi wrote: On Jul 22, 1:10 am, Dave Angel wrote: A totally off-the-wall query. Are you using a source control system, such as git ? It can make you much braver about refactoring a working program. Question in a similar vein: What development environment do you use? My impression is that the majority of pythonistas use a non-ide editor like vi or emacs Ive been using emacs for 20 years and python-mode of emacs is very useful but I am increasingly concerned that emacs is refusing to move with the times. My current 'Python development environment' is gedit with line numbering turned on and a terminal window to run chmodded scripts :-) Which is why I am particularly curious how an ol Java-head finds eclipse+python (http://pydev.org/ ) Python and eclipse ... Noo ;-) Well I have to say that I've used Eclipse with the myEclipse plugin for a number of years now and although it has it's moments it has earned me LOADS of MONEY so I can't really criticise it. I have Eclipse installed on a Windows box so I may try the plugin ... but actually I'm really enjoying doing things the 'old fashioned way' again. I'm going to do 'proper OO' version of the shell script to learn about wiring different modules together ... I find the official documentation hard to navigate though. Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Sudden doubling of nearly all messages
On 07/21/2012 12:48 PM, Dave Angel wrote: Has anybody else noticed the sudden double-posting of nearly all messages in the python mailing list? [snip] I'm using Thunderbird 14.0 on Linux 11.04, with mail configured for non-digest mode. I read the messages in threaded mode. I'm pretty sure it is Thunderbird-related -- I have had this issue before as well. Unfortunately, I cannot remember how I solved it. It seems like there was a particular box that needed to be checked or unchecked in the IMAP settings for the mail server, but I can't be sure anymore. Alan -- http://mail.python.org/mailman/listinfo/python-list
Re: py2app bundling scikits-image etc.
In article <8c0c74c9154346598227037a57d34...@gmail.com>, Nicklas Nordenmark wrote: > Hey guys, didn't know where else to post so I thought I'd give this list a > shot. I've been googling a lot but hasn't been able to find any reasonable > answers. Probably the best place to ask questions about py2app is on the Python Mac SIG list: http://www.python.org/community/sigs/current/pythonmac-sig/ -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Sudden doubling of nearly all messages
On 07/22/2012 05:30 AM, Alan Ristow wrote: > On 07/21/2012 12:48 PM, Dave Angel wrote: >> Has anybody else noticed the sudden double-posting of nearly all >> messages in the python mailing list? > [snip] >> I'm using Thunderbird 14.0 on Linux 11.04, with mail configured for >> non-digest mode. I read the messages in threaded mode. >> > I'm pretty sure it is Thunderbird-related -- I have had this issue > before as well. Unfortunately, I cannot remember how I solved it. It > seems like there was a particular box that needed to be checked or > unchecked in the IMAP settings for the mail server, but I can't be > sure anymore. > > Alan Thanks. But the problem appeared suddenly, and ended suddenly. And i didn't go into Account-settings or Preferences during that time. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On Sun, Jul 22, 2012 at 6:49 PM, Andrew Berg wrote: > On 7/22/2012 3:37 AM, Lipska the Kat wrote: >> Many in >> the Linux world seem to use git. Seeing as I've been using Linux at home >> since the early days of slackware I suppose I'd better look into it. > There are Mercurial (aka Hg) and Bazaar as well for DVCS. AFAIK, git, > Mercurial, and Bazaar are all fine choices and the one to use will > mainly boil down to personal preference. I prefer Mercurial myself. Agreed. I poked around with Bazaar a bit this year, and it seems to lack some features. But certainly hg and git are both excellent choices, with bzr not significantly far behind. I prefer git, personally; on Windows, though, I would recommend hg. Probably the best feature of any of them (one which, I believe, is now standard in all three) is 'bisect' with a command. It's "git bisect run", or "hg bisect -c", or "bzr bisect run". You can search back through a huge time period without any human interaction. I did that a while ago with a docs-building problem; the current state wouldn't successfully generate its docs from a fresh start, even though it could update them from a previous state. It took 45 minutes (!) of chuggity-chug compilation to find the actual cause of the problem, and no effort from me (since "make doc" already gave the right exit codes). Use source control now; you'll reap the benefits later! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On 22/07/2012, Lipska the Kat wrote: > On 21/07/12 21:10, Dave Angel wrote: >> >> A totally off-the-wall query. Are you using a source control system, >> such as git ? It can make you much braver about refactoring a working >> program. > > Thanks for your comments, I've taken them on board, > I'm most familiar with with cvs and svn for source control. I've also > used Microsoft source safe. I generally just use what's given to me by > whoever is paying me and don't worry too much about the details. Many in > the Linux world seem to use git. Seeing as I've been using Linux at home > since the early days of slackware I suppose I'd better look into it. What Dave said. I used CVS briefly and then git and its gui tools for last 5 years. Took me a while to get comfortable with it, but now it turns managing complex, evolving text files into fun and I cannot imagine working without its power and flexibility. First thing I do on any programming task: git init -- http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On 22/07/12 11:17, Chris Angelico wrote: On Sun, Jul 22, 2012 at 6:49 PM, Andrew Berg wrote: On 7/22/2012 3:37 AM, Lipska the Kat wrote: Many in the Linux world seem to use git. snip Use source control now; you'll reap the benefits later! from sudo apt-get install git to git add *.py was about 5 minutes and that included reading the basic documentation. POSITIVELY the fastest install and the least trouble from any source control app ever Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Looking for good tutorials after reading "Byte of Python"
My main goal is to do web development with Django/flask or another framework that suits me best. But I think that I should learn a bit more of Python before diving into a framework. I would like to know if anyone has some good tutorials like building a to-do list app or any other type of programs so I can learn by doing and also as a guiding kinda thing. Thanks in advance. P.S. excuse my poor english. -- http://mail.python.org/mailman/listinfo/python-list
Re: Sudden doubling of nearly all messages
On 21/07/2012 19:16, Rick Johnson wrote: [...] It's due to the new Google Groups interface. They started forcing everyone to use the new buggy version about a week ago EVEN THOUGH the old interface is just fine. I disagree - the old interface was dreadful and needed fixing. The new one is much worse, obviously. -- I have made a thing that superficially resembles music: http://soundcloud.com/eroneity/we-berated-our-own-crapiness -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for good tutorials after reading "Byte of Python"
On 22/07/12 15:48, Paulo wrote: My main goal is to do web development with Django/flask or another framework that suits me best. But I think that I should learn a bit more of Python before diving into a framework. I would like to know if anyone has some good tutorials like building a to-do list app or any other type of programs so I can learn by doing and also as a guiding kinda thing. Thanks in advance. P.S. excuse my poor english You may have already seen this but there is a tutorial on the python site http://docs.python.org/py3k/ (python3.2.3) There is also one at http://www.tutorialspoint.com/python/index.htm that looks like it could be worth reading Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On Sun, 22 Jul 2012 10:29:44 -0500, Tony the Tiger wrote: > Hi, > Is there such a thing in the language, or do I have to invent it myself? > > I came up with the following: > > # options.modus_list contains, e.g., "[2,3,4]" > # (a string from the command line) > # MODUS_LIST contains, e.g., [2,4,8,16] > # (i.e., a list of integers) > > if options.modus_list: > intTmp = [] > modTmp = options.modus_list[1:-1] > for itm in modTmp: > intTmp.append(int(itm)) > MODUS_LIST = intTmp > > There are probably never more than maybe between one to four items in > the options.modus_list, and its contents as integers should always > replace all of the original MODUS_LIST, because it is up to the user to > decide what should be used for calculating the result. > > The above works (unless I have introduced some bug when I copied into my > editor here), but I would like to know if there already is such a thing, > or something better than the above. I'd hate to re-invent the wheel. > > TIA > > > /Grrr looks like a classic list comprehension to me and can be achieved in a single line MODUS_LIST=[int(x) for x in options.modus_list] -- NOTICE: -- THE ELEVATORS WILL BE OUT OF ORDER TODAY -- (The nearest working elevator is in the building across the street.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
In article <3rcdnuciwpp1gzhnnz2dnuvz7vqaa...@giganews.com>, Tony the Tiger wrote: > Hi, > Is there such a thing in the language, or do I have to invent it myself? > > I came up with the following: > > # options.modus_list contains, e.g., "[2,3,4]" > # (a string from the command line) > # MODUS_LIST contains, e.g., [2,4,8,16] > # (i.e., a list of integers) > > if options.modus_list: > intTmp = [] > modTmp = options.modus_list[1:-1] > for itm in modTmp: > intTmp.append(int(itm)) > MODUS_LIST = intTmp To answer the question you asked, to convert a list of strings to a list of ints, you want to do something like: MODUS_LIST = [int(i) for i in options.modus_list] But, to answer the question you didn't ask, if you're trying to parse command-line arguments, you really want to use the argparse module. It's a little complicated to learn, but it's well worth the effort. -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On 22.07.2012 18:39, Alister wrote: On Sun, 22 Jul 2012 10:29:44 -0500, Tony the Tiger wrote: I came up with the following: # options.modus_list contains, e.g., "[2,3,4]" # (a string from the command line) # MODUS_LIST contains, e.g., [2,4,8,16] # (i.e., a list of integers) if options.modus_list: intTmp = [] modTmp = options.modus_list[1:-1] for itm in modTmp: intTmp.append(int(itm)) MODUS_LIST = intTmp TIA /Grrr looks like a classic list comprehension to me and can be achieved in a single line MODUS_LIST=[int(x) for x in options.modus_list] Hi, I am not sure why everyone is using the for-iterator option over a "map", but I would do it like that: MODUS_LIST= map(int, options.modus_list) "map" works on a list and does commandX (here "int" conversion, use "str" for string.. et cetera) on sequenceY, returning a sequence. More in the help file. And if I'm not completely mistaken, it's also the quicker way to do performance wise. But I can't completely recall the exact reason. Jan -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
Tony the Tiger wrote:
> On Sun, 22 Jul 2012 11:39:30 -0400, Roy Smith wrote:
>
>> To answer the question you asked, to convert a list of strings to a list
>> of ints, you want to do something like:
>>
>> MODUS_LIST = [int(i) for i in options.modus_list]
>
> Thanks. I'll look into that. I now remember reading about the technique
> (in Mark Lutz' "Learning Python"), but it seems I'm getting old as I tend
> to forget about it from time to time. ;)
>
>> But, to answer the question you didn't ask, if you're trying to parse
>> command-line arguments, you really want to use the argparse module. It's
>> a little complicated to learn, but it's well worth the effort.
>
> Your suggestions about the argparse. Well, it seems it does pretty much
> the same as OptionParser which I use now. Perhaps it has more features
> (that I probably won't need in my 30 line script), I only need to keep
> track of maybe one or two options. Maybe one of these days, when I have
> little else to do, or when the OptionParser stops working, I'll give it a
> try. Thanks. :)
Here's an argparse example:
$ cat argparse_list.py
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("-m", "--modus", type=int, nargs="*")
print parser.parse_args().modus
$ python argparse_list.py
None
$ python argparse_list.py -m
[]
$ python argparse_list.py -m 1
[1]
$ python argparse_list.py -m 1 2 3
[1, 2, 3]
--
http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On Jul 22, 2:20 pm, Lipska the Kat wrote: > Well I have to say that I've used Eclipse with the myEclipse plugin for > a number of years now and although it has it's moments it has earned me > LOADS of MONEY so I can't really criticise it. Ive probably tried to use eclipse about 4 times in the last 8 years. Always run away in terror. Still I'm never sure whether eclipse is stupid or I am... First time I'm hearing of myEclipse. Thanks. What does it have/do that standard eclipse (JDT?) does not? > Python and eclipse ... Noo ;-) Very curious about this. You made 'Loads of money' with eclipse but want to stay away from it? Simply cannot make out this thing called 'java-programmer-culture'... -- http://mail.python.org/mailman/listinfo/python-list
command line option parsing and pylint?
Is there such a thing as a Python option parsing module, that plays well with pylint? I've been doing my own option parsing to get working static analysis. -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On Sun, Jul 22, 2012 at 12:20 PM, Jan Riechers wrote: > On 22.07.2012 18:39, Alister wrote: >> looks like a classic list comprehension to me and can be achieved in a >> single line >> MODUS_LIST=[int(x) for x in options.modus_list] > Hi, > > I am not sure why everyone is using the for-iterator option over a "map", > but I would do it like that: > MODUS_LIST= map(int, options.modus_list) > > "map" works on a list and does commandX (here "int" conversion, use "str" > for string.. et cetera) on sequenceY, returning a sequence. More in the help > file. > > And if I'm not completely mistaken, it's also the quicker way to do > performance wise. But I can't completely recall the exact reason. Because if you don't have a functional background 'map' is unfamiliar. Although I've been aware of it for years I still can't remember if it's map(int, list) or map(list,int) and although with a small effort I could force it into my brain, I know that many of the people reading my code are as ignorant as I am. The list comprehension seems clearer to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
Tony the Tiger writes: > # options.modus_list contains, e.g., "[2,3,4]" Try this: import ast MODUS_LIST = ast.literal_eval(options.modus_list) literal_eval is like eval except it can only evaluate literals rather than calling functions and the like. The idea is you can use it on untrusted data. -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On Sun, 22 Jul 2012 19:20:18 +0300, Jan Riechers wrote: > "map" works on a list and does commandX (here "int" conversion, use > "str" for string.. et cetera) on sequenceY, returning a sequence. More > in the help file. > > And if I'm not completely mistaken, it's also the quicker way to do > performance wise. But I can't completely recall the exact reason. The following only applies the standard CPython implementation. Other implementations may be different. In particular, PyPy turns everything you know about optimizing Python code on its head, and can often approach the speed of optimized C code in pure Python. map is faster than an ordinary for-loop if the function you are applying is a builtin like int, str, etc. But if you have to write your own pure- Python function, the overhead of calling a function negates the advantage of map, which is no faster than a for-loop. For example: results = map(int, sequence) # calls builtin `int` hoists the call to int into the fast C layer, instead of the slow Python layer, and should be faster than results = [] for x in sequence: results.append(int(x)) which runs at the speed of Python. But: results = map(lambda x: x+1, sequence) # calls pure Python function if no faster than a for-loop: results = [] for x in sequence: results.append(x+1) Note: this has *nothing* to do with the use of lambda. Writing the "+1" function above using def instead of lambda would give the same results. List comprehensions are at least as fast as map, since they too hoist the calculation into the fast C layer. They have the added advantage that they can calculate arbitrarily complex Python expressions in the C layer without needing an intermediate function. So: map(lambda x: x**2 - 3, sequence) runs more-or-less at the speed of an ordinary for-loop, but the list comprehension version: [x**2 - 3 for x in sequence] should be faster and doesn't rely on an intermediate function. So in general, a list comprehension will be no slower than map, and may be faster; both will be no slower than a for-loop, and may be faster. Or at least, this was the case last time I checked. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On 22.07.2012 20:03, David Robinow wrote: On Sun, Jul 22, 2012 at 12:20 PM, Jan Riechers wrote: On 22.07.2012 18:39, Alister wrote: looks like a classic list comprehension to me and can be achieved in a single line MODUS_LIST=[int(x) for x in options.modus_list] Hi, I am not sure why everyone is using the for-iterator option over a "map", but I would do it like that: MODUS_LIST= map(int, options.modus_list) "map" works on a list and does commandX (here "int" conversion, use "str" for string.. et cetera) on sequenceY, returning a sequence. More in the help file. And if I'm not completely mistaken, it's also the quicker way to do performance wise. But I can't completely recall the exact reason. Because if you don't have a functional background 'map' is unfamiliar. Although I've been aware of it for years I still can't remember if it's map(int, list) or map(list,int) and although with a small effort I could force it into my brain, I know that many of the people reading my code are as ignorant as I am. The list comprehension seems clearer to me. Hello, no offense by that, I just was wondering why everyone uses the list comprehension instead the built-in map in this case - I'm still using Python 2.7.3 so perhaps things might have changed a little. :) So far Jan -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On Sun, Jul 22, 2012 at 10:20 AM, Jan Riechers wrote: > Hi, > > I am not sure why everyone is using the for-iterator option over a "map", > but I would do it like that: > > MODUS_LIST= map(int, options.modus_list) > > "map" works on a list and does commandX (here "int" conversion, use "str" > for string.. et cetera) on sequenceY, returning a sequence. More in the help > file. > > And if I'm not completely mistaken, it's also the quicker way to do > performance wise. But I can't completely recall the exact reason. My recollection is that map has the edge if you can pass it a built-in or a C extension function, like int, or a complicated Python function that you would end up calling anyway in the list comprehension. The situation changes though if you can write the comprehension to remove the overhead of the Python function call. For example: map(lambda x: x+1, my_list) [x+1 for x in my_list] By performing the addition inline instead of calling a function to do it, the list comprehension wins performance-wise in this scenario. So as a simple rule of thumb I will typically choose between map or a comprehension based on whether I need to call a function or not (and also based on how pretty or ugly the resulting code is). Anything further would just be premature optimization. Also keep in mind that in Python 3 map returns an iterator instead of a list, so for a fair comparison you would have to compose the map with a list() call. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: My first ever Python program, comments welcome
On 22/07/12 17:18, rusi wrote: On Jul 22, 2:20 pm, Lipska the Kat wrote: Well I have to say that I've used Eclipse with the myEclipse plugin for a number of years now and although it has it's moments it has earned me LOADS of MONEY so I can't really criticise it. Ive probably tried to use eclipse about 4 times in the last 8 years. Always run away in terror. Still I'm never sure whether eclipse is stupid or I am... First time I'm hearing of myEclipse. Thanks. What does it have/do that standard eclipse (JDT?) does not? Eclipse for Java supports development of 'standard' Java applications that is applications that use the standard Java Distributions (JDK). MyEclipse adds support for J2EE and a bunch of other stuff. I used it mainly for jsp syntax highlighting, HTML syntax highlighting and Servlet development. It's marketed as a J2EE and web development IDE. It comes with an embedded Tomcat server and some versions support common frameworks such as Spring and Hibernate. Struts is supported by default I think although I always stayed away from frameworks when I could. I preferred to write Java rather than XML :-) Check out http://www.myeclipseide.com/ for an example of marketing bling. Python and eclipse ... Noo ;-) Very curious about this. You made 'Loads of money' with eclipse but want to stay away from it? Simply cannot make out this thing called 'java-programmer-culture'... How dare you sir, I'm not a Java programmer I am a 'retired' software engineer ;-) Heh heh, Nothing to do with Eclipse, just another thing to get my head around. For work and Java IMHO you can't beat eclipse... at the moment I'm getting my head around git, reminding myself of C, learning Python and re-learning make. Enough already; but if there's a python plugin I guess I'll get around to it eventually Lipska -- Lipska the Kat: Troll hunter, Sandbox destroyer and Farscape dreamer of Aeryn Sun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On 22.07.2012 20:01, Steven D'Aprano wrote: [SNIP] map is faster than an ordinary for-loop if the function you are applying is a builtin like int, str, etc. But if you have to write your own pure- Python function, the overhead of calling a function negates the advantage of map, which is no faster than a for-loop. For example: results = map(int, sequence) # calls builtin `int` hoists the call to int into the fast C layer, instead of the slow Python layer, and should be faster than results = [] for x in sequence: results.append(int(x)) which runs at the speed of Python. But: results = map(lambda x: x+1, sequence) # calls pure Python function if no faster than a for-loop: results = [] for x in sequence: results.append(x+1) Note: this has*nothing* to do with the use of lambda. Writing the "+1" function above using def instead of lambda would give the same results. [SNAP] Hi Steven, besides that I testdrive Pypy (and still am impressed, other topic) - your answer was what I was picking for ;) Especially this part of you: > map is faster than an ordinary for-loop if the function you are applying > is a builtin like int, str, etc. [underlaying c-layer] But if you have to write your own pure- > Python function, the overhead of calling a function negates the advantage > of map [...] I did not know that the speed gain is up foremost present when using built-ins, but that's for sure something to keep in mind when writing code. Thanks for your explanation, clarifies a lot! Jan -- http://mail.python.org/mailman/listinfo/python-list
Re: A thread import problem
On Sat, Jul 21, 2012 at 5:47 PM, Dennis Lee Bieber wrote: > On Sat, 21 Jul 2012 17:10:05 -0600, Bruce Sherwood > declaimed the following in > gmane.comp.python.general: > > >> Thanks, but the problem I need to solve does not permit putting a >> function like runner in the main program. I'm constrained to being >> able to handle the API of VPython (vpython.org), which lets you write >> programs like the following (call it user.py), which animates a 3D >> cube moving to the right, using OpenGL: >> >> from visual import box >> b = box() >> while True: >> b.pos.x += 0.001 > > Well, based on that sample, wrap THAT as "runner" > > def runner(): > from visual import box > b = box() > while True: > b.pos.x += 0.0001 > > and don't /call/ runner() until after all the main system is configured. > (And runner could, if need be, be "called" as a thread). > > Not having a Mac, I can't do tests... but everything I've seen so > far comes down to NOT IMPORTING anything that tries to spawn threads > /during the import/. > > A properly designed module (as I showed with my testABA.py) only > "runs" stuff if loaded as the main program; any other use (import) only > does imports and defines module level entities -- running anything is > deferred for the program that did the import to invoke AFTER the import > finished. > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ > > -- > http://mail.python.org/mailman/listinfo/python-list I don't have the luxury of doing things the "approved" way. I'm constrained by extensive legacy code (and legacy educational documentation for student use) to be able to run programs such as this one: from visual import box b = box() while True: b.pos.x += 0.001 Another way of saying this is that I'm not building an app, in which case I would structure things in a simple and straightforward manner. I am instead trying to maintain and update a library that allows novice programmers to write programs that generate real-time navigable 3D animations, writing minimalist programs that work cross-platform. Bruce Sherwood -- http://mail.python.org/mailman/listinfo/python-list
default repr?
If a class has defined its own __repr__ method, is there a way of getting the default repr output for that class anyway? I'm attempting to graph some objects by digging around in the garbage collector's idea of what objects exist, and when I go to format them for the graph node labels, the ones that haven't defined a __repr__ look nice, but the ones that have come out looking strangely. -- http://mail.python.org/mailman/listinfo/python-list
Re: default repr?
On Mon, Jul 23, 2012 at 8:48 AM, Dan Stromberg wrote: > If a class has defined its own __repr__ method, is there a way of getting > the default repr output for that class anyway? Methods are just functions, and you can call any method of any class with any object as its first parameter. object.__repr__(some_object) Though this mightn't work with everything. I wasn't able to paint a list as a tuple - "tuple.__repr__([1,2,3])" threw a TypeError. Oh well. There's a limit to the ways Python lets you shoot yourself in the foot. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: default repr?
On 22 July 2012 23:48, Dan Stromberg wrote: > > If a class has defined its own __repr__ method, is there a way of getting > the default repr output for that class anyway? > For new style classes you can just call object.__repr__ e.g.: In [1]: class A(object): ...: pass ...: In [2]: class B(object): ...: def __repr__(self): ...: return 'foo' ...: In [3]: a = A() In [4]: b = B() In [5]: repr(a) Out[5]: '<__main__.A object at 0x2136b10>' In [6]: repr(b) Out[6]: 'foo' In [7]: object.__repr__(b) Out[7]: '<__main__.B object at 0x2136c10>' Oscar. -- http://mail.python.org/mailman/listinfo/python-list
Re: A thread import problem
On Sun, Jul 22, 2012 at 3:48 PM, Dennis Lee Bieber wrote: > On Sun, 22 Jul 2012 13:04:25 -0600, Bruce Sherwood > declaimed the following in > gmane.comp.python.general: > > >> Another way of saying this is that I'm not building an app, in which >> case I would structure things in a simple and straightforward manner. >> I am instead trying to maintain and update a library that allows >> novice programmers to write programs that generate real-time navigable >> 3D animations, writing minimalist programs that work cross-platform. >> > I suspect you don't need to update the library so much as enforce a > project style that prevents your import-thread-import cycle. In short, > something like that hypothetical "runner()" design. > > Oh, and document that style in detail: "importable modules shall > only perform module level definition of entities during import -- no > code that actually processes data"; "importable modules shall make use > of the 'if __name__ == "__main__": main()' convention to identify when > the module is being used stand-alone, and thereby invoke the main > processing; otherwise the module.main() function is to be invoked only > be the module doing the imports, after the import has completed" > etc. > > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ > > -- > http://mail.python.org/mailman/listinfo/python-list There's nothing wrong with the current VPython architecture, which does use good style, but there are two absolute, conflicting requirements that I have to meet. (1) The simple program API I've shown must be preserved, because there exist a large number of such programs in existence, used by lots of people. I can't change the API. Among other uses, every semester there are about 5000 students in introductory college science courses, especially physics, who do computational modeling with 3D visualizations based on instructional materials that teach the existing API. There is also a large number of instructors who depend on existing VPython demo programs to continue working even if the college upgrades Python and VPython. This isn't some little project where I'm able to teach my small group of collaborators how they should structure programs. (2) My hand is forced by Apple no longer supporting Carbon. Among other aspects of this, Carbon can't be used with 64-bit Python, and more and more Mac users of VPython want to use 64-bit Python. So there has to be a version of VPython that is based on Cocoa, but Cocoa is required to be the primary thread. This requirement, combined with the absolute requirement that the VPython API cannot be changed, is the problem I face. I have to turn the architecture inside out, independent of whether the solution meets all criteria for good Python programming style. Bruce Sherwood -- http://mail.python.org/mailman/listinfo/python-list
Re: default repr?
On Mon, 23 Jul 2012 08:54:00 +1000, Chris Angelico wrote: > On Mon, Jul 23, 2012 at 8:48 AM, Dan Stromberg > wrote: >> If a class has defined its own __repr__ method, is there a way of >> getting the default repr output for that class anyway? If the class, call it C, is a subclass of some other class (or classes), then there is also the repr of the parent. You can get to that by calling parent.__repr__(instance), although there are some subtleties. In Python 2, there are old-style or classic classes that don't inherit from anything else. I don't believe there is any way to get the repr of a classic class with no __repr__ method *except* from an instance with no __repr__ method. So the answer for C below will be No: # Python 2.x class C: def __repr__(self): return "C()" But for new-style classes in Python 2, or all classes in Python 3, the answer is Yes. All classes inherit from object, directly or indirectly, so you can either call the object repr or use super: # Python 2.x or 3.x class K(object): # inheriting from object makes it "new style" def __repr__(self): # but please don't do this -- see below for a better way print(object.__repr__(self)) return "K()" You can specify the parent class directly by name, as above, grab its __repr__ method, and call it. But that's the wrong solution: it does not work correctly with multiple inheritance, and even if you don't use MI yourself, it means that nobody else can use your class for MI. Better is to allow Python to work out which parent class you have, even if you already know the answer and only have one parent. The dance is a little more complex, but now you are multiple-inheritance-safe: # Python 2.x or 3.x class K(object): def __repr__(self): # this ONLY works for new-style classes print(super(K, self).__repr__()) return "K()" Python 3 offers some additional magic: if you don't give super() any arguments, the compiler magically does the right thing: # Python 3.x class K(object): # or just "class K" def __repr__(self): print(super().__repr__()) return "K()" > Methods are just functions, and you can call any method of any class > with any object as its first parameter. Not quite: they have to be an instance of that class. > object.__repr__(some_object) That will work because everything is an instance of object (apart from classic classes in Python 2). > Though this mightn't work with everything. I wasn't able to paint a list > as a tuple - "tuple.__repr__([1,2,3])" threw a TypeError. Oh well. > There's a limit to the ways Python lets you shoot yourself in the foot. Of course -- [1,2,3] is not a tuple, so how would tuple know what to do with it? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: default repr?
On Mon, Jul 23, 2012 at 10:24 AM, Steven D'Aprano wrote: >> Methods are just functions, and you can call any method of any class >> with any object as its first parameter. > > Not quite: they have to be an instance of that class. > >> Though this mightn't work with everything. I wasn't able to paint a list >> as a tuple - "tuple.__repr__([1,2,3])" threw a TypeError. Oh well. >> There's a limit to the ways Python lets you shoot yourself in the foot. > > Of course -- [1,2,3] is not a tuple, so how would tuple know what to do > with it? Hmm. I would have thought that methods were like all other functions: they take their arguments and do code with them. Duck typing and all. I stand corrected, then. In any case, it works fine for methods of object, at least with Python 3 and with new-style classes in Py2. (Other than backward compatibility with old code, is there any reason to use an old-style class?) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: default repr?
On Sun, Jul 22, 2012 at 8:29 PM, Chris Angelico wrote: > On Mon, Jul 23, 2012 at 10:24 AM, Steven D'Aprano > wrote: >> Not quite: they have to be an instance of that class. 8< > Hmm. I would have thought that methods were like all other functions: > they take their arguments and do code with them. Duck typing and all. > I stand corrected, then. On Python 3 you are correct. >>> class A: ... def print(self): ... print(self) ... >>> A.print(2) 2 -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Converting a list of strings into a list of integers?
On 07/22/2012 11:29 AM, Tony the Tiger wrote: > Hi, > Is there such a thing in the language, or do I have to invent it myself? > > I came up with the following: > > # options.modus_list contains, e.g., "[2,3,4]" > # (a string from the command line) > > > > So which is it, a list of strings, or a string? Your subject line does not agree with the comment. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: default repr?
On Mon, 23 Jul 2012 10:29:33 +1000, Chris Angelico wrote: > On Mon, Jul 23, 2012 at 10:24 AM, Steven D'Aprano > wrote: >>> Methods are just functions, and you can call any method of any class >>> with any object as its first parameter. >> >> Not quite: they have to be an instance of that class. >> >>> Though this mightn't work with everything. I wasn't able to paint a >>> list as a tuple - "tuple.__repr__([1,2,3])" threw a TypeError. Oh >>> well. There's a limit to the ways Python lets you shoot yourself in >>> the foot. >> >> Of course -- [1,2,3] is not a tuple, so how would tuple know what to do >> with it? > > Hmm. I would have thought that methods were like all other functions: > they take their arguments and do code with them. Duck typing and all. I > stand corrected, then. > > In any case, it works fine for methods of object, at least with Python 3 > and with new-style classes in Py2. Naturally. In Python 3, and for new-style classes in 2, any instance is an instance of object. As the base class of everything, object has a generic repr that can handle everything. But subclasses are entitled to be more picky. What would you expect int.__repr__ do with a tuple for an argument? Raise an error, of course, and a TypeError at that. Which it does, in both 2 and 3: py> int.__repr__( (1, 2) ) Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__repr__' requires a 'int' object but received a 'tuple' In general, you should assume that an arbitrary method will insist on its "self" argument actually being a valid instance of its class. There may be occasions where that is not the case, but don't count on it. I expect that this is under-specified behaviour: whether it works or not is implementation-specific, and so may change from compiler to compiler, or version to version. The mechanism behind method look-up is slightly complex, and changed significantly in Python 3. In Python 2, *both* these lookups: myclass.mymethod myinstance.mymethod return a *method object* -- the first case returns an "unbound method", which needs self to be provided when it is called, and the second returns a "bound method", which already knows what value of self to use (myinstance). In CPython, they are the same type with slightly different reprs, but that's an implementation detail. In either case, the method type enforces the rule that self is an instance of the type. In Python 3, the rule is slightly different. As before, *bound* methods (those that already have self supplied) are still returned when you look- up on an instance: myinstance.mymethod # returns a bound method object but unbound methods are no longer returned. (I presume you could still create one, by hand, but haven't tried.) Instead, looking up on the class returns the raw function object without the method wrapper, and that does no type-checking on self unless the developer put one in. Which built-in methods have got. > (Other than backward compatibility with old code, is there any reason to > use an old-style class?) Old-style classes have subtle differences in behaviour, and in principle at least are slightly faster. (At least they were back in Python 2.2.) Some differences include: 1) descriptor protocol does not work, including properties 2) super does not work 3) no __getattribute__ 4) magic dunder methods such as __add__ do not bypass the instance 5) automatic delegation is trivial So if you *require* such differences, then they would be good reasons for using classic classes. But frankly, as far as I can tell only #4 and #5 are positive differences, the others are reasons to avoid classic classes. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: A thread import problem
On Sun, Jul 22, 2012 at 7:14 PM, Bruce Sherwood wrote: > (2) My hand is forced by Apple no longer supporting Carbon. Among > other aspects of this, Carbon can't be used with 64-bit Python, and > more and more Mac users of VPython want to use 64-bit Python. So there > has to be a version of VPython that is based on Cocoa, but Cocoa is > required to be the primary thread. This requirement, combined with the > absolute requirement that the VPython API cannot be changed, is the > problem I face. I have to turn the architecture inside out, > independent of whether the solution meets all criteria for good Python > programming style. I had exactly this problem with Tkinter on Mac. The API involved "synchronous" calls to update a GUI written in tkinter, which ran in another thread (so e.g. students could call the API from the interactive interpreter). This didn't work on new Mac OS X releases, because Tkinter had to be run in the main thread after some update -- and also because of this deadlock issue with imports (but I didn't know that until later). I ended up solving it by running the Tkinter in the main thread of a different process, which could handle RPC invocations asynchronously, and sending remote invocations via a synchronous RPC library in the parent process. Maybe you can do something similar in your case? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
