Python information and short questions megathread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Python information and short questions megathread.

«‹›484 »

spankweasel: Jan 4, 2006

For the record, dumping zip and lambda on a new python programmer is just plain mean.

# ? Mar 9, 2013 21:12

Adbot: ADBOT LOVES YOU

# ? May 8, 2024 15:13

The Insect Court: Nov 22, 2012; by FactsAreUseless

Python already has methods to do just what you're trying to do(more or less):

code:

alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
key = "ZYXWVUTSRQPONMLKJIHGFEDCBA"
translation_table = str.maketrans(alphabet, key)
"TESTING".translate(translation_table)

This is arguably the most straight-forward way to do it, but the least homework-y since it only really displays knowledge of the Python standard library

# ? Mar 9, 2013 23:35

OnceIWasAnOstrich: Jul 22, 2006

The Insect Court posted:

Python already has methods to do just what you're trying to do(more or less):
code:
alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
key = "ZYXWVUTSRQPONMLKJIHGFEDCBA"
translation_table = str.maketrans(alphabet, key)
"TESTING".translate(translation_table)
This is arguably the most straight-forward way to do it, but the least homework-y since it only really displays knowledge of the Python standard library

Without using lambda or zip you can easily do it with a comprehension, which I always found more intuitive.

Python code:

alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
key = "ZYXWVUTSRQPONMLKJIHGFEDCBA"
word = "TESTING"
print ''.join(key[alphabet.find(letter)] for letter in word)

# ? Mar 10, 2013 02:34

BeefofAges: Jun 5, 2004; Cry 'Havoc!', and let slip the cows of war.

I think showing a newbie programmer anything with lambdas or zip or even list comprehensions is a bit too much. The most educational example is probably to just write out all the steps in a loop using the list indexes. Otherwise there's just too much magic going on for most new programmers to learn anything.

# ? Mar 10, 2013 07:41

The Insect Court: Nov 22, 2012; by FactsAreUseless

I agree on the zips and lambdas, but I wish that list comprehensions(and their various cousins like dictionary/set comprehensions, generator expressions, etc.) were introduced early on to new Python programmers. They're incredibly useful language constructs, and generally have the best performance and readability. Better to start out using them than having to find a way to jam them into the standard object-oriented paradigm.

# ? Mar 10, 2013 12:40

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

The Insect Court posted:

I agree on the zips and lambdas, but I wish that list comprehensions(and their various cousins like dictionary/set comprehensions, generator expressions, etc.) were introduced early on to new Python programmers. They're incredibly useful language constructs, and generally have the best performance and readability. Better to start out using them than having to find a way to jam them into the standard object-oriented paradigm.

Yes, this is true. I remember when I was first learning Python (and disregarding a bunch of QBasic in the early 90's this was when I was learning Real Programming), the resources I were using didn't teach list comprehensions. I then avoided them for a couple years.

I wish I hadn't.

# ? Mar 10, 2013 17:16

JetsGuy: Sep 17, 2003; science + hockey
=
LASER SKATES

Thermopyle posted:

Yes, this is true. I remember when I was first learning Python (and disregarding a bunch of QBasic in the early 90's this was when I was learning Real Programming), the resources I were using didn't teach list comprehensions. I then avoided them for a couple years.

I wish I hadn't.

Same. I avoided lambda for a long time because it just seemed lazy and dumb to me. Then I programmed in python for a few years and understood.

# ? Mar 11, 2013 06:09

Emacs Headroom: Aug 2, 2003

List comprehensions good, lambdas bad (by the Guido-given style conventions).

# ? Mar 11, 2013 15:30

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

I almost never use list comprehensions. I do, however, use generator functions and expressions very often and set and dict comprehensions quite often. I usually either need some extra storage functionality (e.g. only unique elements or key/value pairs) or I need an iterator -- rarely an actual list.

# ? Mar 11, 2013 15:58

fritz: Jul 26, 2003

Emacs Headroom posted:

(by the Guido-given style conventions).

More reasons to disregard them, then.

# ? Mar 11, 2013 19:17

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

lambdas are functions. I don't see why you would ever use a lambda instead of a def, which gives you a name, a docstring, etc.

# ? Mar 11, 2013 19:50

JetsGuy: Sep 17, 2003; science + hockey
=
LASER SKATES

Suspicious Dish posted:

lambdas are functions. I don't see why you would ever use a lambda instead of a def, which gives you a name, a docstring, etc.

I agree in that def is almost always better but lambda can be mildly useful if you're just writing a quick app/script to do something and you only need the function once. Even then, it's gotta be a quick and simple function like a power law before I even consider using lambda.

EDIT:
Here's a dumb example of usage of lambda that's not a mathematical function. I pulled it from my plotter program that I made so that I can keep matplotlib separate from my data analysis routines.

code:

    master_data = col.OrderedDict(sorted(master_data.items(),
                                         key=lambda k: k[0]))

EDIT2:
col is collections

JetsGuy fucked around with this message at 21:47 on Mar 11, 2013

# ? Mar 11, 2013 21:38

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

operator.itemgetter(0)

# ? Mar 11, 2013 22:22

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

JetsGuy posted:

EDIT:
Here's a dumb example of usage of lambda that's not a mathematical function. I pulled it from my plotter program that I made so that I can keep matplotlib separate from my data analysis routines.
code:
    master_data = col.OrderedDict(sorted(master_data.items(),
                                         key=lambda k: k[0]))
EDIT2:
col is collections

code:

master_data = col.OrderedDict(sorted(master_data.items(), key = operator.itemgetter(0)))

edit: bastard

# ? Mar 11, 2013 22:22

JetsGuy: Sep 17, 2003; science + hockey
=
LASER SKATES

How wonderful, I learned something today.

# ? Mar 12, 2013 00:43

Opinion Haver: Apr 9, 2007

What about lambda k: k[0][0]?

# ? Mar 12, 2013 00:48

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Define a function so you can explain why you need such a weird getter in a docstring.

# ? Mar 12, 2013 01:11

Nippashish: Nov 2, 2005; Let me see you dance!

Suspicious Dish posted:

Define a function so you can explain why you need such a weird getter in a docstring.

How is this better than a comment over the line with the lambda, assuming it's not already obvious?

This sounds like silly dogma.

# ? Mar 12, 2013 04:59

Scaevolus: Apr 16, 2007

Given a tuple or list, sorting by k[0] first is the default anyways. (tiebreakers of k[1] etc)

# ? Mar 12, 2013 05:01

Opinion Haver: Apr 9, 2007

Suspicious Dish posted:

Define a function so you can explain why you need such a weird getter in a docstring.

I can totally come up with other ones that should be more 'obvious', like lambda x: x.client.name or something. You could presumably write def frobSorterKey(x): x.client.name, but then what have you gained?

# ? Mar 12, 2013 05:06

Emacs Headroom: Aug 2, 2003

I think the point isn't that lambdas will break your code or ruin everything, but rather that consistent style guides are good (even if you personally don't like them, it's good to have an official document guiding the style and it's genrally better to conform where it doesn't hurt you).

The style guide in this case chose to discourage the use of lambda. This is because function definitions work just fine, and in nearly every case will be clearer and more expressive than using a lambda (and a lot of times people use lambda to make an unnamed function that is identical to a function that's already named, as in the example earlier).

I use them too sometimes, but it's still discouraged in general, and the reasons for it are sensible.

# ? Mar 12, 2013 05:11

Nippashish: Nov 2, 2005; Let me see you dance!

Emacs Headroom posted:

I think the point isn't that lambdas will break your code or ruin everything, but rather that consistent style guides are good (even if you personally don't like them, it's good to have an official document guiding the style and it's genrally better to conform where it doesn't hurt you).

This is a reasonable view, but what happens pretty often instead is that people say things like "I can't imagine why you'd ever use a lambda" and then get snarky when someone tries to suggest that maybe they aren't the worst thing in the world.

# ? Mar 12, 2013 05:23

Opinion Haver: Apr 9, 2007

Yeah, I agree that generally in python you want to actually make a def. It's just that sometimes it's clearer not to.

# ? Mar 12, 2013 05:28

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Given the nature of human beings and our love of taking sides and creating dogma instead of being reasonable , I prefer the dogma to fall on the side of defining functions.

Yes there are reasons to use a lambda, but I'd rather everyone define a function all of the time than get clever with lambda some of the time.

That being said, that's never going to happen, so I'm over it!

# ? Mar 12, 2013 06:17

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

Could anyone point me to a Python module (or modules) that can allow me to create a Single Elimination Tournament Bracket?

I've been gradually trying to construct entirely on my own here but I'm sure someone has already done it and I'd rather just fork the library and use it for my own sinister purposes rather than go through the mental exercises of constructing such a class/module.

Google hasn't really helped me very much other than remind me of the heapq module and show me to old modules that go beyond the scope of what I'm looking for.

# ? Mar 12, 2013 12:08

the: Jul 18, 2004; by Cowcaster

In a second order Runge-Kutte method, how do I account for the "half" values?

A programming assignment I have asks me to do two loops, one of them is like:

E[i+1, j+1, k+1] through loops of i,j,k, and the other is E[i+1/2, j+1/2, k+1/2]. How do I loop through those halves?

EDIT: Upon further examination, only n is 1/2 step, not i,j,k. I'll have to look further into this.

the fucked around with this message at 00:26 on Mar 13, 2013

# ? Mar 12, 2013 23:48

Emacs Headroom: Aug 2, 2003

First of all, this is really not a Python question, it's more of a scientific computing question, but that said the first thing you'll want to do is find a better explanation of Runge-Kutta (one that doesn't just dump a bunch of equations on you with no explication). A little googling gave me this one which looks decent.

Second, I assume you'll have some ODE you can calculate derivatives from (at any place over your domain), and what you want to do is simulate a trajectory for some inital values by numerical integration. I'm not an EM person so I don't know anything about the particular system you're working with there, but you should be able to take the general case of 2nd-order Runge-Kutta (from wikipedia or from the link earlier) and fill in your particular system, and it'll be obvious what's meant by storing half-steps (i.e. all you're really doing is taking steps along a path, only you can't see the actual path all you can see is a direction you should go from here. You could look down every big step and turn in the new direction every time but that would give you a lot of error, so instead you'll get a direction every step but also get a direction at the half step and average them in a way that reduced the error).

# ? Mar 13, 2013 00:46

JetsGuy: Sep 17, 2003; science + hockey
=
LASER SKATES

I wrote a runge kutte for a hw assignment in my comp physic class back in grad school. I'll post it tomorrow, but I guarantee its going to be of beginner quality code since I wrote it when I was a month into even starting python. Definitely worked though!!

# ? Mar 13, 2013 07:02

QuarkJets: Sep 8, 2008

JetsGuy posted:

Same. I avoided lambda for a long time because it just seemed lazy and dumb to me. Then I programmed in python for a few years and understood.

Can you help me understand? Because lambda seems lazy and dumb to me, and while I do use Python a lot I wouldn't say that I'm more than average-skilled, so I'm authentically interested in learning more about the parts of Python that I don't get to see day-to-day. Wouldn't it be better to write a clean and documented def in case someone else has to use your code in the future?

I've been following along, but I still can't think of a circumstance where a lambda is easier to understand than a def

QuarkJets fucked around with this message at 08:10 on Mar 13, 2013

# ? Mar 13, 2013 08:06

The Gripper: Sep 14, 2004; i am winner

QuarkJets posted:

Can you help me understand? Because lambda seems lazy and dumb to me, and while I do use Python a lot I wouldn't say that I'm more than average-skilled, so I'm authentically interested in learning more about the parts of Python that I don't get to see day-to-day. Wouldn't it be better to write a clean and documented def in case someone else has to use your code in the future?

I've been following along, but I still can't think of a circumstance where a lambda is easier to understand than a def

I don't think they're ever easier to understand but I tend to use them in things like map() if the implementation is simple enough and the lambda is a function that won't be used elsewhere, or if I'm providing convenience functions which call other functions with a simple callback e.g.:

Python code:

def DeleteTree(key_str, subkey_str):
    """Wrapper for ActionTree(key,subkey,callback) where callback deletes the current key"""
    ActionTree(key_str, subkey_str, lambda k, i: _winreg.DeleteKey(k, i))

It's no better or worse I suppose, it just saves having to write a full function definition for something that is short-lived, simple and highly specialized.

# ? Mar 13, 2013 08:50

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

The Gripper posted:

I don't think they're ever easier to understand but I tend to use them in things like map() if the implementation is simple enough and the lambda is a function that won't be used elsewhere.

I don't think I've ever seen a use of map() that wouldn't be easier to read if it were a list comprehension. I'm not saying they don't exist, but I've never seen one. And if you're doing stuff that's sufficiently complicated in the list comprehension/map statement that it's hard to read, you should probably define a function anyway. Either way there's no real need for lambda.

The Gripper posted:

Or if I'm providing convenience functions which call other functions with a simple callback e.g.:
Python code:
def DeleteTree(key_str, subkey_str):
    """Wrapper for ActionTree(key,subkey,callback) where callback deletes the current key"""
    ActionTree(key_str, subkey_str, lambda k, i: _winreg.DeleteKey(k, i))
It's no better or worse I suppose, it just saves having to write a full function definition for something that is short-lived, simple and highly specialized.

Couldn't you just do this?

Python code:

def DeleteTree(key_str, subkey_str):
    """Wrapper for ActionTree(key,subkey,callback) where callback deletes the current key"""
    ActionTree(key_str, subkey_str, _winreg.DeleteKey)

Edit: To clarify: I do think there are some valid uses for lambda, precisely for stuff like simple callbacks that need to modify the input arguments slightly before passing the data on to some other function. But it's very rare.

# ? Mar 13, 2013 10:04

Nippashish: Nov 2, 2005; Let me see you dance!

Since we are still on the topic of lambdas, I don't see why I would ever want to use operator.itemgetter(0) over lambda x: x[0]. The second one is shorter to type, no less clear, and doesn't require I import an extra module (i.e. doesn't require a code change many lines away).

# ? Mar 13, 2013 10:13

The Gripper: Sep 14, 2004; i am winner

LOOK I AM A TURTLE posted:

I don't think I've ever seen a use of map() that wouldn't be easier to read if it were a list comprehension. I'm not saying they don't exist, but I've never seen one. And if you're doing stuff that's sufficiently complicated in the list comprehension/map statement that it's hard to read, you should probably define a function anyway. Either way there's no real need for lambda.

Probably true, I only really come across it's use in existing code and tend to lean toward comprehensions in my own. It's still an example of where a lambda is useful, though, despite the actual case being replaceable with comprehensions.

LOOK I AM A TURTLE posted:

Couldn't you just do this?
...

Yeah that was a pretty terrible example of it in use (I stripped some arguments out of the lambda that made it necessary), but that is one of the cases where using a lambda is handy even if it's not completely necessary.

# ? Mar 13, 2013 10:43

Lurchington: Jan 2, 2003; Forums Dragoon

Nippashish posted:

Since we are still on the topic of lambdas, I don't see why I would ever want to use operator.itemgetter(0) over lambda x: x[0]. The second one is shorter to type, no less clear, and doesn't require I import an extra module (i.e. doesn't require a code change many lines away).

itemgetter is a bit of future proofing in case there's a chance you need multiples of an object's item:
operator.itemgetter(*some_list_of_keys) seems better than lambda x: [[x[k] for k in some_list_of_keys]
(note that the lambda here isn't even equivalent to itemgetter if the list of keys is one)

it's also possible that itemgetter is slightly better in performance since stdlib things like that do get worked on for efficiency occasionally.

VVVVVVVVVV

MeramJert posted:

I think if you're relying on the side effects of a function, it makes more sense to use map rather than a list comprehension. But maybe that's just me. That sort of situation doesn't really come up much for anything I write, though.

I agree completely

Lurchington fucked around with this message at 14:10 on Mar 13, 2013

# ? Mar 13, 2013 14:01

fart simpson: Jul 2, 2005; DEATH TO AMERICA

LOOK I AM A TURTLE posted:

I don't think I've ever seen a use of map() that wouldn't be easier to read if it were a list comprehension. I'm not saying they don't exist, but I've never seen one. And if you're doing stuff that's sufficiently complicated in the list comprehension/map statement that it's hard to read, you should probably define a function anyway. Either way there's no real need for lambda.

I think if you're relying on the side effects of a function, it makes more sense to use map rather than a list comprehension. But maybe that's just me. That sort of situation doesn't really come up much for anything I write, though. Basically, if you have

Python code:

# some code
map(f, stuff)
# more code

I think it's clearer that you aren't really doing anything with the resultant list compared to doing:

Python code:

# some code
[f(thing) for thing in stuff]
# more code

fart simpson fucked around with this message at 14:08 on Mar 13, 2013

# ? Mar 13, 2013 14:05

a lovely poster: Aug 5, 2011; by Pipski

Nippashish posted:

Since we are still on the topic of lambdas, I don't see why I would ever want to use operator.itemgetter(0) over lambda x: x[0]. The second one is shorter to type, no less clear, and doesn't require I import an extra module (i.e. doesn't require a code change many lines away).

Because writing the shortest lines possible is not really a goal for most software developers. I would use the first because in the case of someone else editing my code it would be a lot easier to understand.

operator.itemgetter(0) looks like a python statement, anyone with two weeks of python would understand what's going on

lambda x: x[0] might as well be a different language as far as a lot of developers go

Now, it's important to be concise and clear, but I'm unconvinced that it's worth shaving off five characters

# ? Mar 13, 2013 14:39

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

MeramJert posted:

I think it's clearer that you aren't really doing anything with the resultant list compared to doing:

Hmm, I think I disagree. It seems very clear to me what the comprehension is doing and ever so slightly obtuse what map is doing there. However, I can't say for sure if that is because I use list comprehensions 100 times more than map, or if it's just a difference in the way we understand code we read.

However, like I said earlier, it's not a big deal either way.

# ? Mar 13, 2013 15:04

fritz: Jul 26, 2003

LOOK I AM A TURTLE posted:

I don't think I've ever seen a use of map() that wouldn't be easier to read if it were a list comprehension. I'm not saying they don't exist, but I've never seen one. And if you're doing stuff that's sufficiently complicated in the list comprehension/map statement that it's hard to read, you should probably define a function anyway. Either way there's no real need for lambda.

Not a lambda, but:
f = open("x.csv","w")
cw = csv.writer(f)
map(cw.writerow,data)
f.close()

I also use lambdas when I need a defaultdict with a non-standard default value:
from collections import defaultdict

fives = defaultdict(lambda: 5)
pairs = defaultdict(lambda: [0,0])

# ? Mar 13, 2013 18:31

Thern: Aug 12, 2006; Say Hello To My Little Friend

fritz posted:

Not a lambda, but:
f = open("x.csv","w")
cw = csv.writer(f)
map(cw.writerow,data)

I just started looking into csv module for something I'm working on, so I'm curious. Is there a reason that you couldn't use the writerows method instead?

# ? Mar 13, 2013 19:50

Adbot: ADBOT LOVES YOU

# ? May 8, 2024 15:13

JetsGuy: Sep 17, 2003; science + hockey
=
LASER SKATES

I didn't have time before work to check my home computer for that Runge-Kutter, but I promise I'll post it tonight.

Thern posted:

I just started looking into csv module for something I'm working on, so I'm curious. Is there a reason that you couldn't use the writerows method instead?

out of curiosity, what benefits does the csv reader give you over doing something like:

code:

with file("datafile.csv", "r") as f:
    data = f.readlines()

x = []
y = []
for line in data:
    line = line.split(",")
    x.append(float(line[0]))
    y.append(float(line[1]))

Does the CSV package automatically do this poo poo for you? I've never really spent much time with it.

# ? Mar 13, 2013 21:11

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Python information and short questions megathread.

«‹›484 »