newbie questions (Python vs. Perl) 
Author Message
 newbie questions (Python vs. Perl)

[I'm sorry -- I'm sure this is a frequently addressed issue on this
site....]

I've been using Perl for several months and don't find its syntax
troublesome.  I like its speed considering I don't have to use C
constructs (and memory management).  I'm considering learning python for
several reasons; but have questions and concerns:

1) I hear it's the best for learning OO.  I have heard high praise of
Eifel as well, but information on it seems to be scarce at best.  (I
have C and Perl experience)  Will Python take me to the next level in
terms of understanding OO?

2) Use in the 'real world.'  Are companies really using Python?
Articles suggest that Python is preferable to Perl because it's better
for prototyping and more suitable for team projects (than Perl).  In
your opinion(s), has this been a major factor in choosing Python, or is
it more enjoyable to program in (than Perl)?

3) Speed.  How much slower is Python than comparable Perl?  I have read
about compiling Python as C or Java and ask myself how this code
compares to code written directly in those languages.

Your comments are appreciated.  My pet Antaresia childreni thanks you as
well.



Thu, 20 Sep 2001 04:00:00 GMT  
 newbie questions (Python vs. Perl)

Quote:

> 1) I hear it's the best for learning OO.  I have heard high praise of
> Eifel as well, but information on it seems to be scarce at best.  (I
> have C and Perl experience)  Will Python take me to the next level in
> terms of understanding OO?

I think this is likely. If for no other reason than that it makes
understanding easier to get to play with objects interactively (in the
interpreter).

Have fun.

Bob



Thu, 20 Sep 2001 04:00:00 GMT  
 newbie questions (Python vs. Perl)
I found a bug in using Tkinter to raise a canvas widget above later
packed (etc.) widgets.  It seems Tkinter gets confused between the
Misc.tkraise() method and the Canvas.tkraise(item) methods.
The following script shows the problem:

from Tkinter import *

def raiseCanvas():
    canvas1.lift()
    #canvas1.tkraise()
    #canvas1.widgetlift()

root = Tk()
canvas1 = Canvas(root, bg='blue')
canvas1.place(x=10, y=10, anchor=NW)
canvas2 = Canvas(root, bg='red')
canvas2.place(x=20, y=20, anchor=NW)
raiseButton = Button(root, text='raiseCanvas', command=raiseCanvas)
raiseButton.pack()
root.geometry("%dx%d" % (100,100))
root.mainloop()

which gives the following error:

Exception in Tkinter callback
Traceback (innermost last):
  File "C:\Program Files\Python\Lib\lib-tk\Tkinter.py", line 764, in
__call__
    return apply(self.func, args)
  File "C:\PROGRA~1\PYTHON\RAISEC~1.PY", line 4, in raiseCanvas
    canvas1.lift()
  File "C:\Program Files\Python\Lib\lib-tk\Tkinter.py", line 1287, in
tkraise
    self.tk.call((self._w, 'raise') + args)
TclError: wrong # args: should be ".8249616 raise tagOrId ?aboveThis?"

I made Tkinter do what I want by adding a method to the Misc
class and not the Canvas class:

class Misc...
    def tkraise(self, aboveThis=None):
        self.tk.call('raise', self._w, aboveThis)
    lift = widgetlift = tkraise

so that widgetlift will call the tkraise in Misc and not the tkraise in
Canvas.

I discovered the error in developing a multiple document interface for
Tkinter
which can be found on: http://www2.zyvex.com/OpenChem/index.htm
Dockable toolbars and a tree widget can also be found there.
They probably don't look very good on unix yet.

John



Fri, 21 Sep 2001 03:00:00 GMT  
 newbie questions (Python vs. Perl)

* Phil Voris
|
| 1) I hear it's the best for learning OO.

Maybe. Personally, however, I think that when learning OO it doesn't
matter all that much which language you do it in. All you want is
basically that the language stay out of your way and let you get on
with the learning.

As such, I think maybe Simula would be the best language to learn OO
in.

| I have heard high praise of Eifel as well, but information on it
| seems to be scarce at best.

Try this URL:

<URL: http://www.cm.cf.ac.uk/CLE/>

Here you'll find lots of informationa and links to other useful
pages. You can also find some useful tutorials.

However, I don't think Eiffel would be a good learning language. I
tried it and found it difficult to get started, and I also think you'd
do best to stay away from this design-by-contract until you understand
OO.

| (I have C and Perl experience) Will Python take me to the next level
| in terms of understanding OO?

You might go there with Python, but it won't do this automatically for
you.

| 2) Use in the 'real world.'  Are companies really using Python?

Sure. I work at a company which does, and we're very happy with it.
You'll find some references at the Python web site as well.

| Articles suggest that Python is preferable to Perl because it's
| better for prototyping and more suitable for team projects (than
| Perl).  In your opinion(s), has this been a major factor in choosing
| Python, or is it more enjoyable to program in (than Perl)?

We chose Python simply because it was a better language. Easier to
build large programs with good structure, more predictable syntax,
easier to learn, easier to catch bugs in etc etc

| 3) Speed.  How much slower is Python than comparable Perl?

Yes. More or less. Maybe. Not at all.

It depends to a very large degree on what you're doing and how you do
it. In general I don't think the speed difference is an issue.

| I have read about compiling Python as C or Java and ask myself how
| this code compares to code written directly in those languages.

The Python2C compiler I haven't tried, but JPython is slower than both
pure Java code and CPython. Again, the exact amounts will vary.

To take one example, I recently heard from a guy who'd written a
performance-critical function in Common Lisp that executed in 623 s
per call. He has a C version that takes 92 s per call, but after
heavy optimization he now has a pure Common Lisp version that executes
in 4.7 s per call.

His conclusion was that although the first attempt was likely to be
faster in C, Common Lisp made it far easier to try out different
strategies and algorithms, so that achieving 5 s performance required
less effort in CL than in C.

I think you'll have similar experiences with JPython and CPython.
Usually it's fast enough. When it's not you can usually tune it quite
a bit. If that doesn't help you usually at least have a very good
algorithm, that you can then translate into C/Java. Predicting the
performance ratio of this version against C/Java code I find almost
impossible, since performance is to some degree a function of expended
optimization effort. (It's also usually related to your choice of
language implementation.)

To take another example, I've written a validating XML parser in
Python, which I've spent quite a bit of time optimizing since version
0.50 (which was unoptimized). Version 0.50 chewed through my benchmark
suite in 49 seconds when not validating and 599 seconds when
validating (one document has a 2K document and a fiendishly complex
79K DTD).

The version currently in my CVS tree does the benchmark suite in 21
and 48 seconds respectively, and I still haven't tried rewriting any
of it in C.

So a fixed comparison ratio between languages is at best useless and
probably misleading.

--Lars M.



Fri, 21 Sep 2001 03:00:00 GMT  
 newbie questions (Python vs. Perl)
The following got posted in a reply tree by mistake:

I found a bug in using Tkinter to raise a canvas widget above later
packed (etc.) widgets.  It seems Tkinter gets confused between the
Misc.tkraise() method and the Canvas.tkraise(item) methods.
The following script shows the problem:

from Tkinter import *

def raiseCanvas():
    canvas1.lift()
    #canvas1.tkraise()
    #canvas1.widgetlift()

root = Tk()
canvas1 = Canvas(root, bg='blue')
canvas1.place(x=10, y=10, anchor=NW)
canvas2 = Canvas(root, bg='red')
canvas2.place(x=20, y=20, anchor=NW)
raiseButton = Button(root, text='raiseCanvas', command=raiseCanvas)
raiseButton.pack()
root.geometry("%dx%d" % (100,100))
root.mainloop()

which gives the following error:

Exception in Tkinter callback
Traceback (innermost last):
  File "C:\Program Files\Python\Lib\lib-tk\Tkinter.py", line 764, in
__call__
    return apply(self.func, args)
  File "C:\PROGRA~1\PYTHON\RAISEC~1.PY", line 4, in raiseCanvas
    canvas1.lift()
  File "C:\Program Files\Python\Lib\lib-tk\Tkinter.py", line 1287, in
tkraise
    self.tk.call((self._w, 'raise') + args)
TclError: wrong # args: should be ".8249616 raise tagOrId ?aboveThis?"

I made Tkinter do what I want by adding a method to the Misc
class and not the Canvas class:

class Misc...
    def tkraise(self, aboveThis=None):
        self.tk.call('raise', self._w, aboveThis)
    lift = widgetlift = tkraise

so that widgetlift will call the tkraise in Misc and not the tkraise in
Canvas.

I discovered the error in developing a multiple document interface for
Tkinter
which can be found on: http://www2.zyvex.com/OpenChem/index.htm
Dockable toolbars and a tree widget can also be found there.
They probably don't look very good on unix yet.

John



Fri, 21 Sep 2001 03:00:00 GMT  
 newbie questions (Python vs. Perl)
: The following got posted in a reply tree by mistake:

: I found a bug in using Tkinter to raise a canvas widget above later
: packed (etc.) widgets.  It seems Tkinter gets confused between the
: Misc.tkraise() method and the Canvas.tkraise(item) methods.
: The following script shows the problem:

: from Tkinter import *

: def raiseCanvas():
:     canvas1.lift()
:     #canvas1.tkraise()
:     #canvas1.widgetlift()

: root = Tk()
: canvas1 = Canvas(root, bg='blue')
: canvas1.place(x=10, y=10, anchor=NW)
: canvas2 = Canvas(root, bg='red')
: canvas2.place(x=20, y=20, anchor=NW)
: raiseButton = Button(root, text='raiseCanvas', command=raiseCanvas)
: raiseButton.pack()
: root.geometry("%dx%d" % (100,100))
: root.mainloop()

: which gives the following error:

: Exception in Tkinter callback
: Traceback (innermost last):
:   File "C:\Program Files\Python\Lib\lib-tk\Tkinter.py", line 764, in
: __call__
:     return apply(self.func, args)
:   File "C:\PROGRA~1\PYTHON\RAISEC~1.PY", line 4, in raiseCanvas
:     canvas1.lift()
:   File "C:\Program Files\Python\Lib\lib-tk\Tkinter.py", line 1287, in
: tkraise
:     self.tk.call((self._w, 'raise') + args)
: TclError: wrong # args: should be ".8249616 raise tagOrId ?aboveThis?"

: I made Tkinter do what I want by adding a method to the Misc
: class and not the Canvas class:

: class Misc...
:     def tkraise(self, aboveThis=None):
:         self.tk.call('raise', self._w, aboveThis)
:     lift = widgetlift = tkraise

: so that widgetlift will call the tkraise in Misc and not the tkraise in
: Canvas.

: I discovered the error in developing a multiple document interface for
: Tkinter
: which can be found on: http://www2.zyvex.com/OpenChem/index.htm
: Dockable toolbars and a tree widget can also be found there.
: They probably don't look very good on unix yet.

It is not a bug with either code, it is a naming problem.  The
Canvas.tkraise is calling the correct code, but it should be called
tag_raise, not tkraise (see the Text widget for naming choice).

Fredrik or Guido, is this something you can change for before 1.5.2 is
released?  (I don't see anything on www.python.org/1.5/ that says when
1.5.2 will be done except "mid March", which has gone by.)

Until then, I would suggest the following fix:

  from Tkinter import Canvas
  Canvas.tag_raise = Canvas.tkraise
  del Canvas.tkraise, Canvas.lift

This should correct the problem.

  -Arcege



Sat, 22 Sep 2001 03:00:00 GMT  
 newbie questions (Python vs. Perl)
|
| I found a bug in using Tkinter to raise a canvas widget above later
| packed (etc.) widgets.  It seems Tkinter gets confused between the
| Misc.tkraise() method and the Canvas.tkraise(item) methods.
| The following script shows the problem:
|
| from Tkinter import *
|
| def raiseCanvas():
|     canvas1.lift()
|     #canvas1.tkraise()
|     #canvas1.widgetlift()
|
| root = Tk()
| canvas1 = Canvas(root, bg='blue')
| canvas1.place(x=10, y=10, anchor=NW)
| canvas2 = Canvas(root, bg='red')
| canvas2.place(x=20, y=20, anchor=NW)
| raiseButton = Button(root, text='raiseCanvas', command=raiseCanvas)
| raiseButton.pack()
| root.geometry("%dx%d" % (100,100))
| root.mainloop()

You can call Misc.lift (overriden by Canvas.lift) as follows:

    def raiseCanvas():
        Misc.lift(canvas1)

In general, you can call a base class method overriden by a subclass
method by BaseClassName.methodname(SubClassInstance, arguments).

You'll find that the same technique is used in the __init__ methods of
the Tkinter widget classes.

--



Sat, 22 Sep 2001 03:00:00 GMT  
 newbie questions (Python vs. Perl)

Quote:
> It is not a bug with either code, it is a naming problem.  The
> Canvas.tkraise is calling the correct code, but it should be called
> tag_raise, not tkraise (see the Text widget for naming choice).

> Fredrik or Guido, is this something you can change for before 1.5.2 is
> released?  (I don't see anything on www.python.org/1.5/ that says when
> 1.5.2 will be done except "mid March", which has gone by.)

You are right that there is a naming conflict.  Unfortunately the
default rules for naming Tk subcommands yield this conflict and I
didn't catch it when I (or whoever it was) originally created the
Canvas class.  The Canvas.bind() method shows a precedent for naming
it tag_raise() as you propose.

Unfortunately, I cannot make this change without breaking all existing
code that was using Canvas.tkraise() for raising Canvas items (instead
of raising the Canvas itself).  I can add tag_raise() and then in 1.6
we can delete the tkraise() and lift() names.

Other issues:

- As someone else suggested, the proper solution is
Misc.tkraise(canvasobject).

- /Fredrik Lundh is responsible for *documenting* Tkinter, but not for
its maintenance (although he contributed a bunch of support modules).
The maintenance of Tkinter is strictly my responsibility.  (Not that I
asked for it. :-)

- 1.5.2 will more likely be released around mid-April.

--Guido van Rossum (home page: http://www.python.org/~guido/)



Sat, 22 Sep 2001 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Newbie question: tcl vs perl and tkMotif vs tkX

2. Python Binding [Was: Re: PYTHON VS. PERL VS. TCL ]

3. Yet another Python vs. Perl speed issue/question

4. NEWBIE question:Python or perl?

5. Forth vs Python vs Perl

6. perl vs python vs icon

7. PYTHON VS. PERL VS. TCL

8. jredford's flames and criticism (was: PYTHON VS. PERL VS. TCL )

9. THANKS: RE: PYTHON VS PERL VS TCL

10. newbie question: python vs. Matlab

11. Python and Perl (was: converting perl to python)

 

 
Powered by phpBB® Forum Software