• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# Python, Can it work?

## 14 posts in this topic

Hello... Can anyone tell me your opinion on Python? To get you UNBIASED!!! Go to these sites. www.python.org Vpython pygame Post you complaints and I'll tell Guido, the creator of Python... His Electronic Mail Destination Yes, it's true, there should be a Java-Python-C++ language called Japyc or (Jah-PIC) Edited by - Andrew Nguyen on December 21, 2001 9:30:20 PM Edited by - Andrew Nguyen on December 21, 2001 9:31:52 PM
0

##### Share on other sites
never used it, been meaning to check it out, sounds cool
0

##### Share on other sites

Here is some code to get you running...
from visual import *# ruth chabay, carnegie mellon university, 2000-06# rings may be dragged through stuff - a little surrealscene.y=0scene.width=800scene.title="Tower of Hanoi"print "Move the stack with mouse buttons up to the white pole."maxradius=2.5thick=.5spacing=maxradius+thickleftpole=cylinder(pos=(-2*spacing,-3,0), radius=0.3, axis=(0,6,0))leftpole.color=(.5,.5,.5)midpole=cylinder(pos=(0,-3,0), radius=0.3, axis=(0,6,0))midpole.color=(.5,.5,.5)rightpole=cylinder(pos=(2*spacing,-3,0), radius=0.3, axis=(0,6,0))floor=box(pos=(0,-3.5,0), axis=(0,.99,0), height=23, width=5, color=(.6,.4,0))poles=[leftpole,midpole,rightpole]rings=[]hues=[(1,0,0), (1,1,0), (0,1,0), (.3,.3,1), (1,0,1)]for y in arange(-2, 3,1): rings.append(ring(pos=(poles[0].x,y,0), radius=.5*(3-y), color=hues[y+2], thickness=thick,axis=(0,1,0)))stack=[rings[:],[],[]] # list of rings on each poleselect=Nonescene.autoscale=0moves=0while 1: m=scene.mouse.getclick() # identify pole clicked on mx=m.project(normal=(0,0,1)).x pole=int((mx+floor.height/2.)/(floor.height/3.)) if select==None: # pick up a ring if len(stack[pole])>0: select=stack[pole][-1] # remove ring from stack del(stack[pole][-1]) while not scene.mouse.clicked: # drag ring select.pos=scene.mouse.project(normal=(0,0,1)) rate(60) else: # put down a ring if len(stack[pole])>0: # stack not empty if stack[pole][-1].radius > select.radius: # legal move select.x=poles[pole].x select.y=-2+len(stack[pole]) stack[pole].append(select) select=None moves=moves+1 else: # illegal move print "A ring may not be placed on a smaller ring." while not scene.mouse.clicked: # keep dragging ring select.pos=scene.mouse.project(normal=(0,0,1)) rate(60) else: # stack empty select.x=poles[pole].x select.y=-2 stack[pole].append(select) select=None moves=moves+1 if len(stack[2])==5: # task completed? print "You won in ",moves," moves." flash=0 while flash < 6: rightpole.color=(1,0,0) rate(10) rightpole.color=(1,1,1) rate(10) flash=flash+1 break

Well... I didn't write that code, it's really fun though...

Yes, it's true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)

Edited by - Andrew Nguyen on December 21, 2001 9:31:11 PM
0

##### Share on other sites
My opinion of Python.

It''s an awesome language for a beginner.
1) It''s easy to understand compared to other languages.
2) It forces you to indent and make your code look nice.
3) It has wide support.

Once you get higher up though, Python begins to get limited by its speed.
0

##### Share on other sites
Oh yeah, here ya go:
This will let you compile.

Yes, it''s true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)
0

##### Share on other sites
... That''ll speed it up REAL GOOD!!! Also, 3d is prttty fast comparativly to other thing...

Yes, it''s true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)
0

##### Share on other sites
Well here is my opinion then:

pros:
1) it is very elegant and nicely designed,
2) it is easy and powerful,
3) it''s quite fast for a scripting language,
4) it still exposes a lot of system functionnality,
5) it has very good exception handling,
6) the virtual machine is stable.

cons:
1) it''s HELL to embed in C++ (see below),
2) portability isn''t guaranteed (some different functions names and scripts names on Mac, see below),
3) it''s still not as fast as, say, Perl (but easier to read)

Embedding (C++):

Not only is exporting classes to Python hard and almost totally undocumented (like 99% of the embeddabled languages, btw), it''s also impossible to link to the Python library without using some ''tricks'' because 1) you can''t assume a libpython.so (on *nix) ''cause the name changes with the version (libpythonxxx.so) 2) it is a static library on *nix, shared on windows (no idea about mac). I had to add ugly m4 macros to get autoconf to find the lib on all platforms. Using ''freeze'' to make it a binary would be an option, but it would mean distributing one different binary file per system (meaning you need to find one of the said platforms to compile on, or use some kind of crosscompiler). This hell of embedding made me go for Guile whenever it comes to embedding a language (Lisp rules when it comes to AI anyway). Sadly, Guile is hardly portable at all... Go figure..

Portability :

Still related to embedding: the Python interpreter is started with Py_Initialize(), but on Mac with PyMac_Initialize(). Why a different name? Ok, it''s nothing that can''t be easily worked around when you have a preprocessor, but I still find it weird. Also, why is ''freeze'' named ''macfreeze'' on Mac?

Speed :

I still find it (sometimes much) slower than Perl for about everything. Maybe is it me not writting the ''best'' Python code, but given the nature of the language, I think writting good Python code is pretty straightforward. Compiling it into a binary file will result on a *large* file on *nix (because of the static library), and you''ll have to pray that your executable finds the python lib on windows (it''s a dll on windows). If shipping your own python dll on windows, you still have to make sure than it will load yours. I''d rather keep the Python code viewable and open.

Finally, I totally dislike the Python way to handle regexps, but that''s probably because of my Perl background (so it''s biased).

--

I haven''t tried PyGame. All I know is that it runs on top of SDL. I won''t use it mainly because I like to do the lower level stuff better than the higher level (writting libs/API/engines is what I like the best).

So please, don''t get me wrong, I love Python, I use it everyday, but, IMHO, it still has to mature a bit to be truly usable for games as the main development language (it''s already embedded in a lot of products, like Truespace, Blender, CrystalSpace, etc). And it still can''t replace Perl in my heart .

0

##### Share on other sites
quote:
Original post by Oluseyi
You should always have symbolic links to your library files, so that you can link without ambiguity (this also allows you to maintain multiple versions on the same machine). Mesa, for example, would follow this pattern:
libGL.so->libGL.2.so->libGL.2.2.so->libGL.2.2.15.so

Sadly, the Python directory also differs with the version (eg /usr/lib/python2.2). Creating a symlink in /usr/lib might work, but it wouldn''t be safe to assume than a given user on another platform will have that link, since Python doesn''t set it up.

quote:

I''m sure it''s possible to build shared objects under *nix. Currently I don''t run any of the *nixes, but I''ll be setting up a new workflow solution early next year and plan to investigate Python under Linux. You could <a mailto:seyisonaiya@hotmail.com>email me</a> so I''d have your address, and I''ll let you know how I fare (I''m the moderator of the Everything Unix forum).

Yes, it is possible but raises new problems: most people will just build it with a static library. While not a problem when running interpreted code, it once again becomes annoying when embedding (yes, my main complain is about embedding ).

Thx for the offer but, IIRC, building Python with shared lib support is just a matter of building it with -fpic and enabling ''shared'' in the setup file.

quote:

(...snipped...)
In regards to your other comments comparing Python with Perl, I agree as well. I have a definite preference for Perl (much more robust, doesn''t force any stylistic conventions on you, and embeds nicely in C/C++; plus, Perl is a valuable sysadmin tool - not so Python).

I personally find Python great for prototyping applications but wouldn''t use it for administrative tasks either.
0

##### Share on other sites
quote:
Original post by Anonymous Poster
Sadly, the Python directory also differs with the version (eg /usr/lib/python2.2). Creating a symlink in /usr/lib might work, but it wouldn''t be safe to assume than a given user on another platform will have that link, since Python doesn''t set it up.

In regards to this and the fact that most people build static libraries, perhaps you should advocate on the Python mailing lists that the standard makefiles be modified to set up the symbolic link and build a dynamic library? I assume the reason only the static version is being built cirrently is because most people use Python purely as a stand-alone scripting language. As more and more people embed it and advocate its use as an embedded solution, this step (modifying the makefiles) will become a necessity.

[ GDNet Start Here | GDNet FAQ | MS RTFM | STL | Google ]
Thanks to Kylotan for the idea!
0

##### Share on other sites
You know, I use python for games... sssslllllllooooooowwwwww games... Oh well...

Yes, it''s true,
there should be
a Java-Python-C++ language called Japyc
or (Jah-PIC)
0

##### Share on other sites
quote:
Original post by Anonymous Poster
Well here is my opinion then:

pros:
1) it is very elegant and nicely designed,
2) it is easy and powerful,
3) it''s quite fast for a scripting language,
4) it still exposes a lot of system functionnality,
5) it has very good exception handling,
6) the virtual machine is stable.

cons:
1) it''s HELL to embed in C++ (see below),
2) portability isn''t guaranteed (some different functions names and scripts names on Mac, see below),
3) it''s still not as fast as, say, Perl (but easier to read)

Embedding (C++):

Not only is exporting classes to Python hard and almost totally undocumented (like 99% of the embeddabled languages, btw), it''s also impossible to link to the Python library without using some ''tricks'' because 1) you can''t assume a libpython.so (on *nix) ''cause the name changes with the version (libpythonxxx.so) 2) it is a static library on *nix, shared on windows (no idea about mac). I had to add ugly m4 macros to get autoconf to find the lib on all platforms. Using ''freeze'' to make it a binary would be an option, but it would mean distributing one different binary file per system (meaning you need to find one of the said platforms to compile on, or use some kind of crosscompiler). This hell of embedding made me go for Guile whenever it comes to embedding a language (Lisp rules when it comes to AI anyway). Sadly, Guile is hardly portable at all... Go figure..

Most version of Unix and Linux hae these libs have links to the correct verison so you don''t need to worry about it and you can just call libpython.so

I''ve tried it on these Linux Distro: SuSE, Mandrake, Slackware
and on Sun''s Solaris 8.0

it worked without any problems...

"And that''s the bottom line cause I said so!"

** I WANT TO BE THE MODERATOR FOR THE LINUX FORUM **

Cyberdrek

Resist Windows XP''s Invasive Production Activation Technology!

"gitty up" -- Kramer
/(bb|[^b]{2})/ that is the Question -- ThinkGeek.com
Hash Bang Slash bin Slash Bash -- #!/bin/bash
0