Prev: passing environment variable path to open command
Next: pyjsglade: GTK-glade-like UI builder for pyjamas
From: Martin on 13 Jun 2010 16:54 On Jun 13, 5:46 pm, exar...(a)twistedmatrix.com wrote: > On 04:25 pm, wuwe...(a)gmail.com wrote: > > > > > > >Steven D'Aprano <st...(a)REMOVE-THIS-cybersource.com.au> wrote: > >>No, I think your code is very simple. You can save a few lines by > >>writing > >>it like this: > > >>s = input('enter two numbers: ') > >>t = s.split() > >>print(int(t[0]) + int(t[1])) # no need for temporary variables a and > >>b > > >Not that we're playing a round of code golf here, but this is a > >slightly nicer take on your version: > > >one, two = input('enter two numbers: ').split() > >print(int(one) + int(two)) > > >I like names over subscripts, but that's just me :) > > Fore! > > print(sum(map(int, input('enter two numbers: ').split()))) > > Jean-Paul Can't beat that for lack of syntax! I'd probably add a check just because the OP did mention only two int's... data = [int(i) for i in raw_input('Enter two integers:\n').split()] if len(data) != 2: print 'Only enter 2 integers!' else: print "\n%d" % sum(data)
From: alex23 on 13 Jun 2010 21:35 exar...(a)twistedmatrix.com wrote: > Fore! > > print(sum(map(int, input('enter two numbers: ').split()))) Well, I _was_ trying to stick to Steven's more simple map-less form :) (Although I have to say, I have little sympathy for Steven's hypothetical "new programmer who isn't familiar with map and reduce". Python isn't PHP, its built-ins are nowhere near as exhaustive, something like 80ish vs 2000+ functions? Not exactly a huge lookup burden.)
From: geremy condra on 13 Jun 2010 22:03 On Sun, Jun 13, 2010 at 9:46 AM, <exarkun(a)twistedmatrix.com> wrote: > On 04:25 pm, wuwei23(a)gmail.com wrote: >> >> Steven D'Aprano <st...(a)REMOVE-THIS-cybersource.com.au> wrote: >>> >>> No, I think your code is very simple. You can save a few lines by writing >>> it like this: >>> >>> s = input('enter two numbers: ') >>> t = s.split() >>> print(int(t[0]) + int(t[1])) # no need for temporary variables a and b >> >> Not that we're playing a round of code golf here, but this is a >> slightly nicer take on your version: >> >> one, two = input('enter two numbers: ').split() >> print(int(one) + int(two)) >> >> I like names over subscripts, but that's just me :) > > Fore! > > print(sum(map(int, input('enter two numbers: ').split()))) > > Jean-Paul I prefer football to golf: print(sum([sum([(ord(j)-48)*10**pos for pos,j in enumerate(reversed(i))]) for i in raw_input().split()])) Geremy Condra
From: Ben Finney on 13 Jun 2010 22:24 alex23 <wuwei23(a)gmail.com> writes: > (Although I have to say, I have little sympathy for Steven's > hypothetical "new programmer who isn't familiar with map and reduce". With 'reduce' gone in Python 3 [0], I can only interpret that as “I have little sympathy for programmers who start with Python 3”. Is that in line with what you meant? > Python isn't PHP, its built-ins are nowhere near as exhaustive, > something like 80ish vs 2000+ functions? Not exactly a huge lookup > burden.) The process of deprecation ('map' and 'reduce' are nowadays better replaced with list comprehensions or generator expressions) surely entails deprecating learning the deprecated practice for new code. [0] <URL:http://docs.python.org/py3k/library/functions.html> -- \ “The fact of your own existence is the most astonishing fact | `\ you'll ever have to confront. Don't dare ever see your life as | _o__) boring, monotonous or joyless.” —Richard Dawkins, 2010-03-10 | Ben Finney
From: Steven D'Aprano on 13 Jun 2010 22:45
On Sun, 13 Jun 2010 18:35:52 -0700, alex23 wrote: > I have little sympathy for Steven's > hypothetical "new programmer who isn't familiar with map and reduce". Perhaps you need to spend some more time helping beginners then, and less time hanging around Lisp gurus *wink* > Python isn't PHP, its built-ins are nowhere near as exhaustive, > something like 80ish vs 2000+ functions? Not exactly a huge lookup > burden. It's not the lookup burden, but the mental burden of grasping the idea of functions-as-data. Higher-order functions (functions that take functions as data) are notoriously difficult for many people to grasp, and even some programmers of the calibre of Guido van Rossum never get entirely comfortable with (e.g.) reduce. That's why Guido recommends people use a for-loop instead of reduce, apply was removed entirely, and list comps were introduced as a more friendly alternative to map. I'm certainly not saying that people should avoid higher-order functional code, but merely to remember that map and filter aren't introductory concepts, they're moderately advanced functions that many people find difficult. -- Steven |