The best platform and editor for Python
kimiraikkonen
For experienced with Pyhton users, which developing software and
enviroment would you suggest for Pyhton programming? Compiler+Editor
+Debugger.
Also what are your suggestions for beginners of Pyhton programming?
Thank you.
Sönmez Kartal
Emacs is the best for anything for me. Some people prefers Eclipse
with PyDev extension.
Build some real world applications with Python. Pick what do you need
from SourceForge or similar one then write it. If it is something you
need then you probably will make it more special then you found and
this will take you to the more coding and more...
By the way, thanks for winning Magny Cours grand prix Kimi... :-P
kimiraikkonen
> Hello,
>
> Emacs is the best for anything for me. Some people prefers Eclipse
> with PyDev extension.
>
> Build some real world applications with Python. Pick what do you need
> from SourceForge or similar one then write it. If it is something you
> need then you probably will make it more special then you found and
> this will take you to the more coding and more...
>
> By the way, thanks for winning Magny Cours grand prix Kimi... :-P
>
>
>
>
> > Hi,
> > For experienced with Pyhton users, which developing software and
> > enviroment would you suggest for Pyhton programming? Compiler+Editor
> > +Debugger.
>
> > Also what are your suggestions for beginners of Pyhton programming?
>
> > Thank you.
>
> > --
>
> - Show quoted text -
Thank you for the suggestions. I'd prefer a GUI-based, helpful and
easy-implemention skilled enviroment. Tesekkurler Sayin Kartal :-)
Roy Smith
kimiraikkonen <kimirai...@gmail.com> wrote:
I'm very happy with emacs using python mode (http://www.python.org/emacs/).
It's a love it or hate it kind of thing. If you're an emacs fan, you'll
probably not want to use anything else. If you're not an emacs fan, this
is probably not for you.
There really is no separate compiler. It's part and parcel of the
interpreter. Your .py files do get compiled into .pyc files, but it
happens automatically the first time you run a module. No need to run a
separate compilation phase like you would with C or Java.
As for a debugger, I've honestly never found the need for one. I invest a
lot of time in unit tests, which smoke out most of the bugs. For what's
left, it's easy enough to stick print statements in strategic places to see
what's going on.
cyberco
not an Apple product, but it would be worth waiting in line for 3 days
for)
http://ipython.scipy.org/moin/
Stef Mientki
> Thank you for the suggestions. I'd prefer a GUI-based, helpful and
> easy-implemention skilled enviroment. Tesekkurler Sayin Kartal :-)
>
then first decide which graphical package you want to use,
because that limits your choice.
cheers,
Stef Mientki
kimiraikkonen
wrote:
I only have experience with Dev C++ for GUI and debugging based
programming for C/C++.
But i didn't know about Python.
So, like Visual Studio and Dev C++ similiar Python editor is welcome.
Laurent Pointal
Under Windows, take a look at PyScripter.
For students learning Python, we are switching from Scite to PyScripter,
good editor, online Python shell, graphical debugger with step by step,
showing variables values in popups and many other sympathic features...
test it.
sjde...@yahoo.com
> Hi,
> For experienced with Pyhton users, which developing software and
> enviroment would you suggest for Pyhton programming? Compiler+Editor
> +Debugger.
I use standard CPython bytecode compiler/virtual machine, the Vim
editor, and standard pdb for debugging. Vim is nice as it's
multiplatform, has a built-in Python interpreter for writing
extensions, is free and lightweight. It's a modal editor so that's a
matter of taste--people either love it or hate it.
> Also what are your suggestions for beginners of Pyhton programming?
Start with something like http://www.diveintopython.org for a brief
intro.
Pick a very small project and program it. Then pick something bigger
and do that. Once you're comfortable with small projects, find an
open-source project that you like and try to understand the code
enough to make some change you find useful; reading code is as
important as writing it.
evil tabby cat
http://www.wingware.com/ is pretty impressive but non-free of both
beer & speech varieties
kimiraikkonen
What is the most reliable and easy way to start learning Ptyhon?
Books? Trusted code sammples(where?)?
I know the importance and eases of Python quiet.
Thanks.
ed
code (especially on windows).
http://drpython.sourceforge.net/
you will need wxPython to have it running though
It's not per se an IDE but it
has a lot of feature to help you writing with some interesting plug-
ins.
You can launch code in the IDE, you have an inserted console etc.
Oh and it's written in python :)
./ed
Cameron Laird
kimiraikkonen <kimirai...@gmail.com> wrote:
>Thanks for the replies so far. Also i have to learn:
>
>What is the most reliable and easy way to start learning Ptyhon?
>Books? Trusted code sammples(where?)?
.
.
Beside answering your direct questions (which others have already
done well), I think it's important to alert you (as others have
also done, though less directly) that learning and using Python is
different from VC++. Python is simply easier than C++; you might
well find that a debugger, for example, doesn't feel as essential
as it is for you with C++. Books might not be as necessary as
they were for C++.
I recommend you at least scan the following: <URL:
http://wiki.python.org/moin/BeginnersGuide >, <URL:
http://docs.python.org/tut/ >, and <URL:
http://www.poromenos.org/tutorials/python >.
kimiraikkonen
My another aim is: Can i develop graphical applications (like in
Windows) which contain menus, interactive dialog boxes etc. using
Ptyhon?
I got it quite but not sure. I don't know Ptyhon's capability skills
for creating interactive softwares like in Windows's created by C++ or
Delphi.
Kay Schluehr
> Python is simply easier than C++; you might
> well find that a debugger, for example, doesn't feel as essential
> as it is for you with C++.
That's what I love most about the Python community. Whenever there is
just a non-standard, platform-dependent or crappy implementation of a
feature you get told that you don't need it. When printf was good for
little David print is good enough for me.
Among the first things I examine about an IDE ( for Python ) is the
integration of a good REPL and how well recursive functions can be
debugged ( yes, I know, Pythonistas can't recurse and so it is not
recommended as well but sometimes ... )
Gregor Horvath
> That's what I love most about the Python community. Whenever there is
> just a non-standard, platform-dependent or crappy implementation of a
> feature you get told that you don't need it. When printf was good for
> little David print is good enough for me.
>
That's a property of open source projects.
Features nobody really needs are not implemented.
Gregor
Gregor Horvath
> My another aim is: Can i develop graphical applications (like in
> Windows) which contain menus, interactive dialog boxes etc. using
> Ptyhon?
>
> I got it quite but not sure. I don't know Ptyhon's capability skills
> for creating interactive softwares like in Windows's created by C++ or
> Delphi.
>
have a look at Dabo
Gregor
Thomas Heller
Gregor Horvath schrieb:
Nicola Musatti
[...]
> That's a property of open source projects.
> Features nobody really needs are not implemented.
No, no, you got it all wrong. It's in *commercial* projects that
features nobody really needs are not implemented. Profit is
fundamental in convincing you that you really need the features.
On the other hand open source projects tend to lack features nobody
enjoys implementing.
Cheers,
Nicola Musatti
P.S. Maybe I should add a ;-)
Roy Smith
Nicola Musatti <nicola....@gmail.com> wrote:
> On Jul 5, 1:23 pm, Gregor Horvath <g...@gregor-horvath.com> wrote:
> [...]
> > That's a property of open source projects.
> > Features nobody really needs are not implemented.
>
> No, no, you got it all wrong. It's in *commercial* projects that
> features nobody really needs are not implemented.
No, no, squared. In a commercial project, the only features that get
implemented are the ones somebody is willing to pay for. Whether there is
any correlation between need and willingness to pay is an open question.
Paul McGuire
> In article <1183644537.859604.27...@w5g2000hsg.googlegroups.com>,
> Nicola Musatti <nicola.musa...@gmail.com> wrote:
>
> > On Jul 5, 1:23 pm, Gregor Horvath <g...@gregor-horvath.com> wrote:
> > [...]
> > > That's a property of open source projects.
> > > Features nobody really needs are not implemented.
>
> > No, no, you got it all wrong. It's in *commercial* projects that
> > features nobody really needs are not implemented.
>
> No, no, squared. In a commercial project, the only features that get
> implemented are the ones somebody is willing to pay for. Whether there is
> any correlation between need and willingness to pay is an open question.
Then tell us, pray, who was willing to pay for the epitome of useless
features in MS Word, that Useless Features' Useless Feature, the
ability to format text with the animated effect "Marching Red Ants"?
I'm sure I paid for it, but it wasn't willingly...
-- Paul
sjde...@yahoo.com
> On Jul 3, 8:12 pm, cla...@lairds.us (Cameron Laird) wrote:
>
> > Python is simply easier than C++; you might
> > well find that a debugger, for example, doesn't feel as essential
> > as it is for you with C++.
>
> That's what I love most about the Python community. Whenever there is
> just a non-standard, platform-dependent or crappy implementation of a
> feature you get told that you don't need it.
A fairly nice debugger is standard and built-in to the regular Python
distribution on all platforms.
But 95% of what a debugger is used for IME is getting a stack trace--
in Python (or Java or Ruby or most modern languages) you get that
automatically, and the debugger is nowhere near as useful as it is in
C or C++.
Neil Cerutti
You should count your blessings. At least it doesn't play
pinball any more. At least, I hope not.
--
Neil Cerutti
Kay Schluehr
> On Jul 5, 1:23 pm, Gregor Horvath <g...@gregor-horvath.com> wrote:
> [...]
>
> > That's a property of open source projects.
> > Features nobody really needs are not implemented.
>
> No, no, you got it all wrong. It's in *commercial* projects that
> features nobody really needs are not implemented. Profit is
> fundamental in convincing you that you really need the features.
>
> On the other hand open source projects tend to lack features nobody
> enjoys implementing.
OSS projects have the healthy tendency to die silently. No one has yet
counted all the corpses.
Someone has mentioned Eclipse before and it somehow indicates that the
strongest distinction between an OSS project and a commercial one is
the property of being OSS.
Kay
> Cheers,
> Nicola Musatti
>
> P.S. Maybe I should add a ;-)
This is a full ;-) thread. So it would be a bit redundant to mention
it - just like this meta-comment.
Cameron Laird
You've made factual claims with which I can't agree.
If I understand you correctly, Pythoneers (to the exclusion of other
software workers?) are prone to misrepresent lacunae as irrelevant.
Perhaps I've done so in this case; perhaps I characteristically do
so myself, and need to examine my own judgment more closely. It
simply is not true, though, and even slanderous, to leave the
impression that the community as a whole wallows "fat and dumb" in
its rut of missing features. Py2exe, pyexpect, pylint, ElementTree,
and many, many other Python facilities we now take for granted didn't
exist at one time, and were recognized as important lacks. Old
comp.lang.python threads make this clear.
In writing this, I don't mean to minimize at all the merit of the
specific individuals who authored ElementTree, pylint, and so on.
You seem also to be saying that all Python debuggers are "non-standard,
platform-dependent or crappy". Is that truly your assessment of pdb
<URL: http://docs.python.org/lib/module-pdb.html >? Or are you focused
on the IDEs <URL:
http://wiki.python.org/moin/IntegratedDevelopmentEnvironments >, and
really see them all that way?
Anyway, I repeat my claim: I recommend to the original poster that he
consider learning Python in a style that's qualitatively different--
"lighter"--than his experience with C++.
Nicola Musatti
> In article <1183644537.859604.27...@w5g2000hsg.googlegroups.com>,
>
> > On Jul 5, 1:23 pm, Gregor Horvath <g...@gregor-horvath.com> wrote:
> > [...]
> > > That's a property of open source projects.
> > > Features nobody really needs are not implemented.
>
> > No, no, you got it all wrong. It's in *commercial* projects that
> > features nobody really needs are not implemented.
>
> No, no, squared. In a commercial project, the only features that get
> implemented are the ones somebody is willing to pay for. Whether there is
> any correlation between need and willingness to pay is an open question.
Ah, but you snipped the most important part of my post:
> Profit is fundamental in convincing you that you really
> need the features.
I mean, marketing is all about creating the willingness by stimulating
the perception of the need.
Cheers,
Nicola Musatti
Cameron Laird
.
.
I want to make this explicit for the benefit of the original questioner:
A. Dabo's great stuff; but
B. there are, at the same time, quite a few
other frameworks for GUI programming with
Python <URL: http://wiki.python.org/moin/GuiProgramming >.
kimiraikkonen
messed up. Think questioner as a beginner and use more understandable
terms to help :)
Thanks.
Mark Morss
"Emacs is the best for anything for me."
Me too.
Also, as pointed out by some others, a debugger is not really all that
necessary for an interpreted language like Python.
> > Hi,
> > For experienced with Pyhton users, which developing software and
> > enviroment would you suggest for Pyhton programming? Compiler+Editor
> > +Debugger.
>
> > Also what are your suggestions for beginners of Pyhton programming?
>
> > Thank you.
>
> > --
> >http://mail.python.org/mailman/listinfo/python-list
Kay Schluehr
The problem is simply that the Python community has failed in this
respect. There are many platform dependent and ideology driven ways to
do deal with code editing / debugging but not actually a recommend or
"pythonic" way. Other than Smalltalk, Python has not created an own
style / identity regarding decent development environments and since
half of the community is happy with Emacs and the other half wants to
program in a VS-like environment, neither consensus nor progress has
to be expected. If you use Google groups to access comp.lang.python
you will also recognize that your question comes up every few weeks so
it has a certain tradition to create the same spectrum of answers.
Alex Popescu
I am a Python newbie, but unfortunately I don't agree with that. For
me having a debugger helped understand very quickly the flow
in the libraries for which otherwise I would have had to navigate
through code (which once again is not always easy without a good IDE).
But this is just a newbie opinion :-),
./alex
--
.w( the_mindstorm )p.
Jason
> Hi,
> For experienced with Pyhton users, which developing software and
> enviroment would you suggest for Pyhton programming? Compiler+Editor
> +Debugger.
That would depend on what platform(s) you would be developing on, what
development environments you were used to, and so forth. I personally
enjoy working in Eclipse with the PyDev plugin. Other people love
Emacs. I know folk who you'll only pry their vim editors from their
cold, dead fingers.
For people dipping their toes into the Python pool, I recommend using
Idle. It comes with Python itself, and has a built-in debugger (see
the Debug menu), syntax highlighting, and other goodies. It's
certainly enough to write your programs in.
Quite frankly, you can use Windows Notepad to write your Python
programs. Python itself is just a language. There is no single
environment that Python ties to itself tightly. The basic debugger,
PDB, is built in as a Python module, so you can use Python to debug
itself. Most of the IDE's that provide debuggers are merely placing a
nice wrapper over the python debugger.
To develop very short programs, I often start Python on my command
line and fiddle away.
> Also what are your suggestions for beginners of Pyhton programming?
Don't worry about making GUI programs at first. GUIs are present in
every operating system, but they are an additional level of
complexity. Get the language down, first, then head into the world of
graphical user interfaces.
Start programming. See "Dive Into Python"[1]. Check out the
Beginner's section of the Python Wiki[2]. The hardest part about
learning to programming is learning to structure your thoughts into a
coherent series of logical units. The rest is just code, and code is
easy. It's the damn thinking that's so hard.
Get familiar with the Python documentation. If you are under Windows,
the Python docs are installed with Python in Microsoft's Compiled Help
format, so you can browse them via the contents, look things up in the
index, and search via the search tab. Remember that the built-in
stuff, like lists and dictionaries, are documented in the Python
Library Reference [3], while most of the modules are documented in the
Global Modules [4] document. It's huge, but if you want to know what
Python has, it's almost always in there.
If you have a question, look for the solution by Googling this
newsgroup or the web in general. If you still can't find a solution,
ask around in here. Give plenty of detail, such the exact error
messages if one occurred, and the minimum amount of working code that
causes or demonstrates the problem.
You may get twenty different answers sometimes (like for your question
here), but that's twenty answers or perspectives that you may not have
known before you asked.
--Jason
[1] http://www.diveintopython.org/
[2] http://wiki.python.org/moin/BeginnersGuide
[3] http://docs.python.org/lib/lib.html
[4] http://docs.python.org/modindex.html
Steven D'Aprano
> On Jul 5, 7:18 pm, kimiraikkonen <kimiraikkone...@gmail.com> wrote:
>> I just wanted a simple answer to my simple question, however topic has
>> messed up. Think questioner as a beginner and use more understandable
>> terms to help :)
>>
>> Thanks.
>
> The problem is simply that the Python community has failed in this
> respect. There are many platform dependent and ideology driven ways to
> do deal with code editing / debugging but not actually a recommend or
> "pythonic" way.
What makes you think this is a *problem*?
Why is it a failure that Python is perfectly usable with a whole range
of editors, debuggers and development styles?
> Other than Smalltalk, Python has not created an own
> style / identity regarding decent development environments and since
> half of the community is happy with Emacs and the other half wants to
> program in a VS-like environment, neither consensus nor progress has
> to be expected.
I don't accept that consensus on editing tools is a good thing, let
alone a necessity. Nor that progress is only possible when everybody
agrees. To quote from one of my favourite fictional characters, Lord
Vetinari:
"Pulling together is the aim of despotism and tyranny. Free men pull
in all kinds of directions." He smiled, "It's the only way to make
progress. That and, of course, moving with the times."
-Terry Pratchett, "The Truth"
--
Steven.
Alex Martelli
...
> half of the community is happy with Emacs and the other half wants to
> program in a VS-like environment, neither consensus nor progress has
Calling all vi/vim users (and we'll heartily appreciate the support of
TextMate fans, BBEdit ones, etc, etc) -- we're at risk being defined out
of existence, since we're neither happy with Emacs nor wanting anything
like Visual Studio, and yet Kay claims that people in either category
make up the whole (one half plus the other half) and so that WE DON'T
EXIST!!! A ridiculous claim to be sure, but we'd better let Herr
Schluehr know that in no uncertain terms...
Alex
Kay Schluehr
wrote:
You don't have to be unfortune about it. As you see there is no
consensus. I don't even know how Java developers would respond to the
assertion that the debugger is halfway irrelevant because they can
read the stacktraces ( A real C programmer and real man can read core
dumps. So what? ) Java is often considered as Blub but it doesn't at
least deny progress in tool development of the last 20 years.
> But this is just a newbie opinion :-),
I don't think so. BTW if you want to take a glimpse on the future of
"dynamic" languages you might also checkout this paper:
http://lamp.epfl.ch/~mcdirmid/mcdirmid07live.pdf
Kay
Gregor Horvath
> The problem is simply that the Python community has failed in this
> respect. There are many platform dependent and ideology driven ways to
> do deal with code editing / debugging but not actually a recommend or
> "pythonic" way. Other than Smalltalk, Python has not created an own
Again, that's how Open Source or a Toolkit driven development (Unixy)
works.
For every problem there are 5 solutions. One size does not fit all.
It's no fault that for example Linux Distributions do not have only one
GUI but a lot of them. It's a great fortune.
Gregor
Ben Finney
Bah, it's clear. Vim users are in the *third* half -- the larger one.
Anyone not already in those three categories can presumably find a
decent half as well.
--
\ "Intellectual property is to the 21st century what the slave |
`\ trade was to the 16th." -- David Mertz |
_o__) |
Ben Finney
Neil Cerutti
this morning.
Can I still post messages if I don't exist?
--
Neil Cerutti
Ed Jensen
> Calling all vi/vim users (and we'll heartily appreciate the support of
> TextMate fans, BBEdit ones, etc, etc) -- we're at risk being defined out
> of existence, since we're neither happy with Emacs nor wanting anything
> like Visual Studio, and yet Kay claims that people in either category
> make up the whole (one half plus the other half) and so that WE DON'T
> EXIST!!! A ridiculous claim to be sure, but we'd better let Herr
> Schluehr know that in no uncertain terms...
vi/vim/gvim user here... :)
greg
> It's in *commercial* projects that
> features nobody really needs are not implemented. Profit is
> fundamental in convincing you that you really need the features.
In Soviet Russia, you don't need features, features need *you*.
--
Greg
Douglas Alan
> Kay Schluehr <kay.sc...@gmx.net> wrote:
>> half of the community is happy with Emacs and the other half wants to
>> program in a VS-like environment, neither consensus nor progress has
> Calling all vi/vim users (and we'll heartily appreciate the support
> of TextMate fans, BBEdit ones, etc, etc) -- we're at risk being
> defined out of existence, since we're neither happy with Emacs
That's because the Emacs users are the only ones who matter.
|>oug