ashgromnies posted:

code:

tuple = ()
for i in range(1000000):
    tuple += (i,)

runs slower than

code:

array = []
for i in range(1000000):
    array.append(i)

Habnabit posted:

As has been mentioned, tuples are immutable and hashable, which means they can be used as dictionary keys and in a myriad of other places where lists can't.

ashgromnies posted:

After learning that you can use tuples as hash keys it took another tenth of a second off my program execution time on average! Woo!

So I feel REALLY embarrassed for asking this one, but how can you put variables inline? I'm writing some CSS out from a Python script(eventually I will do this the right way with templating, this is just for a really quick prototype though so it's not necessary at the moment) and I need to embed variables and it looks really ugly:

I know I could do it way better but I don't know how

Suggestions?

Scaevolus posted:

You really do want Templating.

Or at least the basic String Formatting Operations.

code:

	f.write("#div")
	f.write(str(idx))
	f.write("""a {
		background-color: rgb(""")
	f.write(str(int(rgb[0])))
	f.write(",")
	f.write(str(int(rgb[1])))
	f.write(",")
	f.write(str(int(rgb[2])))
	f.write(""")
		}
"""

becomes

code:

f.write("""#div%da {
    background-color: rgb(%d,%d,%d)
}""" % (idx, rgb[0], rgb[1], rgb[2]))

ashgromnies posted:

Yeah, I know I want templating but this is just a one-off for now to test my algorithm and will go away so I don't want to put too much effort into it - just enough to be readable. This is eventually going to be called from a Django application.

I didn't know Python had an equivalent of sprintf! Thanks!

king_kilr posted:

If this is for use in a Django app, you should probably take a look at the Django templating language.

Bozart posted:

It was my understanding that they are only hashable if they include only hashable elements, although I could be completely wrong.

Flea110 posted:

How do I get the indexes of every instance of a given character in a given string?

string.find seems to only give the index of the first instance.

Habnabit posted:

Fixed in bold.

deimos posted:

And if you want the count of every character in a string:

code:

import [b]collections[/b]

def letter_counts(st):
    counts = [b]collections.[/b]defaultdict(int)
    for l in st:
        counts[l] += 1
    return counts

This returns a defaultdict (basically a dict with some extra hotness), the way you would use it is:

code:

blah = "donges and buttes"
counts = letter_counts(blah)

[b]counts['a'] > 0[/b]
#Returns false ([b]no exception is raised when accessing a defaultdict, as the
defaultdict sets the value of a key if a key is missing. This is also why you 
can't just check [fixed]'a' in counts[/fixed] as [fixed]counts['a'][/fixed] could be 0.[/b])

counts['e'] #Returns 2

Benji the Blade posted:

I am by NO means a PyPy expert, though I do think it's pretty cool.

The developers say PyPy is a tool for generating virtual machines. PyPy started as a Python interpreter written in Python, and it can still be used as such on top of CPython and you get an ungody slow Python interpreter. And so, they decided to write a translation layer that takes RPython (a subset of Python) and translates it into C code. They then wrote the interpreter in RPython and now the interpreter can be translated into C code, and is currently around twice as slow as CPython.

However, they can use a different translator to automatically translate PyPy onto different platforms such as CLI/.NET, JVM, and apparently also less obviously useful platforms such as Smalltalk and Scheme.

Of course, the translator will translate anything from RPython to C/CLI/JVM or whatever, so people can write whatever interpreters or other programs they like in RPython (though using RPython in production isn't really advised right now, from what I can tell). You can also use RPython to generate libraries for CPython that have been translated into C and compiled.

Anyway, they're working on things like JIT compilation/optimization and messing around with writing plugins for PyPy to change the behavior of the language in various ways (like reimplementing Stackless).

Really, the interesting thing to me is that if PyPy really takes off, it promises to make Jython and IronPython and CPython obsolete, since it could be run on pretty much any platform. I'd also like to see a stable RPython that would be useful for application developers to write high performance Python. Of course, if they get the JIT compiler in order, you should pretty much get the same speed boost out of any piece of your code that conforms to the constraints of RPython, even if it's embedded in the middle of your Python program. Sadly, I keep reading that the JIT is currently pretty seriously broken, so who knows if it'll ever pan out.

If you're interested in the gritty details of it all, this Google Tech Talk goes into some depth on it. The sound gets better after a little while, but it's still kinda a lacking presentation.

tripwire posted:

This is a really cool post; I have a somewhat dumb followup question that you or someone else might be able to answer for me.

One of the things the pypy people mentioned was improving the performance and portability of the interpreter to the point where it would be faster and more compatible than ironpython/cpython/jython; specifically they mentioned picking up where psyco left off in terms of speeding up cpu-bound code. I realize one of the stated goals of pypy over psyco is that its not as dependant on architecture, but will pypy fully support 64-bit processors/code, and how easily will it mesh with parallel python or pyprocessing? I never even bothered to download and compile python in 32-bit compatibility mode to take advantage of psyco, and if I did I suspect it wouldn't play nice with parallel python, although I haven't tried it yet.
In a nutshell, does anyone know if the devs of pypy going to make it work out of the box on multicore systems on a 64-bit os?

tripwire posted:

I'm modifying the source of neat-python, which is a pretty decent implementation of NEAT to use.
One of the benefits of python that I'm really enjoying is how understandable the code is; if you want to learn about how neuroevolution works I'd recommend studying neat-python code over any of the c++ or even java implementations, which had a lot more code devoted to just making things work, or work fast. A lot of people will bitch and moan that python isn't suitable for number crunching but really that is misleading I think.

All of the CPU intensive parts of this code can be sped up by using psyco and special optimized c++ libraries for manipulating neural nets, but because I'm using this 32-bit simulation environment and my native python is incompatible (64-bit), I have to use the python packaged with the simulator, version 2.3. Because this interpreter is incompatible with my installed modules, I've simply been throwing my modified neat-python folder into the simulation directory and waiting for the simulator developer to hurry up and throw python 2.5 in there.

Right now I've pretty much mangled the code in my attempts to implement a steady state algorithm novelty search (first time using python, it's been a real learning experience), but once I'm satisfied thats its cleaned up enough to be legible and understandable (and once it works properly) I'll ask the dev to throw it on the SVN. Which is here by the way: http://code.google.com/p/neat-python/source/browse

chips posted:

I worked out how to discover the number of arguments of a method/function in Python, but it doesn't seem to have a way to discover the names of the arguments - anyone know if there would be a way to do this? I realize that in many languages, this probably doesn't make sense, since the names of arguments are just labels local to the definition of the function. If anyone has a nice guide on reflection in Python, it'd be appreciated - I could only find some rather obtuse references that led me to find im_func and so on, which I have to admit is slightly easier than PHP5's reflection methods.

Bozart posted:

I know this was a ways back, but thanks for this -- I've been going through the papers on NEAT and reading some of the python code and it is exactly what I have been looking for.

ashgromnies posted:

Bonus posted:

From the commandline, try navigating to the

code:

neat

directory and type in

code:

python setup.py install

at the terminal. I'm not sure if that's the procedure for that particular package, but that's how it usually goes.

ashgromnies posted:

code:

		if colorhash.get('r') and colorhash.get('g') and colorhash.get('b'):

Bozart posted:

Thanks for the pointer. I am now somewhat closer to my goal, however I wasn't kidding when I said I basically screw everything up.

It gives an error about having been built in VS2003 (the extensions for neat-python are written in c++) and that extensions have to be built using the same compiler. I don't own VS2003, but it also said that you can build it with mingw32. OK, sweet, I downloaded and installed mingw32, and then tried again with the additional option

code:

setup.py install -c mingw32

just like it suggests, but then it bombs out with the error message that mingw32 is an unrecognized command.

So I installed cygwin and then installed python under it, and installed gcc as well. Things compiled fine but now I can't use eclipse. (this is making me think I am doing things very wrong)

Also, when I tried to run the example/single_pole.py it tries to import genome2.py, I think, and that file or directory just doesn't exist. Help me please!

Habnabit posted:

I'm not sure whether this is it, but there's at least one thing to try:

code:

def getLight(self):
	pixel = self.red, self.green, self.blue
	maxi, dom = max((v, i) for i, v in enumerate(pixel))
	mini, dim = min((v, i) for i, v in enumerate(pixel))
	light = 0.5 * (maxi + mini)
	return light

Default arguments are evaluated at compile time, not call time. Also, you should use 'r' in colorhash etc., because colorhash.get('r') would evaluate to False if colorhash['r'] is 0.

http://docs.python.org/ref/function.html posted:

Default parameter values are evaluated when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that that same ``pre-computed'' value is used for each call. This is especially important to understand when a default parameter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function

Milde posted:

A tuple is immutable, it isn't an issue there. And you want @classmethod:

code:

>>> class Foo(object):
...     @classmethod
...     def bar(cls, baz):
...         print baz
... 
>>> Foo.bar(5)
5

Also I'm not sure what you're referring to with unit testing there. Python has several testing libraries, like doctest, which tests code examples of interactive interpreter output in doc strings, and unittest, which is a huge Java-like piece of poo poo.

nose is nice too. With nose you can just write functions starting with test_ and use assert.

Scaevolus posted:

In Python, 0 evaluates to False. (What you want is colorhash.has_key('r'))

ashgromnies posted:

I'm unsure of where you were going with your last example, but I got an example of the behavior I wanted working:

Habnabit posted:

That's a little messy. Why don't you just do it like this?

code:

class Pixel:
	def __init__(self, colorhash):
		if 'r' in colorhash and 'g' in colorhash and 'b' in colorhash:
			# rgb
			self.red = colorhash['r']
			self.green = colorhash['g']
			self.blue = colorhash['b']
		elif 'h' in colorhash and 's' in colorhash and 'b' in colorhash:
			# hsl
			raise NotImplementedError
		else:
			raise ValueError
	def getLight(self):
	    return getLight((self.red, self.green, self.blue))

def getLight(pixel):
	maxi, dom = max((v, i) for i, v in enumerate(pixel))
	mini, dim = min((v, i) for i, v in enumerate(pixel))
	light = 0.5 * (maxi + mini)
	return light

Also, has_key is deprecated, as is the new module. Instead, use in and the types module, respectively. The future of types is unknown in py3k currently, though I think it might remain under a different name. new will be gone for sure, though.

Milde posted:

I still have no idea what you're trying to accomplish, but it looks like you're making things more complicated than they need to be.

And while we're talking about style, you should be using new-style classes (e.g. class TestClass(object):) and you should just assign the attribute directly, instead of using __dict__.

ashgromnies posted:

I don't really like that because I can't call getLight on the Pixel class so it makes it harder to encapsulate. I would need to import that method from the file Pixel is stored in as well. I'd rather have it all in one class if I could.

I will check out types and try to replace new with it.

ashgromnies posted:

I don't see how I'm making things more complicated - it makes them easier and more reusable in the end, in my opinion. The Pixel class contains methods that act on Pixels. Sometimes I don't actually have an instance of a Pixel and don't need to make one because I won't be using it any more but would like to perform certain operations on an arbitrary (r,g,b) tuplet.

Habnabit posted:

No you wouldn't. Everything in a module, including functions and classes, is created aware of its surroundings. If it was in a separate module, it wouldn't check the caller's global namespace; that wouldn't make sense. It would check the global namespace in which it was defined.

Besides, it's rather weird to do it the way you want. Why not then just make one function and call that?

code:

def getLight(pixel):
    pixel = list(pixel)
    maxi, dom = max((v, i) for i, v in enumerate(pixel))
    mini, dim = min((v, i) for i, v in enumerate(pixel))
    light = 0.5 * (maxi + mini)
    return light

This, and then make Pixels convertible to lists.

e: stupid textmate, mixing tabs and spaces.

Habnabit posted:

What might seem easier or more intuitive can sometimes make more fragile code. I've seen some pretty broken APIs that rely on isinstance or type calls to try to determine what to do with the arguments passed to a method, effectively limiting themselves in the name of "convenience."