Avenging Dentist posted:

Here you go. I did it in a single statement if you don't count the imports (EDIT: who needs import when you have __import__) (EDITx2: wait I can make multiline lambdas a lot simpler):

code:

print("Heads came up {0} times.\nTails came up {1} times.".format(*__import__('functools').reduce(
lambda T, x: (print(['Heads!', 'Tails!'][x]), [T[0] + int(x==0), T[1] + int(x==1)])[-1],
(__import__('random').randint(0, 1) for _ in range(10)), [0, 0])))

Indented: http://pastebin.com/cfBXNSsZ

m0nk3yz posted:

Wow, just wow. I need to find some way of using this in real code, just to be a dick.

m0nk3yz posted:

Wow, just wow. I need to find some way of using this in real code, just to be a dick.

AzraelNewtype posted:

The added comments above are important. Yay asked you before, but you left that out of what you replied to. I'm honestly curious what you think is going on here, and it's not really worth explaining what is happening until you answer.

Mr. Clark2 posted:

I throw myself upon the mercy of the python gods...

Benji the Blade posted:

I know that it can sometimes be difficult to determine intent on the internet, but people are not pressing this issue to make you feel bad or to make fun of you or revel in our superiority. We're pressing you on this to try to figure out what misconception led you to believe that that line would do something so that we can help you learn what's actually going on. There's nothing wrong with not understanding.

Emo Businessman posted:

Avenging Dentist posted:

Here you go. I did it in a single statement if you don't count the imports (EDIT: who needs import when you have __import__) (EDITx2: wait I can make multiline lambdas a lot simpler):

code:

print("Heads came up {0} times.\nTails came up {1} times.".format(*__import__('functools').reduce(
lambda T, x: (print(['Heads!', 'Tails!'][x]), [T[0] + int(x==0), T[1] + int(x==1)])[-1],
(__import__('random').randint(0, 1) for _ in range(10)), [0, 0])))

Indented: http://pastebin.com/cfBXNSsZ

Habnabit posted:

Well I'm going to (again!) suggest cython instead of ctypes; it's much less effort for much higher-quality bindings.

[cython stuff]

(If you really hate yourself and want to use ctypes: count the number of dereferences your C code is doing vs. the types you have declared in ctypes.)

e: whoops, I realized I didn't check the return value of the callocs. Proper error handling is left as an exercise to the reader.

Captain Capacitor posted:

I'm just going to add something to this (possibly because I just gave a talk on it for my local python group), that writing extensions in C isn't all that difficult. The API provides a nice set of functions for building Python objects.

Habnabit posted:

There is basically no reason to not use cython at this point.

Avenging Dentist posted:

There's tons of reasons, and one of the big ones is "Cython just provides the illusion of easiness for people who are uncomfortable with C". Writing C extension modules for Python is really loving easy. In many places, I find it easier than writing the equivalent code in Python. Cython isn't actually good for everything.

Habnabit posted:

I meant to say when making python bindings to C libraries.

Habnabit posted:

Writing C extensions for python still involves a lot of boilerplate if you're doing anything involving argument parsing, refcounting, or defining functions/classes/methods. Cython removes all of this.

Habnabit posted:

Not only that, it by default produces C extensions that are compatible with python 2.3-3.1. That would, again, take a bunch of boilerplate to get right in just C.

Avenging Dentist posted:

...stuff...

Avenging Dentist posted:

Arg parsing is two lines of code in C (including error handling) and is considerably more flexible than in Python. It's also one of the main reasons I prefer writing stuff in C, since it actually allows you to do reasonable things like type-checking arguments and supplying poor-man's overloading without having ludicrous amounts of type-checking in your Python code. Granted, Cython can do limited typechecking (as I recall), but having access to more advanced arg parsing features (e.g. converter functions) is a godsend.

Avenging Dentist posted:

You seem to be under the strange impression that boilerplate is something that you should strive to avoid at all costs, when in reality, much of the boilerplate in a C extension module is a one-time thing that doesn't actually disrupt development in any way once you've done it that one time. The benefit you get for this small amount of effort is a massive improvement in clarity by maintaining a logical separation between Python and C, as well as easy access to the Python C API's more useful features that are strangely absent in Python.

Avenging Dentist posted:

The fact is, unless you are simply binding C to Python without doing anything special, the majority of your code is going to deal with talking to C stuff. And if you are simply binding C to Python without doing anything special, you should be using SWIG. In writing a C extension module, I found that the overwhelming majority of my code was stuff that Cython would do absolutely nothing to help with, e.g. simple conditionals and actual calls to the underlying C library.

Avenging Dentist posted:

Refcounting is trivially easy and if you have to manage refcounts often when you're just binding C functions, you're doing something wrong. I think the only time I even touch refcounts (with one or two exceptions) is when converting stuff to NumPy arrays.

Avenging Dentist posted:

Doing that in C consists of a handful of tiny changes in the module init func for 3.x compatibility. Provided you pay a tiny amount of attention to the Python C API docs, you'll have zero problems until you hit the 3.x bump.

m0nk3yz posted:

And Ctypes is perfectly good for the rest of us

Thermopyle posted:

code:

(test) C:\Users\Therms> pip install -e hg+[url]http://bitbucket.org/alberanid/imdbpy#egg=imdbpy[/url]

...wall of text with no obvious errors...

code:

(test) C:\Users\Therms>search_movie.py "the matrix"
Traceback (most recent call last):
  File "C:\Users\Therms\test\Scripts\search_movie.py", line 4, in <module>
    from pkg_resources import require; require('IMDbPY==4.6dev-20100521')
  File "C:\Python26\lib\site-packages\pkg_resources.py", line 2603, in <module>
    working_set.require(__requires__)
  File "C:\Python26\lib\site-packages\pkg_resources.py", line 666, in require
    needed = self.resolve(parse_requirements(requirements))
  File "C:\Python26\lib\site-packages\pkg_resources.py", line 565, in resolve
    raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: IMDbPY==4.6dev-20100521

All of the command line scripts that come with the IMDbPY package return this error. Actually using IMDbPY in my own scripts works fine. For example, the following functions correctly:

code:

>>> import imdb
>>> imdb_access = imdb.IMDb()
>>> imdb_access.search_movie("the matrix")
[<Movie id:0133093[http] title:_The Matrix (1999)_>, <Movie id:0234215[http] tit
le:_The Matrix Reloaded (2003)_>, <Movie id:0242653[http] title:_The Matrix Revo
lutions (2003)_>, <Movie id:0092106[http] title:_The Transformers: The Movie (19
86)_>, <Movie id:1392983[http] title:_The Father (2010)_>, <Movie id:0295432[htt
p] title:_The Matrix Revisited (2001) (V)_>, <Movie id:0277828[http] title:_Ente
r the Matrix (2003) (VG)_>, <Movie id:0274085[http] title:_Sex and the Matrix (2
000) (TV)_>, <Movie id:0451118[http] title:_The Matrix: Path of Neo (2005) (VG)_
>, <Movie id:0117021[http] title:_Menno's Mind (1997)_>, <Movie id:0365467[http]
 title:_Making 'The Matrix' (1999) (TV)_>, <Movie id:0390244[http] title:_The Ma
trix Online (2005) (VG)_>, <Movie id:0437137[http] title:_Crash Course (2003) (V
)_>, <Movie id:0391319[http] title:_Making 'Enter the Matrix' (2003) (V)_>, <Mov
ie id:0439783[http] title:_Return to Source: Philosophy & 'The Matrix' (2004) (V
)_>, <Movie id:0410519[http] title:_The Matrix Recalibrated (2004) (V)_>, <Movie
 id:1074193[http] title:_Decoded: The Making of 'The Matrix Reloaded' (2003) (TV
)_>, <Movie id:1499960[http] title:_The Living Matrix (2009)_>, <Movie id:038915
0[http] title:_The Matrix Defence (2003) (TV)_>, <Movie id:0438231[http] title:_
The Matrix: The Movie Special (1999) (TV)_>]

So this has something to do with how pip is installing this package. Since pip and easy_install are a big mystery to me, I was hoping someone can point me in the right direction for fixing this. It's seems obvious that it has something to do with what the install thinks is the required version for the scripts that are packaged with the package, but I don't know where it's getting that required version from, nor what it thinks the version I installed actually is.

As an example of my cluelessness, in the install command above, I don't really know if it matters what I put as the package name in the "#egg=imdbpy" part. I just thought it seemed like a good idea, and it did install...

edit: As per usual, 5 minutes after I posted I figured it out. I guess since .py files are associated with the system-wide installation of python, you have to actually type "python script.py" when using pip to be sure and use the virtualenv...

Habnabit posted:

Either way, overloading is a silly thing to try to do in python.

Habnabit posted:

And while cython doesn't support converter functions, as far as I understand their utility, they're not really useful with cython's other features.

Habnabit posted:

It really seems like you're confused about how cython works, between the last few lines here and your earlier comments about typechecking and argument parsing in python. You can call anything within the python C API directly from cython basically without any effort.

Habnabit posted:

Cython lets you do both in one module.

Avenging Dentist posted:

Habnabit posted:

I can't help but notice that you didn't refute my points about reference counting and exception handling.

Avenging Dentist posted:

If you'd really rather me say "manually handling exceptions and reference counts is not hard" again, I can do it, but I fail to see how it adds to the discussion in any way.

Avenging Dentist posted:

You're welcome to use Cython, but saying, "There is basically no reason to not use cython at this point," is pretty ignorant and basically just a childish "my way or the highway" attitude. It would be like me saying, "There is basically no reason to not use C++ at this point."

Habnabit posted:

See uh I just don't know what imaginary metric you're basing that on, when it the opposite seems to be agreed on enough to warrant mentions in the python documentation.

Habnabit posted:

While there are some things it can't do (easily), yes, these are solved by including some .c files along with the .pyx files.

quote:

... all symbols in extension modules should be declared static, except for the module’s initialization function, in order to avoid name clashes with other extension modules ...

Avenging Dentist posted:

I certainly hope you're not doing that, since that would likely mean you have non-static names in your extension module (in order to access them across translation units), and Python explicitly recommends against this

ShoulderDaemon posted:

After doing all the linking to create the final object file for the module, you can go back and strip any symbols that shouldn't be visible to the outside world. This is fairly normal practice for shared libraries anyway, although that doesn't mean the python community does it when they should.

Avenging Dentist posted:

If you actually think properly handling errors is hard, as opposed to merely something you need to pay a modicum of attention to, then you are not very good at programming. Sorry, but this just isn't even remotely challenging, unless "paying attention" is something you consider challenging.

Avenging Dentist posted:

I certainly hope you're not doing that, since that would likely mean you have non-static names in your extension module (in order to access them across translation units), and Python explicitly recommends against this:

At first, I thought Cython might be smart enough to handle something like this, but it seems that, far from it, it actually generates .c files on its own, essentially requiring at least a handful of non-static names to appear in the C source so that things can be properly initialized in the module init function.

Avenging Dentist posted:

Cython definitely doesn't, and last I checked, distutils and friends don't either.

Habnabit posted:

Trying to avoid this whole mess is basically the reason people use python in the first place. Since, unfortunately, not all software is written in python, there needs to be something to bridge the gap.

Avenging Dentist posted:

I think we're done here.

Habnabit posted:

I'm just curious what you think the point of using python over C is, then.

Avenging Dentist posted:

Fear of curly braces?

Otto Skorzeny posted:

No, not having an awesome enough moustache to use Perl is the reason people use Python

Avenging Dentist posted:

Fear of curly braces?

Avenging Dentist posted:

Here you go. I did it in a single statement if you don't count the imports (EDIT: who needs import when you have __import__) (EDITx2: wait I can make multiline lambdas a lot simpler):

code:

print("Heads came up {0} times.\nTails came up {1} times.".format(*__import__('functools').reduce(
lambda T, x: (print(['Heads!', 'Tails!'][x]), [T[0] + int(x==0), T[1] + int(x==1)])[-1],
(__import__('random').randint(0, 1) for _ in range(10)), [0, 0])))

Indented: http://pastebin.com/cfBXNSsZ

passionate dongs posted:

I am translating some python into javascript, and I am confused by the following bit of code:

code:

sqrt(sum((v1-v2)**2))

What is **2? I am not a python developer and am failing at finding anything with google.

yatagan posted:

http://www.devshed.com/c/a/Python/Python-Operators/1/

Googling "python operator" was hard.