m0nk3yz posted:

Why I like python: I enjoy both it's syntax, dynamic (latent) typing, standard library and truly enjoy programming in the language. I've been hacking in python for about (edit) 7 or 8 years at this point, and I have come to really enjoy the community and ecosystem around the language as well. Python is expressive and while I've run into bits of python code that make me WTF, I've rarely run into a chunk I couldn't read, or understand - you have to go out of your way (or be abusive with say, list comprehensions) to make python unreadable.

TasteMyHouse posted:

Since python is often recommended as a beginner's language (especially here in CoC) it'd be nice for there to be a short discussion / link to a discussion about interpreted vs compiled in general, the distinction between CPython and Python itself, etc. I know that stuff kind of confused me when I was looking at python and didn't know poo poo from poo poo.

Bonus posted:

Yeah I agree, Python is by far my favourite language. It's concise yet readable. It's just a joy to work in, I love how the modules work, the duck typing is great, all in all I really like it. Well, everything except the GIL in CPython, which basically prevents Python from running on multiple cores concurrently. However, there's a great module called Parallel Python which lets you do just that.

N.Z.'s Champion posted:

After hating on the XML processing in Python (4suite is sluggish and buggy) I found LXML and P4X. So use them unless you want to break your brain.

deimos posted:

http://effbot.org/librarybook/

I posted it earlier but OP hasn't added it.

deimos posted:

I am blind, sorry.


Now more on topic: woop, properties for 2.6 and 3k: http://bugs.python.org/issue1416

duck monster posted:

Ah. Nice. Much more elegant than the get_foo set_foo stuff.

I'm really keen on this decorator stuff. Lots of oportunities for aspect coding type stunts.

Hammertime posted:

I'm relatively python ignorant, I've only been learning it for a week or so ...
What's the point of threading in python with the GIL, excluding heavy I/O situations?
..snip

fake posted:

I still don't really understand why the GIL helps interpreter developers. They can't write threadsafe code?

bitprophet posted:

Look, between that whitespace bullshit and this inability to handle threading natively, I don't see how anyone can consider Python anything but a toy language

tef posted:

Docstings and pydoc.

http://www.diveintopython.org/getting_to_know_python/documenting_functions.html

http://docs.python.org/lib/module-pydoc.html

Hammertime posted:

Edit2: Well, it removes much of python's threading overhead. Doesn't solve the GIL problem though, still bound to a single core. Neat idea, seems a big waste of effort though, unless I've missed something.

FuraxVZ posted:

I'm looking to get into Python a bit; since I learn best from paper books, any recommendations? And yes, yes, I know, you learn by doing not reading, but I like books for grokking languages. Something with some good depth and the spirit of the language would be great.

The online Diving into Python is pretty good, and I was thinking of getting the dead-tree version. Is there better?

No Safe Word posted:

Casao posted:

I figure it's worth pointing out that PyObjC, which allows you to program native Coacoa apps for OSX ,now comes standard with Leopard and XCode, making Mac Python programming a bigger joy.

w_hat posted:

From one error to another:
Traceback (most recent call last):
File "C:\Python25\cpumon.py", line 44, in <module>
except pywintypes.error:
NameError: name 'pywintypes' is not defined

I should probably get around to actually learning Python instead of hacking it together.

porkface posted:

You guys know you can safely run multiple versions of Python on the same machine? You just have to set them up right, and choose which version you want to be your generic system-wide install.

deimos posted:

Things to add to the op:

Implementations
tinypy - http://www.tinypy.org/ - Sexy small implementation that compiles to C
pypy - http://codespeak.net/pypy/dist/pypy/doc/home.html - Almost self-hosting python implementation? Not sure.


Links:
Norvig's Infrequently asked questions - http://norvig.com/python-iaq.html - This man exemplifies elegant code. His solutions are just... beautiful.

Scaevolus posted:

I thought the Global Interpreter Lock made this form of threading pointless? Or are you doing multiple processes?

deimos posted:

I just realized I've been reading m0nk3yz's blog for a while if that's his PEP.

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?

Scaevolus posted:

Python 2.6b1 was released, changelog here

Things of note:

- Issue #2831: enumerate() now has a ``start`` argument.
- Issue #2138: Add factorial() the math module.
- Added the multiprocessing module, PEP 371.

tripwire posted:

m0nk3yz, I know you worked on pyprocessing so perhpas you can answer a stupid question. I'm trying to parallelize a serial python program; in the program there is a list of "chromosome" objects which are supposed to get a unique id when they are instanced. The relevant code for it looks like this:

code:

class Chromosome(object):
    _id = 0

    def __init__(self, some arguments..):
        self._id = self.__get_new_id()
        .
        .
        .
    id = property(lambda self: self._id)

    @classmethod
    def __get_new_id(cls):
        cls._id += 1
        return cls._id

My question is, what is the best/most elegant way to make sure that concurrent processes don't produce id's which collide with any other process?

Since new chromosomes are going to be generated constantly in a loop, should I give up just incrementing a counter to generate unique id's? Would it be better to rework the __get_new_id function such that it generates a pseudo-random value with a very low chance of collision? Would I be better off trying to make sure each concurrent process only access a central id factory in synchronization? There is probably a really simple solution but I'm too dumb to figure it out and I don't want to rush into trying to code without knowing what I'm trying to accomplish.

Bozart posted:

Why not just use the incremented IDs, and have each process remember its process ID. If you want to combine the results, you can create unique IDs then from the PID and innovation number. Also, I am not sure if NEAT would work if the innovation numbers were not strictly increasing, but I could be wrong. I would mainly just be way too lazy to go through the code and see what I would have to change to use random IDs instead of incremented ones, but to each their own.

bitprophet posted:

Not a bad idea (as long as you use the built-in "runserver" -- unless you're already a web dev, don't get bogged down with installing Apache or anything), doing the Django tutorial and then making a simple site will expose you to a lot of real-world Python very quickly

duck monster posted:

Except that literally every unix on the market except for the mac has a coherent policy on package management. I love the mac, but its package management has more in common with loving slackware than anything modern. Download tarball, compile and pray the gods will be benevolant. And no, easy_install will usually light on fire the minute its got to compile something and it becomes apparent that Apple puts things in different places to bsd's or SysV's. Reminder there are about 5 distros of python out there for the mac, none of which are compatible.

outlier posted:

That's not true - there's no problem with compiling a framework build for OSX. I routinely maintain 3 different pythons on my Mac (2.3 for backwards, 2.4 for zope, 2.5 for work). And once you factor eggs in, installing packages is a snap. So your original point is true - python works great on the mac.

(With, admittedly, some exceptions. Over the years I've sometimes had problems with libraries like PIL and MySQLdb that have to be compiled, but always able to eventually hack around them. And I've had problems with these libraries under Redhat as well, so it's difficult to see OSX as deficit in this regard.)

Bozart posted:

This, 1000 times.