PDA

View Full Version : Python....why?



ghaefb
5th September 2004, 03:55 PM
Ok it's like this.
Programming languages I know: C++, Java (learned in school/university)

I know how to write simple programs, and know how to use gtk/gtk2.
So I'm writing some apps in mixing C and C++ with gtk2 (which is not good)
I know I should use gtkmm with c++, but I had some problems with some libraries..

I saw this -> http://fedora.redhat.com/projects/config-tools/
So guys at fedora are using Python with PyGtk2 for GUI and all.

I'm learning some Perl now and I'm interested in Python.
My question is why Python ??

I see syntax is really simple, it looks too simple.
What's with all this Python Interpreter (Interactive Mode) >>> ?
Why is this usefull?

I know programs are written in text file and compiled.
It looks like Python/Perl programs are not compiled, you just run the source code.
Does this make it slower than C/C++ ? I think so.


So my main goal is to master good programming language(with gtk2 for GUI).
Is Python the answer?
Or should I stick to C++

Thanks

earobinson111
5th September 2004, 04:15 PM
I know programs are written in text file and compiled.
It looks like Python/Perl programs are not compiled, you just run the source code.
Does this make it slower than C/C++ ? I think so.
Thanks

See that is where you are wrong, in python nothing is compiled the text is read and the computer then interprets that, so your code is "compiled" on the fly, and unlike java for example you could add code to a python program as it is running and it would run it correctly. In python using oo programing you could infact prompt a user for a line of code and execute it, or have C++ generate some python code and have python run it. Yes you are correct this makes it a lot slower, for the same reason that java is slower than c (java is only semi compiled).

So why use python, or perl. It comes down to preference but pythons and perls common use is a glue for example if you have part of a a program in C and the other part in Java python would be great for takeing a C output parcing it and handing it to java. I also use python to write little scrypts (i wrote one for renaming files i get of my digital camra)

But realy you could do everything one one language, but then you could build anything with screws, we use nails cuz they fit right for some other tasks.

I would never write any big program in python but small little programs the slowness is not noticable but its all up to preference.

Hope this helps feal free to ask me more Q's

earobinson111
5th September 2004, 04:17 PM
Oh on a side note, in general programers can program faster in python since it is a simpler language and a company who pays programers by the hour would most defently use python since it would end up costing them less.

bryancole
5th September 2004, 06:25 PM
A quick correction. Python source-code files are compiled to python 'byte-code' when they are run (so creating a .pyc byte-code file). When a python program is executed a second time (provided the code hasn't been modified) the interpreter reuses the existing byte-code file. This makes subsequent start ups much faster.

We write complex data-acquisition software (with GUIs and groovy 3D visualisations...) in python. Yes, it's slower than C++, but this is rarely an issue. All low-level operations are performed by existing python extension libraries (e.g. large data array handling). Our 30,000 lines of python code does the work of >>100,000 lines of C++. Python is MUCH easier to read and maintain than C/C++ or perl (although I'll admit I'm no perl expert). Development time is typically about 30% of that required for C++ projects (much to the irritation of my C++ coding colleagues).

Python's main disadvantage is not it's speed, but ease-of-distribution. To run a python program, you need python installed. This isn't a problem on linux, but Win32 users must install python before running python-apps. Not a show-stopper, but still an inconvenience! If your app requires any additional python modules, these must also be installed before the app will run.

Alternatively, single-executable python 'compiled' programs can be created. These bundle the python interpreter, python byte-code and any extra dlls required into a single executable. They run just like a normal compiled program on Windows, but have a minimum size of about 4 MB (due to the interpreter) which makes them an inefficient way to distribute small apps or scripts. Again, the start-up time is slower than a C++ app, but they are usually very responsive in use.

One alternative to python we're considering is mono/C#. It seems to offer many of the advantages of python (v. high level OO-language, large component library etc.) but is type-safe/statically typed. Python is 'dynamically typed'. I'm not yet sure under what circumstances static-typing is better than dynamic typing (which I think is great, by the way). In python, since there's no compile-time error checking (beyond simple syntax), errors/bugs only show up at run-time. Thus, bugs could lurke in rarely used corners of your code undiscovered. On the plus side, when the interpreter comes across an error, it handles it gracefully, reporting it's nature and location in the code. Empirically, debugging python code turns out to be easy, even without compile-time type checking.

Oh year, writing python code is fun.

kosmosik
5th September 2004, 06:37 PM
I saw this -> http://fedora.redhat.com/projects/config-tools/
So guys at fedora are using Python with PyGtk2 for GUI and all.

I'm learning some Perl now and I'm interested in Python.
My question is why Python ??
probably because it is getting to be a language of choice for GNOME/GTK2 RAD - it is easy and does it work well...


I see syntax is really simple, it looks too simple.
What's with all this Python Interpreter (Interactive Mode) >>> ?
Why is this usefull?
Python is scripting language, that means commands are executed line by line - so that is for an interpreter is. sometimes also it is easier f.e. to call python from bash script to do some stuff with text and return to that bash script. that is what for interpreter is :)


I know programs are written in text file and compiled.
well not exactly. scripts are programs too...


It looks like Python/Perl programs are not compiled, you just run the source code.
Does this make it slower than C/C++ ? I think so.
Python/Perls programs are compiled - they are converted to bytecode upon exectuion (and cached for next time). it is not the fastest way to do things but with GUI app what you need speed for? I mean it still works normally. it is not like you use C - aplication works like flash, you use Python application will take 10 min. upon starting :) C is for low level stuff like kernels, libraries, servers and so on - for GUI Python is fine. in GUI it is not about execution speed - in GUI it is about to glue things together. like you just make a GUI to use a C library underneath - still operations will be fast as the hardcore stuff is being made by library (written in C). with modern languages it is more important to allow fast and easy creation of tools for developement (RAD).



So my main goal is to master good programming language(with gtk2 for GUI).
Is Python the answer?
Or should I stick to C++
maybe Mono? it is no answer to this. you can code GTK2 aplication with anything (C, Java, C++, C#, Perl, Python, PHP and probably few others) it is just your choice... ;)

if you like to learn something new Python is very nice :)

crackers
5th September 2004, 07:21 PM
As you can tell from the above responses, it all depends upon what you want to do. There is no single solution to every problem set. I use a combination of shell, Perl, and Java to do what I want to do or need to do with my systems and at work, although I'm starting to think about dropping Perl and going with Python for scripting purposes.

By the way, Python is not an OO language - it is "OO-like." The lack of strong typing is one of the issues there... ;)

CheeseWarfare
6th September 2004, 12:00 AM
Python is my first langauge (and only pretty much). It has a very simple syntax and it is infinatey expandable, from games to websevers, to webapplications, to 3D, just about anything. I read a short begginers tutorial on C and the code needed a lot more "babysitting" than python. For example, in C before you store a variable you have to tell it what kind of varible, python can figure that out by itself.

crackers
6th September 2004, 06:02 AM
For example, in C before you store a variable you have to tell it what kind of varible, python can figure that out by itself.
That's called "strong typing" and is actually a lot better than constantly over-loading a variable with whatever junk you want to put into it at the moment. Yes, you can do lots of pretty nifty things with Python (or Perl or whatever), but "professional grade" software requires you to be a lot more explicit and careful with what you're doing - and part of that is strong-typing.

ghaefb
6th September 2004, 09:22 AM
I agree crackers.
What I like about C is that it is very strict, and you have to use brackets..
I think it's a good thing. It takes more time to write programs that's true.

Mono.. no.
I like to use emacs and bash. No fancy GUI apps or any other devel environments.
So I guess I'll look in to Python, if I'll like it I'll learn more.
For now I'm staying on C/C++.

Thanks for all the answers, I see we have some good programers on this forum :)

earobinson111
6th September 2004, 03:56 PM
Bryancole you are correct about the python turning being compiled i was worng, yet i still beleave i rember that you can add a line of python code to python on the fly is this correct?

also who uses python this may give u a better idea if it is a usfull language to learn

"Have any significant projects been done in Python?

See http://www.pythonology.org/success for a list of projects that use Python. Consulting the proceedings for past Python conferences will reveal contributions from many different companies and organizations.

High-profile Python projects include the Mailman mailing list manager and the Zope application server. Several Linux distributions, most notably Red Hat, have written part or all of their installer and system administration software in Python. Companies that use Python internally include Google, Yahoo, and Industrial Light & Magic." http://www.python.org/doc/faq/general.html

Hope this helps I love python, and once u have learned 2 languages the rest are easy to lern its only a matter of syntax. I program in c++ (and c duh) java (most happy with java use it the most) python, perl, and vb (if u call that a language)

Jman
6th September 2004, 05:17 PM
My take on the config tools is that python is used because the graphic bindings are relatively simple and as an intepreted language doesn't have to be recompiled. The tools are basically pretty scripts to help with common administrative tasks.

widesteps
6th September 2004, 06:06 PM
By the way, Python is not an OO language - it is "OO-like." The lack of strong typing is one of the issues there... ;)
:confused:

Why is 'STRONG typing' a prerequsite for an OO language, typing, yes but that applies to all languages. From where I stand all OO languages are OO like: they all have there shortcomings. Java was designed without Multiple Inheritance - does that make it less of an OO language? (By the way technically Java is interpreted bytecode that needs an interpreter, the Java Runtine environment, no different from Python)

Surely the factors for using any language are:

Firstly can it do the job (most languages can because they are abstractions)
Economics - speed of development, ease of maintanence, ease of sharing expertise/ learning et al

Apart from research/weather/spying apps speed is becoming less of an issue as hardware gets faster and memory increases and clustering (parallelism/sharing) becomes the norm. I find it amusing when people harp on about speed as if its the defining factor. Cost is the overriding factor surely? and interpreted languages win hands down on that, don't they?

:)

widesteps
6th September 2004, 06:15 PM
but "professional grade" software requires you to be a lot more explicit and careful with what you're doing - and part of that is strong-typing.

Explain why you need 'strong-typing' to produce 'professional grade' software?

That comment appears very 'ivory tower' to me and insulting to all those professional software developers who write 'professional grade' python apps.

I've written 'professional grade' software in C, C++ and python and to be honest in a professional development environment I would much prefer to use Python.

crackers
6th September 2004, 06:47 PM
I used quotes because, to me, the lack of strong-typing encourages sloppiness - you can put different "types" of objects into the same variable and later on, you have no idea what "type" of object is in there. I'm sorry if you feel offended, but I deal with "stuff" on a daily basis that Python simply cannot handle efficiently enough.

I did not intend to imply that strong-typing is a pre-requisite for an OO language - that was a composition error on my part. (And "multiple inheritance" is not a pre-requisite, either.)

And, while Google may use Python internally, I'll bet you a dollar that the search engine is not. :D

earobinson111
6th September 2004, 07:05 PM
Strong typeing is very gray, my proff told me that what python does when you make a variable is that variable is a pointer to an object, and that when you use a diferent type on it, it actualy points to a different object. But that is a good argument for why python is no OO but even OO is not always black and white like many othe things in programing.

widesteps
6th September 2004, 07:21 PM
No offence taken and none intended just felt the generalistaion needed challenging.

Python does have various menas of identifying the type. type() is one, you can also use isinstance() and issubclass() etc to determine where you are so to speak. When programming in C/C++ you always need to know the type up front. Unless of course if you use void pointers or casting and surely you have used these techniques?

cheers

widesteps
6th September 2004, 07:30 PM
But that is a good argument for why python is no OO...

Can you explain why object pointer changes excludes a language from being OO?

My point is is that OO is defined by high level criteria like abstract data types (eg classes) information hiding, inheritance, polymorphism etc, not by the fact that an object pointer changes

crackers
6th September 2004, 09:47 PM
When programming in C/C++ you always need to know the type up front. Unless of course if you use void pointers or casting and surely you have used these techniques?
Actually, I've not had to use "void pointers" at all, since the majority of my OO development has been in Java. Casting, yes, especially with the Collections framework, but I prefer strong-typed arrays when throwing stuff around.

The fact that you have to declare variables "up front" to me implies clarity of thought, provides good anchors for documentation, and prevents over-loading of variables. Strong-typing helps prevent you from biting yourself in the ... rear-end. ;)

I'm also a very big proponent of up-front design, FYI. I prefer to know what I'm doing before I do it.

widesteps
6th September 2004, 11:56 PM
What is wrong with being able to do it both ways? What if you are passed an external object which you are unsure of its type. Static AND dynamic typing are both available in Python also Python was designed and built from the ground up to be OO.

Its like saying a vegetarian has a more varied diet than a meat-eater when a meat-eater can eat all that a vegetarian can plus have meat dishes.

As for up-front design, that as all professional developers would say is a good approach with the caveat that nothing is set in stone. An iterative design and development approach is surely the more efficient and productive as open source testifies. Flexibility in thought, design and development is to me intuitively the best approach. Iterativeness and flexibility are something OO scripting languages give to the developer.

I have never worked on a project where the initial design was faultless or where during development the light dawned on better ways of implementation.

crackers
7th September 2004, 12:42 AM
What is wrong with being able to do it both ways? What if you are passed an external object which you are unsure of its type.
Heh - I call that lousy design. ;) That's my point: you "shouldn't" (notice the quotes?) just be flinging "stuff" all over the place. In Java, that's what Interfaces are for. And that's what APIs are intended to document. And, yes, I religiously run Javadocs on the components that I have technical responsibility for - everyone calls me "Mr. Documentation" at work. Woe be he/she that omits his/her docs!


Its like saying a vegetarian has a more varied diet than a meat-eater when a meat-eater can eat all that a vegetarian can plus have meat dishes.
Huh? If you want a food analogy, try a "selection from the menu." I'd recommend a white with vegetarian dishes...


As for up-front design, that as all professional developers would say is a good approach with the caveat that nothing is set in stone.
A difference in approach. The more formalized processes I deal with require at least 85% "stone" - otherwise it gets kicked back. That is usually more than sufficient to create your domain and transfer objects, as well as solidify the API.

Er, in case you hadn't guessed, I'm dealing with component- and service- driven applications.


An iterative design and development approach is surely the more efficient and productive as open source testifies.
I'm not talking about FOSS development, particularly. And I wouldn't say that it's more "efficient." It suffices for that particular paradigm, but it does not work in all cases. Your requirements and development processes have to be structured the same way and, in my experience, when you've got lots of moving parts in a system, it doesn't work very well. At work, we had one requirements/development team using XP/Agile, while the rest used the formalized approach. That one team is now 12 months behind schedule and has cost the company quite a load of lost revenue.


Flexibility in thought, design and development is to me intuitively the best approach. Iterativeness and flexibility are something OO scripting languages give to the developer.
I won't disagree on the last point. However, the notion of using strong-typing and a formalized API means that someone else can use your "component" (or at least start coding to it) without the underlying implementation being wholly in place.


I have never worked on a project where the initial design was faultless or where during development the light dawned on better ways of implementation.
Neither have I - but never to the point of breaking the existing "contract" (API).

I think where our fundamental difference lies is that I think in terms of components and services, whereas you appear to see the "whole." I make building blocks, not fully hatched applications. It's up to someone else to stack and mortar my blocks into what you would consider an "application."

Now, when I write applications for myself, I do use an iterative approach. The wife is currently rolling her eyes as I'm engaged in re-writing my Java-based home-control client/server app for the fifth time. While the client/server part is always in flux, the service part I wrote and debugged four years ago for the serial communications hasn't changed one bit - it has a set-in-stone API that is more than sufficient for what it does.

Note: I hope y'all out there are enjoying this as much as widesteps and I apparently are!!! :D

Shadow Skill
17th September 2004, 12:42 AM
I didn't really understand most of that but am I correct in thinking that Python allows you to create variables that don't have a type until data is placed into them?

crackers
17th September 2004, 04:26 AM
Kinda sorta correct - when you use a variable, you can associate (put, if you will) any "kind" of data into it you want - as a default. This allows you to do things like (I think I'm getting the syntax right):


>>> myVariable = 1
1
>>> myVariable = "Now for something completely different"
Now for something completely different

This illustrates (probably incorrectly, but I don't "know" Python - yet) my problems with languages that don't enforce "strong typing" - you don't know exactly what "flavor" a variable is until you either check it explicitly (time-consuming, awkward, error-prone) or something breaks when it was expecting a 1 integer and got a string "Now..."

Yes, there are work-arounds and, as noted above, code- and time-wasting explicit checks - which you don't have to worry about when using strong-typing. An integer is always an integer - you can't "force" it into something it's really not (byte, char, and short are still integers - just smaller in size). (Part of it's also paranoia - I don't trust the moron down the hall to tell me he's giving me an integer when he's screwed up and actually given me a string to process.)

Shadow Skill
17th September 2004, 04:49 AM
The idea of that is almost blasphemous...I wouldn't ever do that, I would rather declare a string then explicitly populate the variable with whatever I wanted. I can't even imagine what would happen if you started passing variables that don't have an explicit tyoe definition. [I had a problem when I still kind of knew how to pass variables of mixing up data types as I went along....)

jcstille
17th September 2004, 12:38 PM
Also one interesting application is physics. There is a thing called VPython, which is python with a few libraries, and it is simple to have physics students program in it. It will calculate many electricity and magnetism fiels.

inha
17th September 2004, 01:38 PM
Also one interesting application is physics. There is a thing called VPython, which is python with a few libraries, and it is simple to have physics students program in it. It will calculate many electricity and magnetism fiels.


I googled on vpython for a bit. Most of it was about visualization of pretty basic electrostatics and -dynamics. Do you know if it has any useful features for calculating fields from potentials and wether it can be used to get analytical solutions?

crackers
18th September 2004, 05:04 AM
The idea of that is almost blasphemous...
I tentatively agree in certain situations that not using strong-typing is not only contraindicated, but approaching the level you indicate.

However, there are also some applications where strong-typing is actually a hindrance! I found one of the pleasant "side effects" of Perl was the ability to parse a string into it's components and then perform math calculations on a couple of the variables directly, no "conversion" necessary. The caveat with not using strong-types is that you have to be extremely careful with what you're doing - which, in my mind, will decrease programmer productivity in larger projects.

zylr
20th September 2004, 09:47 PM
Hmm, what was that program that packaged up a Python file into a Win32 Executable?
That could be REALLY useful :)

ghenry
27th September 2004, 05:30 PM
Does Python have a CPAN style resource? Also, Pythons GUI bindings seem more documented than some of the Perl ones I have found so far.

Daverz
27th September 2004, 08:20 PM
Does Python have a CPAN style resource? Also, Pythons GUI bindings seem more documented than some of the Perl ones I have found so far.
There's no CPAN for Python, but there is PyPI

http://www.python.org/pypi

and most Python packages use disttools so usually you just have to do

python setup.py install

to install something.

Daverz
27th September 2004, 08:22 PM
Hmm, what was that program that packaged up a Python file into a Win32 Executable?
That could be REALLY useful :)
Probably py2exe:

http://www.anti-particle.com/py2exe-0.5.shtml

circulus
29th September 2004, 11:05 PM
Hi,

some notes from me. Why Python ? Why not ! I learn (basicaly) Python about 2 hours of reading docs and trying
some examples and my test (experiments) with it. I found that Python is very usable, easy to learn and so ... relatively fast programming language. For gui apps, there are Gtk/Gnome, Qt or wxWindows bindings for Python.
And wxWindows bindings exist also for MS Win32 architecture and Python for Win32. I find Python very useful and
I write commercial app to collect data and store it into MySQL server in Python (running on FC2) and there are no problems (app is running as a "service" about 4 months continuously). And also excuse my poor english, I am czech citizen.

circulus

Mattio
11th July 2005, 05:51 PM
Python's main disadvantage is not it's speed, but ease-of-distribution. To run a python program, you need python installed. This isn't a problem on linux, but Win32 users must install python before running python-apps. Not a show-stopper, but still an inconvenience! If your app requires any additional python modules, these must also be installed before the app will run.

Not quite bryancole. An application called py2exe can convert your python scripts into executalbe files right? It also automatically takes all the modules needed and puts them in a zip file called library.zip, which is located in the same directory as the exe file. One more thing needed is the python24.dll file and there you go. Use py2exe to convert python scripts into *.exe files and you can run them on a computa without python installed!

website for py2exe: http://starship.python.net/crew/theller/py2exe/

also, the setup script is needed to run py2exe, so you can make one using this source code found here: http://www.python.org/doc/current/dist/setup-script.html (http://www.python.org/doc/current/dist/setup-script.html)

Shakes
11th July 2005, 11:03 PM
but "professional grade" software requires you to be a lot more explicit and careful with what you're doing - and part of that is strong-typing.

I don't agree with this comment at all. Sure "professional grade" software often uses things like C++, but sometimes it doesn't. The main reason C/C++ were made strongly typed is for performance reasons. The type checking is done at compile time, instead of run time.

You could argue it would take more of a professional to program in a weakly typed language, because this aspect can actually lead to harder errors. The language is less safe in it's type checking meaning certain errors that are hard to spot could occur.

Further more, the weak typing could be considered more elegant as no explicit type casting is needed by the programmer.

Professionals will not necassirly stick to one language, It's all about picking the right language for a given task. To state Python is not professional grade in this manner seems crazy. You will often hear many great programmers go on about how good and elegant Python is.

Daverz
12th July 2005, 04:08 AM
I used quotes because, to me, the lack of strong-typing

You're confusing static typing with strong typing. Python is strongly typed, but not statically typed.
Static typing only catches a small class of errors. Unit testing can catch a lot more than just relying on the compiler.

Bruce Eckel, the Thinking in Java guy, has written extensively on this:

http://mindview.net/WebLog

Daverz
12th July 2005, 04:53 AM
By the way, Python is not an OO language - it is "OO-like." The lack of strong typing is one of the issues there... ;)

Again, Python is strongly typed. Types are checked dynamically at runtime. Other examples of dynamically typed OOPLs are SmallTalk, CLOS, and Objective-C*.

BTW, I consider genericity very important for OOP, and while Java now has an implementation of generics, it's broken because you still lose type information (through "erasure").

* Objective-C can also take advantage of static type info at compile time if you include it.

crackers
12th July 2005, 05:14 AM
You guys have to go back almost a year to find something to carp about? Geez... :D

Firstly, while Bruce Eckel has some (overall) good points, he's been writing books and papers too long and hasn't been in the "thick of it" - let's just say he and I have disagreements. And I've been in the game longer than he has... ;)

Secondly, "static typing" (as defined above) means you don't have to write unit tests to make sure the variable you're passing in is even the correct class - or that you've correctly covered situations where it's not the correct type. It is or it isn't - and, yes, I will beat any developer soundly 'bout head and shoulders if they even think that passing Object as a parameter to a method is a good idea (99% of the time, it's not). This is especially true with differing teams writing differing portions of the system. You don't have to read people's minds and hope they've read yours.

Now, there are instances where a more "generic" object-type (aka parent class) is required in a method call - but you'll be operating on the assumption that you have an "is-a" relationship and only invoke methods on the parent-type. In fact, you won't even "know" it's a child class.

And Shakes - you're splitting hairs. Yes, a good pro can be effective in using languages like Python, but I would still argue that using explicit contracts (aka method/function signatures) greatly reduces initial errors. Especially when dealing with diverse development teams: there's reduced or non-existent ambiguity in using their APIs.

Of course, this can also be suborned by making the parameters (objects) super-malleable in the first place. Which means someone thinks they're being clever by not having to write four different methods that perform almost the same function - but in reality there was more work in that one method to account for the malleability than there would have been to just separate the durn things!

Daverz
12th July 2005, 05:53 AM
Ok it's like this.
My question is why Python ??


A couple things to keep in mind:

1) you don't need to replace your existing tools, Python works well with them.
2) you can learn Python quickly and easily (sounds like one of those IT trade-school commercials)



I see syntax is really simple, it looks too simple.


It looks simple because most of the verbiage in other languages is not neccessary in Python. This is why Python is sometimes called executable pseudo-code.



What's with all this Python Interpreter (Interactive Mode) >>> ?
Why is this usefull?


For testing out ideas quickly and easily without having to set up a project or environment, or going through a compile/debug/compile cycle. No makefiles, no ant scripts, no classpath, no config dialogs, and with a lot less verbiage to get wrong. You just type in your "question" and get your answer back as soon as you hit return.

I actually use ipython, which is like the command-line interpreter on steroids (yum ipython).



It looks like Python/Perl programs are not compiled, you just run the source code.
Does this make it slower than C/C++ ? I think so.


Someone else has covered the bytecode thing. As for the speed thing, Python code is much slower than Java or C, but a lot of the time you're just using Python to call C code (which is the case with pygtk and for a lot of built-in operations), so you retain most of the speed advantages for things like that. I invite you to compare the responsiveness of Java/Swing programs to similar pygtk programs.



So my main goal is to master good programming language(with gtk2 for GUI).
Is Python the answer?
Or should I stick to C++


C++ is viable for gtk development. It does reduce some of the tedium of gtk programing in C (all that casting goes away). But pygtk is an order of magnitude simpler still. Take a look at the pygtk tutorial:

http://pygtk.org/tutorial.html

There are some great reference docs there, too, and a huge, constantly updated FAQ with tons of practical info.

Daverz
12th July 2005, 07:30 AM
You guys have to go back almost a year to find something to carp about? Geez... :D


I'm starting with Java 5 as a given. Have they fixed the erasure thing? I don't think C# generics have this problem :rolleyes:



Secondly, "static typing" (as defined above) means you don't have to write unit tests to make sure the


But you still have to write unit tests, unless you're naively hoping that type errors are the only errors. People lose expensive rockets and space probes that way. Again, I think type errors are a relatively small class of errors. Most errors are value errors, and those can't be caught by the compiler.

With dynamic typing most type errors will be caught as soon as you test the program, anyway. You don't need unit tests specific to types, because type errors will be thrown as soon as you follow the code path they're on (because we have dynamic, but still strong, typing) , and it's exercising those code paths that's the important thing. You'll never get complete coverage in either language, of course, but if we wanted proof that our code was 100% sound we'd all be using Haskell.

Also, I wonder if there have been an empirical studies comparing the approaches. I don't think one can assume that because it seems intuitive that static typing should lead to sounder code that it neccessarily does in practice.



variable you're passing in is even the correct class - or that you've correctly covered situations where it's [snip]


It's possible to enforce interfaces in Python. The Zope guys have a standalone interface framework that's also used by the Twisted guys. You can enforce method signatures with decorators. Most of that stuff isn't worth the bother until you get Zope or Twisted sized.

crackers
17th July 2005, 05:39 AM
I'm starting with Java 5 as a given. Have they fixed the erasure thing? I don't think C# generics have this problem :rolleyes:
Yeah, that's a pretty big boo-boo. I think it actually got fixed in the first update (_02) - I'm still mostly stuck in 1.4-land, so I'm not paying that much attention to 5 yet.


But you still have to write unit tests, unless you're naively hoping that type errors are the only errors.
Puh-lease! I just don't want to have to write tests that test for passing the wrong type - extra work for me and I'm lazy.


People lose expensive rockets and space probes that way.
ROFLMAO! What's a few hundred fps between friends, eh?


Again, I think type errors are a relatively small class of errors.
My old Logic prof would call that ciruclar reasoning - type errors are relatively small because types are enforced at the interface level.


Most errors are value errors, and those can't be caught by the compiler.
And that's what Unit tests cover, right? :D


Also, I wonder if there have been an empirical studies comparing the approaches.
I don't think so. But then again, I did state "in my opinion" - of course, I could tack on "based on over 20 years in professional experience in software development." I just don't like using that hammer in a nice, clean philosophical debate.


It's possible to enforce interfaces in Python.
Of course, I found this out after the initial round several months ago. Right now, I'm trying to find some excuse to use Python to replace or supplement my current projects and, being too lazy to learn "yet another language," having a tough go of it.


Most of that stuff isn't worth the bother until you get Zope or Twisted sized.
Which is where the value of languages like Python or Perl. (Don't know jack about Ruby, the other "popular" language it seems.) They're a bit faster and, dare I say it, easier to bang out something really decent pretty fast, compared to C/C++/C#/Java, etc. - as long as it's relatively constrained in scope, such as for a small to medium sized projects (for some nebulous values of those terms). When you get into something measured in millions of lines of code, you find that those strong types helps to ensure system conformity and definitely brings a level of quality assurance that you wouldn't get without well-defined interfaces.

There was this IT admin who thought developers were over-paid weenies, so he built an "automated" J2EE application server setup and deployment management tool in shell scripts and Perl. I broke it in 3 seconds, simply by giving it a type it couldn't handle. He rebuilt it with Java and Ant and it's been in production use for over a year with only minor issues. (One of the error messages even invokes my (true) name: "You're attempting to do something stupid and have invoked the wrath of (name)!" :D)

Daverz
17th July 2005, 08:37 AM
Yeah, that's a pretty big boo-boo. I think it actually got fixed in the first update (_02) - I'm still mostly stuck in 1.4-land, so I'm not paying that much attention to 5 yet.


It's a pretty big backwards compatability issue, so they can't fix it in a minor release. To fix it they'd have to break backwards compatibility, so it may never get fixed.



Puh-lease! I just don't want to have to write tests that test for passing the wrong type - extra work for me and I'm lazy.


You don't have to write extra tests, since types are checked at runtime. Python is strongly typed, so type errors will throw an exception. Type errors are not silently passed over.

Daverz
17th July 2005, 11:53 AM
Of course, I found this out after the initial round several months ago. Right now, I'm trying to find some excuse to use Python to replace or supplement my current projects and, being too lazy to learn "yet another language," having a tough go of it.


I have the same issue with Java, C++, C#, etc (though I've had courses in Java, it just doesn't stick without being used). I have this nightmare that goes something like "We like the work you've done for us so far, but could you do it in .Net." (Maybe not such a nightmare: it would take at least twice as many hours and I'd use it as an excuse to double my rates as well.)