python is going to die! =(

[Matt Gerrans]

I skimmed a little part of this thread earlier and now it is all gone from
my news reader (thankfully!), so forgive me if this comment was already made
by someone else:

The idea that Python and C# are mutually exclusive is inane.

In fact, the idea that Python and Ruby, or Perl or any other language are
mutually exclusive is inane. The more tools you have at your disposal,
the better off you are.

I've been developing in extensively C# for about a year and a half now and
started using Python about twice as long ago or so. I still use Python
extensively and find that it complements my work in other languages,
including C#. I find that it is often useful to imagine how I would
approach a problem in Python, before implementing it in C#, for example.
I find it easier to "think in Python" and find that it helps me create
better solutions in C, C++, C#, and Java.

All these language x vs. language y arguments are silly. I'm more
interested in using Python *with* other languages.

 

[Chris Green]

Speaking of which, is there any way to get tab-completion
(intellisense?) behaviour in emacs? Or in the interactive
interpreter?

M-/ is good for saving keystrokes.

http://cedet.sourceforge.net/semantic.shtml is a project working on
the backend parsing to be able to be at the point where that context
sensitive dynamic completions can happen ( well, as well as they could
in python ).

I love emacs though I keep thinking one day that eclipse will take
over and would love for there to be an emacslike engine on top of
eclipse to access use customizations/keybindings etc.

The trick that I like most about emacs+python right now is inserting
import pdb; pdb.set_trace() and then running the python script from a
*shell* buffer. It just happens to load the exact same code that would
occur from running pdb.py directly so code lines can be synced up.

 

[Fred]

I do notice though that when I try to convince a co-worker to try Python,
the thing that seems to be the biggest turn off is the lack of an IDE with a
GUI designer included standard

I agree. Once you're used to the productivity of Delphi or VB, it's a
big turn-off to have to go back to building GUI's by hand, and
shipping the 3MB DLL for wxWidgets is an extra reason why newbies
might give up on another excellent tool. Too bad Guido et al. didn't
take the GUI part into consideration earlier.

But then, maybe someone will come up with a good IDE + GUI designer as
part of the .Net shebbang.

Fred.

 

[Cameron Laird]

I agree. Once you're used to the productivity of Delphi or VB, it's a
big turn-off to have to go back to building GUI's by hand, and
shipping the 3MB DLL for wxWidgets is an extra reason why newbies
might give up on another excellent tool. Too bad Guido et al. didn't
take the GUI part into consideration earlier.

.
.
.
In the Tk community, there's a fair density of developers
with backgrounds in Delphi or VB, yet who claim to *prefer*
to do "GUIs by hand". The "turn-off" isn't universal, if my
observations are accurate.

Also, I confess to taking offense at your mention of Guido et
al. Please don't think they ignored GUI considerations or
possibilities. Even with hindsight, *I* sure don't know how
they could have done better by themselves and Python. I suspect
I'm overreacting, and that you intended no disrespect in what
you wrote. It certainly rubbed me wrong, though.

 

[Tim Roberts]

I don't really get the connection between the two. C# is a very different
type of language, with a different market.

I have to say that I disagree. Both are interpreted to an intermediate
language. Both have a substantial built-in library. Both are strongly
oriented towards network applications. They are different, sure, but they
are not "very different", in the same way that Python and C++ are "very
different".

And I still don't understand the "why" of mono.

Really? It seems quite clear to me. With Microsoft's considerable weight
behind it, for better or for worse, there are going to be a lot of .NET
managed applications built in the near future. Thanks to Mono, all of
those application BINARIES will run on Linux. Mono provides better support
immediately than what WINE provides after more than a decade.

I don't agree with the original poster, and we'll have to wait to see how
it all plays out, but the fact is that C# and the Common Language Runtime
really are a fundamentally good idea.

 

[Daniel Dittmar]

The one thing that I would like to see, however, (....admittedly a
dangerous statement considering that it could very well wind up getting me
*volunteered* to fix it... ;-) is a "GUI development in Python" page

That would be
http://www.python.org/cgi-bin/moinmoin/GuiProgramming.
There's not much there in term of comparisons, but as you volunteered...

Daniel

 

[Wilk]

I agree. Once you're used to the productivity of Delphi or VB, it's a
big turn-off to have to go back to building GUI's by hand, and

What do you mean "by hand" ? When you must use a mouse to make a gui,
you use your hand, but when you code a gui you use your head... Finaly
if you code the gui, you can reuse it and so don't need more any hand or
head for this.

shipping the 3MB DLL for wxWidgets is an extra reason why newbies
might give up on another excellent tool. Too bad Guido et al. didn't
take the GUI part into consideration earlier.

Guido took the GUI part in consideration when he decide that it's better
to let python as a langage and let people decide which library they
want, wich ide they prefer...
The mistake of java was to decide that they will do everything even the
gui (swing), since, everybody say that java is slow even if the langage
is very fast...

Don't forget that there is a lot of developers who don't need any gui,
or need a very specific gui. But every developers need python the
langage and the standard lib...

I encourage people to look at web application ;-)

But then, maybe someone will come up with a good IDE + GUI designer as
part of the .Net shebbang.

There are, it's just to choose...

 

[Max M]

If you must troll, at least troll with some skill, "julio". Better
still, as many have already suggested, just go away, thanks.

Well, not to feed the troll, but there is a few relevant points in it's
posting.

When writing big systems, it is nice to be able to have an enviroment to
code in. Eg. an IDE.

I am mostly a Zope coder, and while it's a very powerfull system that
now makes it possible to do a huge amouont of work in a short time, it
has the famous Z-shaped learning curve.

It is really really hard to learn. This is caused by the system design
(Which should be solved with Zope3). But I cannot help to think that a
self-educating system would be of a big help. A system where
introspection was well supported.

They do it in Z3 by making the programmer make more work, but it could
probably have been nice if the language was able to do more of the work
in that regards.

I have a feeling that the typelessness of Python can make this harder.
Wrappers on top of wrappers on top of som kind unknown data type can be
really hard to trace.

Eg. if I call a method called getAuthenticatedMember() what does it return?

In plain Zope it returns a user object, but if you have added the CMF to
the system, it returns a user object that is wrapped with extra
functionality.

Also the membership tool is wrapped itself several times. In Zope it is
acl_users, in CMF it's the membership tool and in in Plone it's wrapped
once more, but still called the membership tool.

Each layer adds functionality. This makes it really hard to find out
what inteface you actually have available at what level.

An IDE that could make dynamic introspection on a system like that,
would be of a big help. I think that static typed systems might be
easier to write an introspective IDE for. This is an issue when the
system get's a lot bigger than the language.


--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

 

[Alex Martelli]

Well, not to feed the troll, but there is a few relevant points in it's
posting.

(Please, please, please: "its", not "it's"... pretty please...)

When writing big systems, it is nice to be able to have an enviroment to
code in. Eg. an IDE.

Many people agree with you, enough to provide a commercial audience for
WingIDE, BlackAdder, Kommodo, ActiveState's addin to Microsoft Visual
Studio that lets you use VS as an IDE for Python, ...; and open-source
constituencies for plugins letting you use Eclipse, as well as self
contained IDEs. Nobody forces you to use one, but if you like them,
they're there.

self-educating system would be of a big help. A system where
introspection was well supported.

I've never used any language with better introspection facilities than
Python, not even Lisp.

They do it in Z3 by making the programmer make more work, but it could
probably have been nice if the language was able to do more of the work
in that regards.

The day the _language_ starts being designed to help IDEs to the
detriment of programmers who prefer not to use them, is the day I switch
to Ruby, Smalltalk, Common Lisp, Dylan, or ANY other language who keeps
being designed for human beings, not for tools.

An IDE that could make dynamic introspection on a system like that,
would be of a big help. I think that static typed systems might be
easier to write an introspective IDE for. This is an issue when the
system get's a lot bigger than the language.

I see your point (and a solid type system, like Haskell's, would surely
be more helpful in this regard than wobbly ones like Java's or C#'s).
But I consider the advantages of runtime typing to vastly surpass the
advantages of the simplification that compiletime typing can give to
compilers and other static analysis tools (IDEs included).

If you disagree, and crave compiletime typing, there is a huge array of
compiletime typed languages for you to choose among, including ones such
as bobo, designed to use compiletime typing but otherwise offer some
other Python advantages. The only sensible course of action for a
compiletime typing fan would seem to be to try out any or all of those
other 1000 languages, rather than fighting to foist such typing onto
those of us who consider runtime typing superior, and indeed one of
Python's greatest strengths.


Alex

 

[Ville Vainio]

Chris> http://cedet.sourceforge.net/semantic.shtml is a project
Chris> working on the backend parsing to be able to be at the
Chris> point where that context sensitive dynamic completions can
Chris> happen ( well, as well as they could in python ).

Are they really considering doing this properly for Python? I haven't
even got it running properly with C++, but that might be because I've
tried to do it in xemacs. Python should be viable for context
sensitive dynamic completion via type inference, it's just that it's a
lot of work, work that probably has zero chance of getting done within
the cedet project that is resource starved anyway.

That's the whole problem with emacs - lack of resources. Nobody
bothers do anything "seriously". And when people within the emacs
community do things they pick bizarre ways of doing things, possibly
because they are often Lisp lovers that like to "think different". And
stubborn ones at that.

Chris> I love emacs though I keep thinking one day that eclipse
Chris> will take over and would love for there to be an emacslike
Chris> engine on top of eclipse to access use
Chris> customizations/keybindings etc.

Eclipse will no doubt take over. I'm a long time emacs user and a fan,
but both the emacs projects seem to have stagnated, and part of the
problem is that there are two of them. Emacs might need a fresh start,
but it's hardly likely; most probably a new project would be seen as
further dillution of already scarce emacs resources.

Luckily we emacs fans still have hope in eclipse - what needs to be
implemented is a Jython API that allows customization of eclipse in
the way elisp works for emacs. Eclipse has broad industry support and
a fair share of enthusiasm working for it, while emacs just doesn't
seem to be what kids like to hack anymore.

 

[RPM1]

And you haven't tried kdevelop with qtdesigner?
Or some similar combination of GTK-based IDEs/tools?

Is it available on Windows? Does one need to download 2 or
3 different packages with different licensing?

If that's the case then it would be a hard sell in a
Windows environment.

Keeping in mind that it doesn't matter to *me* because I
code my GUI's in Tkinter. It's when I try to convince
co-workers that Python is worth looking into that I come
across these objections.

The product that came closest to what I'm envisioning was
PythonWorks. It used the included Tkinter libraries and
it was relatively expensive, (which for some strange reason
makes it more trustworthy to Windows people). It was
basically an all-in-one package. Unfortunately it's no longer
available, (probably because Pythonistas are more likely
to piece together what they want for free rather than pay
hundreds of dollars to get one package).

Oh well, hopefully IronPython will be a success.
Patrick

 

[Roy Smith]

Of course emacs is going to die someday. But considering that it's been
around for something like 25 years, and still going strong, I'm not too
worried that it's going to be anytime soon.

 

[Jeremy Bowers]

Python GUI's are one of those annoying circumstances in which there simply
isn't a good solution (or, at least, no good solution readily apparent to
one with my level intellect). For every GUI toolkit you pick there's going
to be several impressive pros and several apaling cons.

Note that all the Python wrappers I've tried (which is all the major ones
except FOX (if you count that as major) and I suppose direct use of Win32
(if you count that as a python wrapper)) are fairly thin wrappers around
the toolkits, possibly with some added library code (wxPython), so they
are at the very least easier to use than the toolkit directly, and in some
cases have significant advantages.

In other words, pinning this issue on Python is misguided; it is a
fundamental issue with GUI toolkits *in general*, and there is little
(more) Python can do to fix that.

The reality is that while we've mostly mastered GUIs that are simple
forms, we still haven't found "one ideal solution" for anything much
beyond that. (Assuming there is one, of course, though there is probably
at least a 95% solution waiting for us to converge on it.) You've got
"widgets" and "events" and "data" and "code" and everybody has different
ideas on how to tie those things together, with fundamental advantages and
disadvantages to each approach, even assuming perfect implementations.

For what it is worth, you have this problem in Windows, too, you just
don't percieve it because Windows has a One True Widget set... at least
for a given development environment... and assuming you don't want to
install GTK or QT... well, it's close enough to true that it is
practically true. But that's only an advantage if the widget set works for
you, and so far, it never really has. I've never been able to go more than
an hour without having to work around a Windows bug of some kind due to
the way I use widgets. But I digress....

 

[Andrew Dalke]

M-/ is good for saving keystrokes.

Well I'll be.. Never knew about that one.

The trick that I like most about emacs+python right now is inserting
import pdb; pdb.set_trace() and then running the python script from a
*shell* buffer. It just happens to load the exact same code that would
occur from running pdb.py directly so code lines can be synced up.

I played around with it a bit but couldn't figure out how
to make it do what I've needed, which is to print the lines
of code as they are running. Unlike doing a step by step
in the debugger, this gives me an record of the entire
program flow. I used it once to debug code running at one
of my client's site.
Calling: ?
..
Calling: do_this
spam.py:2: a = 5
spam.py:3: b = 10
spam.py:4: c = a*b
spam.py:5: return c
return
50
return
Here's showtrace.py

import sys, linecache

def getlineinfo(frame):
filename = frame.f_globals.get("__file__")
if filename is None:
# Don't know a file?
return "."
if filename[-4:] in (".pyc", ".pyo"):
filename = filename[:-1]
lineno = frame.f_lineno
if filename.endswith(".py"):
line = linecache.getline(filename, lineno)
if not line:
line = "???"
return "%s:%s: %s" % (filename, lineno, line.rstrip())
line = "???!!!"
return "%s:%s: %s" % (filename, lineno, line.rstrip())

def getfuncinfo(frame):
return "Calling: " + frame.f_code.co_name

def linetrace(frame, event, arg):
if event == 'line':
sys.stderr.write(" " * indent + getlineinfo(frame) + "\n")
elif event == 'call':
sys.stderr.write(" " * indent + getfuncinfo(frame) + "\n")
return linetrace
elif event == 'return':
sys.stderr.write(" " * indent + "return\n")

Andrew
(e-mail address removed)

 

[Jarek Zgoda]

I agree. Once you're used to the productivity of Delphi or VB, it's a
big turn-off to have to go back to building GUI's by hand, and
shipping the 3MB DLL for wxWidgets is an extra reason why newbies
might give up on another excellent tool. Too bad Guido et al. didn't
take the GUI part into consideration earlier.

I love Delphi, 5 days a week, 9:00-17:30, but I don't want Python to be
bound to one platform, as Delphi is (no, Kylix is not an answer, it's a
disaster). I'm really happy (and productive) using wx on Windows and
PyQt on linux, with wxGlade and Qt Designer as GUI designers. There's
only one thing from Delphi I'd like to see in other IDE's -- its
integrated debugging is great. Eclipse (w. Java) has very similar model
of debugger integration.

But then, maybe someone will come up with a good IDE + GUI designer as
part of the .Net shebbang.

Go, try Delphi 8.

 

[Jorge Godoy]

I love Delphi, 5 days a week, 9:00-17:30, but I don't want Python to be
bound to one platform, as Delphi is (no, Kylix is not an answer, it's a
disaster). I'm really happy (and productive) using wx on Windows and
PyQt on linux, with wxGlade and Qt Designer as GUI designers. There's
only one thing from Delphi I'd like to see in other IDE's -- its
integrated debugging is great. Eclipse (w. Java) has very similar model
of debugger integration.

A friend of mine -- actually a business partner -- that comes from a
world like yours is loving to work with Python since I convinced him
about it. One thing that he always complain about is the absence of
components like TDatabase, TQuery, TDBEdit, TDBGrid, etc. (He's being a
DBA for the last 20+ years --- where the '+' probably means more 5 or 6
years ;-D)

What are you using to replace those in your wxPython apps? I really
don't know them and I am not being able to help him with that.

I've seen, though, the wxODBC family but he always tells me that there
are several penalties in performance for not using the native drivers in
critical applications... What is your opinion about it?


Be seeing you,

 

[G. S. Hayes]

When writing big systems, it is nice to be able to have an enviroment to

code in. Eg. an IDE.

Wow, I actually find this backwards; IDEs often look good for small
projects, but don't scale up (especially to large, multiplatform
projects) very well in my experience.



Which goes to show that it's really a matter of personal taste.

I have a feeling that the typelessness of Python can make this harder.

Wrappers on top of wrappers on top of som kind unknown data type can be

really hard to trace.

Dynamic typing is probably the biggest defining characteristic of
Python; personally, it's one of the very first language features I
consider when I'm figuring out what language to use for a job.



I agree that intellisense-style tools are easier to write for
statically typed languages, but that's a very small advantage when
weighed against the advantages of dynamic typic (or against other,
more interesting advantages of static typing), IMO.

This is an issue when the system get's a lot bigger than the language.

I'm not sure what you mean by this, I can't really imagine a system
"bigger than Python" in the sense of "so big that Python was a bad
choice for implementation" or "so big that Python started to get in
the way/didn't support development/etc".



Right now we have a team of developers working on a system that
includes 250,000 lines of Python code; admittedly, some of that (maybe
30,000 lines) is machine generated, but the majority is not.



The language hasn't been a problem for us--indeed, I think it's helped
tremendously in terms of keeping the team small and yet still allow
for rapid development--and I don't see any reason that it would be a
problem on a project 10 or 100 times that size.

 

[Carlos Ribeiro]

[about data aware components for Delphi]
What are you using to replace those in your wxPython apps? I really
don't know them and I am not being able to help him with that.

TTable and TQuery equivalents are really not needed for Python "per
se". DBAPI 2.0 (even incomplete) and libraries such as sqlobject blow
TDataset and related classes away for almost anything that I can
imagine -- unless, of course, it's something that has to work wit data
aware editing components. These are still to be matched. I've been
studying Dabo (it was announced in this list, you can check it at
http://dabodev.com), and they are working on a framework that in some
ways resembles something that can be done with Delphi, but their
approach is different. Report generation is also problematic -- the
last time I've checked a couple of years ago, ReportLab couldn't be
considered to be on par with Delphi's report libraries, but I don't
about the situation now.

I've seen, though, the wxODBC family but he always tells me that there
are several penalties in performance for not using the native drivers in
critical applications... What is your opinion about it?

Passing over layers and layers of abstraction before getting to the
database is always going to impose a performance hit. ODBC is also
known to be very bad in this respect, at least in the Windows world,
and as far as I know, nobody likes to use it unless absolutely needed
for compatibility reasons.

I never made any benchmark, but I *suspect* that Python DB code can be
surprisingly efficient when compared to Delphi code. Delphi DB library
is very well implemented, but Python may have an edge when it comes to
manipulation of large in memory structures; not that Delphi can't do
it, but because Python libraries are already highly optimized. If one
writes "pythonic" code -- taking advantage of stuff that Python does
well, such as list and mapping manipulation, then the performance gain
can be significant. On the other hand, if someone tries to write code
in Python that reads and works just like Delphi's code, then the
performance will suffer.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Michele Simionato]

I've never used any language with better introspection facilities than
Python, not even Lisp.

Well Alex, you are talking about Python and you are right. But Max M. is talking
about Zope, and he also is right. There is a serious problem in introspecting
Zope. Everything is a wrapper around something and usual Python introspection
facilities give you no useful information. Zope (I am talking about Zope 2) is
the most unpythonic framework I have ever seen :-(


Michele Simionato

 

[Max M]

I'm not sure what you mean by this, I can't really imagine a system
"bigger than Python" in the sense of "so big that Python was a bad
choice for implementation" or "so big that Python started to get in
the way/didn't support development/etc".

You have a learning curve for the language, and a learning curve for the
system.

What I meant was that the learning curve for the system is much bigger
than the langugage. So learning the system becomes a much bigger task
than using any specific language.

In that case, tool support could be more important than language, as the
right tool could help you understand the system better.

I am not saying it is like that. Just that I could imagine a tool that
could make you understand big systems better, and that less dynamic
languages would be easier to write those kind of tools for.

I often find that debugging is pretty trivial. But what I really hate is
when I trace the bug into a subsystem that I have not written. Then I
can spend several days solving it, as I have to learn and understand
that subsystem. In that case the system is larger than the language.

--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science