|
Avenging Dentist posted:Here you go. I did it in a single statement Wow, just wow. I need to find some way of using this in real code, just to be a dick.
|
# ? May 20, 2010 00:54 |
|
|
# ? Jun 13, 2024 04:01 |
|
m0nk3yz posted:Wow, just wow. I need to find some way of using this in real code, just to be a dick. That would be awesome. Of course, if I read it in some real code, I would track you down and stab you in the eyeball.
|
# ? May 20, 2010 01:02 |
|
m0nk3yz posted:Wow, just wow. I need to find some way of using this in real code, just to be a dick. I could actually see someone use multi-expression lambdas in some ill-considered plan to be "concise". The syntax is almost sensible.
|
# ? May 20, 2010 01:54 |
|
I totally hadn't noticed the counting at the end; talk about glossing over an import part That is some insanely clever code, mr. Avenging Dentist. Myself, I was thinking of something along the line of (now with counting?): code:
Yay fucked around with this message at 11:58 on May 20, 2010 |
# ? May 20, 2010 11:55 |
|
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. I can see now that those two lines did absolutely nothing. At the time, I wrongly thought that I needed them in there to 'flip' the coin again. After doing some more reading and experimenting, I see that they are not necessary, and that 'flip' at the beginning of the loop takes care of that. I throw myself upon the mercy of the python gods...
|
# ? May 20, 2010 15:49 |
|
Mr. Clark2 posted:I throw myself upon the mercy of the python gods... 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.
|
# ? May 20, 2010 16:37 |
|
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. Point taken. I welcome and and all constructive criticisms
|
# ? May 20, 2010 19:26 |
|
I have come across a library written in C, and I want to use Python's ctypes to access it. However, I'm currently stuck at attempting to pass an array of structs to one of the functions inside the library, and to paste the entire codebase would be a little much, so I constructed a short little example: My test library: code:
My test python program: code:
code:
|
# ? May 20, 2010 21:53 |
|
Emo Businessman posted:Well I'm going to (again!) suggest cython instead of ctypes; it's much less effort for much higher-quality bindings. code:
code:
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. Habnabit fucked around with this message at 18:36 on May 24, 2010 |
# ? May 21, 2010 09:29 |
|
Avenging Dentist posted:Here you go. I did it in a single statement code:
|
# ? May 21, 2010 12:57 |
|
code:
code:
code:
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... Thermopyle fucked around with this message at 18:27 on May 21, 2010 |
# ? May 21, 2010 17:50 |
|
Habnabit posted:Well I'm going to (again!) suggest cython instead of ctypes; it's much less effort for much higher-quality bindings. 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.
|
# ? May 21, 2010 19:06 |
|
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. Sure. It's not hard; cython just removes all of the stupid boilerplate that writing C extensions requires. There is basically no reason to not use cython at this point. There is some stuff that cython can't do (easily), and for these things I just write some extra .c files that I link into the same extension module.
|
# ? May 21, 2010 21:47 |
|
Habnabit posted:There is basically no reason to not use cython at this point. 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.
|
# ? May 21, 2010 21:51 |
|
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. I meant to say when making python bindings to C libraries. 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. 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.
|
# ? May 21, 2010 22:07 |
|
Habnabit posted:I meant to say when making python bindings to C libraries. This is exactly the sort of thing I wouldn't use Cython for. What I would use it for is to optimize existing Python code in cases where I don't need to deal with anything C-specific. 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. 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. 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. Defining functions/classes/methods are all easy and trivial to macro if you're doing it a lot and have some specific stuff in common. For instance, I have all my docstrings in an external header file and macro it in based on the function name. 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. 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. 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. 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. EDIT: Granted, the specifics will vary depending on the specific C code you're interfacing with, but I'd have probably killed myself if I had to deal with it in my project. Avenging Dentist fucked around with this message at 22:46 on May 21, 2010 |
# ? May 21, 2010 22:37 |
|
Avenging Dentist posted:...stuff... And Ctypes is perfectly good for the rest of us
|
# ? May 22, 2010 01:10 |
|
Being pretty inexperienced I often have a hard time judging the quality/reliability/pitfalls of modules that don't have a lot of online ink written about them. So.... I ask, has anyone here used y_serial? On the surface, it seems like a pretty cool module for data persistence. I have a soft spot for useful modules that use nothing but standard library and are pure python. Thoughts? (As a side note it's some of the most usefully documented code I've ever read...very educational to an amateur like me)
|
# ? May 22, 2010 01:56 |
|
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. code:
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. Also, refcounting is only superficially trivially easy because it's easy to forget which things can implicitly execute arbitrary code. The extending/embedding tutorial points out a bug that was in python when explaining the potential perils of refcounting.. Cython does a lot of work and testing to ensure that its generated increfs/decrefs are correct. 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. e: Oh, yes, I forgot a few things. Exception handling is another thing that cython makes amazingly trivial. When making python C API calls, it gets rather tedious rather quickly to check every return value to see if an exception was raised. Trying to emulate try-except-else-finally blocks also starts getting tedious quickly; just look at this trivial example in the docs.. That example also illustrates another thing cython takes care of for you: decreffing everything properly when you have to do an error return from a function. You still have to remember to clean up resources allocated from your C library, but putting that code in a try-finally block is easy enough. Also sequence unpacking. It's a very minor thing, but it can definitely clean up the API you expose to python to support it. You could require a tuple and then use PyTuple_GET_ITEM or whatever, but why bother when you can support arbitrary sequence types? m0nk3yz posted:And Ctypes is perfectly good for the rest of us Habnabit fucked around with this message at 03:30 on May 22, 2010 |
# ? May 22, 2010 03:19 |
|
Thermopyle posted:
it seems your search_movie.py script wants a specific version of IMDBpy (4.6dev-20100521), and the version you have installed (from mercurial) is different. In the python prompt if you import IMDBpy and try to get it to print out it's version, I bet it will say something other than 4.6dev-20100521.
|
# ? May 22, 2010 05:03 |
|
Habnabit posted:Either way, overloading is a silly thing to try to do in python. Yeah, because using magic functions like __len__ is clearly a smarter solution. (This is one of the things I absolutely cannot stand about Python, though I guess it lets them avoid stuff like ADL.) Incidentally, the type of overloading I'm talking about is the type used by NumPy, e.g. overloading for arrays and array scalars. 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. Until Python decides to add something standard-ish that approximates (type-safe) enumerations, I'll stick with converter functions. 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. And I mentioned that I was aware of this (though I'm not aware of all of its semantics, e.g. when working with NumPy array scalars). Habnabit posted:Cython lets you do both in one module. So does C, and for a person comfortable with C, the benefit of Cython essentially boils down to "reducing a small amount of tedium", which isn't really a problem for a fast typist with a decent editor. What I'm trying to get at here is that, if you're actually fluent in C, the benefit to using a Frankensteinian language to hide "real" C code from you is vastly overblown. I'm not trying to be down on Cython. If someone prefers it, then fine. There are even a couple places that Cython would simplify my code. But those places are pretty rare and I honestly prefer the C API to Python proper (or Cython) in "library" development. To be honest though, one of the main reasons I'm glad I chose the C API is that I now have a very clear picture of the CPython and NumPy internals, which has helped me enormously, especially when trying to do non-trivial things with NumPy.
|
# ? May 22, 2010 05:54 |
|
Oh god, I'm siding with Avenging Dentist...what the hell is wrong with me?
|
# ? May 22, 2010 08:16 |
|
Avenging Dentist posted:I can't help but notice that you didn't refute my points about reference counting and exception handling. Both of these things are very, very easy to screw up with how many times you have to account for them in C code, and cython handles both automatically. I would definitely not call this a small amount of tedium, especially when the python C API tutorial/reference points out very clearly that these are easy things to screw up. I would call myself fluent in C, but I still would prefer to reduce the number of potential failure points in my code.
|
# ? May 22, 2010 09:38 |
|
Habnabit posted:I can't help but notice that you didn't refute my points about reference counting and exception handling. 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. 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."
|
# ? May 22, 2010 16:01 |
|
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." And if it's good enough for lxml, ...
|
# ? May 22, 2010 19:00 |
|
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. 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. This is, of course, massively dependent on how much interaction with Python you need for your project, and that's really my point in all this: if you spend more time interacting with C stuff than with Python stuff, you might as well just use C because the benefits you get from Cython will be spread so thin that you're not gaining much. This was my experience, but this is probably in no small part because the code I was binding was already fairly "Pythonic", especially for something written in C and designed to work with Fortran. 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. 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: 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 ... 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.
|
# ? May 22, 2010 22:23 |
|
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 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.
|
# ? May 22, 2010 22:35 |
|
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. Cython definitely doesn't, and last I checked, distutils and friends don't either. Of course, in practice, this probably won't come up unless you're using really common names, but then again, neither will errors related to memory allocation (especially on Linux where malloc() essentially always succeeds and will only fail later when you actually try to use it).
|
# ? May 22, 2010 22:47 |
|
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. I agree that handling errors is not hard, but the python C API isn't exactly small. I wouldn't exactly say it's easy to try to memorize all of the different semantics of every API call. (And then, like I said before, you have to deal with all of your temporary python objects and being able to clean them all up regardless of which part of your code threw the exception.) 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 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: Avenging Dentist posted:Cython definitely doesn't, and last I checked, distutils and friends don't either. Habnabit fucked around with this message at 22:59 on May 22, 2010 |
# ? May 22, 2010 22:52 |
|
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. I think we're done here.
|
# ? May 22, 2010 22:58 |
|
No, not having an awesome enough moustache to use Perl is the reason people use Python
|
# ? May 22, 2010 22:59 |
|
Avenging Dentist posted:I think we're done here. I'm just curious what you think the point of using python over C is, then.
|
# ? May 22, 2010 22:59 |
|
Habnabit posted:I'm just curious what you think the point of using python over C is, then. Fear of curly braces?
|
# ? May 22, 2010 23:17 |
|
Avenging Dentist posted:Fear of curly braces? Right, fear of redundant cruft.
|
# ? May 22, 2010 23:19 |
|
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? :{)
|
# ? May 23, 2010 02:21 |
|
Avenging Dentist posted:Here you go. I did it in a single statement hahah.. I hope that's code you'd only write for fun and never for a project. I would boot that so fast Insanely clever though.
|
# ? May 23, 2010 20:35 |
|
I am translating some python into javascript, and I am confused by the following bit of code:code:
|
# ? May 27, 2010 07:47 |
|
passionate dongs posted:I am translating some python into javascript, and I am confused by the following bit of code: http://www.devshed.com/c/a/Python/Python-Operators/1/ Googling "python operator" was hard.
|
# ? May 27, 2010 07:49 |
|
yatagan posted:http://www.devshed.com/c/a/Python/Python-Operators/1/ I don't know why that didn't cross my mind. I feel like an idiot. thanks.
|
# ? May 27, 2010 07:55 |
|
|
# ? Jun 13, 2024 04:01 |
|
Is there a popular extension framework for python? Something like MEF/MonoAddins/JPF/Boost-Extension. Currently I am using my own plug-in manager(__import__+ a lot of fluff), but I would much rather use something else if a good plug-in framework exist. This is mostly because I want to have extension information(author, version, and title info) files stored along side the module and I do not want to write a parser. Currently I am storing that information in the module and hoping that plugs keep their modifications inside the activate and deactivate methods.
|
# ? May 27, 2010 08:28 |