True. Still, some might see a distinction between the compiler taking code that a human has made, breaking it down and optimizing the calls into operations, and then assembling that vs. using python to make calls to functions written in python that call functions that someone else has written in C.
Of course, all of this is just academic (vaguely :p). The cool thing about this thread is that Elias' request was not met with "use C, n00b", "> suggesting python should be used for low level ops..", or even just silence. Instead, pygame-users explained the logical issues with the request (that the OP likely wasn't aware of), and explained why the request becomes more of a question of semantics than anything else. As well, they offered suggestions for what could qualify as the next closest method to fulfill that request. That is cool. But yeah: If you want to use python's syntax to work with low-level graphics calls, the modules with low-level bindings can offer a pretty direct 'middle man.' If you want to write C to use the libraries those wrap directly, that's a possibility (and not as hard as it looks at first.) Or if you really want to get into it (mostly just useful for education, but we wouldn't be here if pedagogy wasn't of some interest), try out some assembly. You will need to emulate an older set of hardware, since as far as I'm aware things like 0x13h mode don't exist anymore, and as far as I know most APIs to directly access a graphics card are going to be in C (if I'm mistaken here, someone please correct me.) If your overall goal is to get a better understanding of how graphics and programming in general work, doing a small project in each of these languages in order could be pretty enlightening (this is how it 'clicked' for me, at least) -- tutorial links included: 1. Pygame ["Okay, so I take input, then I update the values from that input, and then I draw.. I guess that's easy enough?] http://inventwithpython.com/ 2. 6502 Assembly (NES) [Registers, memory management, reading/writing to ports/specific addresses, what loops, containers, and other things we take for granted actually look like, etc.] http://www.nintendoage.com/pub/faq/NA/nerdy_nights_out.html 3. C [Working directly with C and SDL or OpenGL calls] http://www.lazyfoo.net/SDL_tutorials/ (SDL) && <I'm not sure what a solid, modern opengl tutorial would be; can anyone provide a link? :p> 4. C/Pygame ["Now that I understand how all that boilerplate works, I can feel comfortable using 'shortcuts', since I see the benefits they really offer (so now the only benefit of rolling my own is going to be '..just 'cause' 95% of the time), and can foresee/avoid the things that could cause bottlenecks. Or I can use C since I want to experiment with designing more complex 3d shaders, physics, etc. Or just because I think it's fun to use C."] [Sorry for the wall of text; hopefully it's helpful] On Thu, Feb 7, 2013 at 11:20 PM, Julian <onp...@gmail.com> wrote: > On 02/07/2013 10:06 PM, Ian Mallett wrote: > >> The point is that you need to go through some kind of middle layer. >> Python code, by definition, does not interface directly with anything--you >> must go through some library/package--whether it is a built-in within >> Python's runtime, a 3rd-party distribution, or a wrapper you make around >> existing C functionality. >> > > Well, if you want to get really technical, only machine code interfaces > directly with anything. C abstracts this so your code can work on more than > one type of processor. Even assembly languages abstract a little bit, if > I'm not mistaken, though it's pretty direct. >
