Python, Can it work?

Andrew Nguyen · 2001-12-23T08:02:41

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

Engines and Middleware Programming

Started by Andrew Nguyen December 21, 2001 07:17 PM

13 comments, last by Andrew Nguyen 22 years, 4 months ago

Anonymous

December 22, 2001 10: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$

Anonymous

December 22, 2001 10: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.

Oluseyi

2,123

December 22, 2001 10: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!

Andrew Nguyen

150

Author

December 22, 2001 11: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)

---START GEEK CODE BLOCK---GCS/M/S dpu s:+ a---- C++ UL(+) P(++) L+(+) E--- W++ N+ o K w(--) !O !M !V PS- PE+Y+ PGP+ t 5 X-- R tv+ b+ DI+ D G e* h! r-- !x ---END GEEK CODE BLOCK---

Cyberdrek

100

December 23, 2001 08: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

[Cyberdrek | ]

Python, Can it work?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Python, Can it work?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines