Jump to content

  • Log In with Google      Sign In   
  • Create Account


Python, Can it work?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
14 replies to this topic

#1 Andrew Nguyen   Members   -  Reputation: 150

Like
Likes
Like

Posted 21 December 2001 - 01:17 PM

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

Sponsor:

#2 Shannon Barber   Moderators   -  Reputation: 1361

Like
Likes
Like

Posted 21 December 2001 - 02:14 PM

never used it, been meaning to check it out, sounds cool

#3 Andrew Nguyen   Members   -  Reputation: 150

Like
Likes
Like

Posted 21 December 2001 - 02:29 PM



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 surreal

scene.y=0
scene.width=800
scene.title="Tower of Hanoi"
print "Move the stack with mouse buttons up to the white pole."

maxradius=2.5
thick=.5
spacing=maxradius+thick
leftpole=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 pole
select=None
scene.autoscale=0
moves=0

while 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

#4 Nytegard   Members   -  Reputation: 820

Like
Likes
Like

Posted 21 December 2001 - 02:52 PM

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.

#5 Andrew Nguyen   Members   -  Reputation: 150

Like
Likes
Like

Posted 21 December 2001 - 02:55 PM

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)

#6 Andrew Nguyen   Members   -  Reputation: 150

Like
Likes
Like

Posted 21 December 2001 - 03:06 PM

... 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)

#7 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 21 December 2001 - 05:04 PM

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 .

Anyway, that''s my (unbiased) 0.02$.

#8 Andrew Nguyen   Members   -  Reputation: 150

Like
Likes
Like

Posted 22 December 2001 - 03:29 AM

Yes, But, Python would be much faster if there were more people working on it... Heck, if it ever becomes faster than C++ then C++ would have to worked on... which do you choose...



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

#9 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 22 December 2001 - 03:51 AM

quote:
Heck, if it ever becomes faster than C++ then C++ would have to worked on... which do you choose...


An interpreted language will never surpass the speed of compiled code since it has to be parsed at runtime.

#10 Oluseyi   Staff Emeritus   -  Reputation: 1678

Like
Likes
Like

Posted 22 December 2001 - 03:54 AM

quote:
Original post by Anonymous Poster
1) you can''t assume a libpython.so (on *nix) ''cause the name changes with the version (libpythonxxx.so)

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 


quote:
2) it is a static library on *nix, shared on windows (no idea about mac).

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 email me so I''d have your address, and I''ll let you know how I fare (I''m the moderator of the Everything Unix forum).

quote:
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?

*sigh* Mac... I agree with you there.

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).

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


#11 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 22 December 2001 - 04:12 AM

One thing I hate is language advocacy. Anyway....

I doubt any interpreted language will ever be faster than C or C++. Python runs on top of the C library. The only way would be to massively optimize 1) the virtual machine 2) the C library 3) the compiler and to only distribute statically linked binaries (and kiss goodbye to portability). The faster the computers get, the less noticeable the difference will be, until it probably doesn''t matter anymore.

To answer your question, if Python ever became faster than C++, I''d use Python for time critical code. I''d still use C++ for the rest because it exposes more functionalities.

I know I probably sound like an anti-Python guy, but the truth is that a lot of ''new'' languages promised wonders and provided nothing at all, so I tend to have a very critical view on these (but I give them a long try before judging). And again, I use Python just about everyday. Its pros easily overcome its cons.

A last thing: I''ve noticed after chatting with some people that they don''t want to use high level languages (as in ''interpreted'') because then they won''t look as ''leet''. Stupid, I know, but sadly a lot of people neglect these languages because of that.

my (long again) 0.02$


#12 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 22 December 2001 - 04:25 AM

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.

#13 Oluseyi   Staff Emeritus   -  Reputation: 1678

Like
Likes
Like

Posted 22 December 2001 - 04:37 AM

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!


#14 Andrew Nguyen   Members   -  Reputation: 150

Like
Likes
Like

Posted 22 December 2001 - 05:06 AM

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)

#15 Cyberdrek   Members   -  Reputation: 100

Like
Likes
Like

Posted 23 December 2001 - 02:02 AM

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




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS