@JonasR: ich hab random schon vor jedem Test gleich ge-seed()-et

Evtl kannst du das noch beschleunigen, in dem du den float-Vergleich 'richtig' machst ('abs(x-y) < EPSILON', mit einem passenden EPSILON).
Folgendes braucht hier ~3min, die originale Funktion ist nach ~20min noch nicht fertig.
def dummy_funktion(a, b, c, d):
gauss = random.gauss
eps = 1.0e-8 ...

Welches 'erste Beispiel'? Etwa das, bei dem dransteht:
Functionality within this package requires that the __main__ module be importable by the children. This is covered in Programming guidelines however it is worth pointing out here. This means that some examples, such as the multiprocessing.Pool ...

Da probier ich gleich mal meine neuen erlang-Kenntnisse aus.

@mohack: Bekommst Du das gewünschte Ergebnis, wenn du datetime.date()-Objecte verwendest?

Dein Return-type ist 'tuple()'. Und dieses tuple wird von Python automatisch ausgepackt:

In [1]: def foo():
...: return 42, 17+4
...:

In [2]: a = foo()

In [3]: repr(a)
Out[3]: '(42, 21)'

In [4]: type(a)
Out[4]: <type 'tuple'>

In [5]: b, c = foo()

In [6]: b
Out[6]: 42

In [7]: c
Out[7]: 21 ...

Naja, ist doch bloß sowas: .. das sieht python schon sehr ähnlich

Sollte das Script so aussehen/funktionieren?
#!python3.2
import os

DATA_FILE = r'a.txt' # Pfad anpassen!

def main():
cwd = os.getcwd()
print("Creating Folder in '{:s}'".format(cwd))
with open(DATA_FILE, 'rt') as names_file:
for line_number, line in enumerate(names_file):
folder_name ...

Mathek hat geschrieben:OSX läuft auf 64-bit, aber Python nicht. Gibt es das überhaupt als 64-Bit Version?

Bestimmt, schau mal nach

Ich hab das mal minimal optimiert , aber wenn ich beide Funktionen auf den selben Pfad loslasse - egal in welcher Reihenfolge - ist die zweite 10x schneller (logisch, jedes OS hat 'nen Cache für die Festplatte).

Wie misst man das denn 'richtig' (Cache, os.path.join vs. os.chdir, rekursion )? :K ...

Warum?

Weil Unicode-literale in Ipython nicht richtig funktionieren: Man kann sowas wie "u=lambda s: s.decode(...)" als Würg-around benutzen.

Ich bin gerade über Tim Golden's FAQ zum win32-module 'gestolpert', da dachte ich mir, ich trag das hier nach.

Funktioniert numpy überhaupt mit ironpython?

Die schleife ist doch eh' unnötig - das geht mit numpy doch anders:
import numpy as num
eSARdBrefx = A \
+ 10 * num.log10(eSARV) \
+ self.BCref[modname][0] * num.log10(1 + self.BCref[modname][1] + eSARV)
eSARdBrefy = A \
+ 10 * num.log10(iSARV) \
+ self.BCref[modname][2] * num.log10(1 + self ...

Darii hat geschrieben:Vielleicht sollte man aber wirklich für Web eine neue Sprache erfinden und sie nach JS kompillieren.

Sowas wie Python?
Die Idee klingt gut, aber ich finde auf die schnelle nicht mal, welche Python-Version da unterstützt wird.

Ich meine, dass hier unnötig einzelne kerne 'aufgeweckt' werden, statt nur einen auf Vollast laufen zu lassen, im Prinzip wie hier, bei lesswatts.org. erklärt - ich finde nur auf die schnelle nichts konkreteres.

Z.B. Cool 'n' quiet, d.h. bei meinem Phenom II werden die Kerne im Leerlauf einzeln von 3100MHz bei 1,35V auf 800MHz bei 1,0V, runtergetaktet.
edit:
Oder auch einfach die ACPI-geschichten

@Rebecca: nur ein Kern auf einmal war klar -- mir war nicht klar, dass trotzdem mehrere Kerne genutzt werden (z.B. sind dann einige Stromspar-mechanismen dahin)

Okay, Python ist nicht an eine CPU gebunden (Wenn ich drüber nachdenke, wieso sollte es?) - ein simples Testprogramm wechselt bei mir zwischen den zwei Kernen hin und her.

Noch offtopic'er: weil threads unter Java so viel nützlicher sind hat Sun ja sowas entwickelt: mit 8x8 Threads in Hardware

'multiprocessing' started zusätzliche Interpreter*, da gibt's dann entsprechend mehrere GILs, 'threading' nutzt nur einen interpreter, einen GIL und AFAIK nur einen Prozessor(-kern).
Aber ohne threading hat man auch kaum einen/keinen Vorteil von C-Funktionen, die den GIL freigeben.

* Deshalb ist ...