Is this a good time to start learning python?
Rui Maciel
programming language. I've already dipped my toes in Perl (I've read online
tutorials and wrote a couple of irrelevant pet projects) but, as the
computers at my workplace only sport the python interpreter, it probably
means that learning python will end up serving me better, at least in the
short run. Plus, you know how Perl goes.
So far the decision seems to be a no brainer. Yet, Python 3000 will arrive
in a few months. As it isn't backwards compatible with today's Python,
there is the risk that no matter what I learn until then, I will end up
having to re-learn at least a considerable part of the language. To put it
in other words, I fear that I will be wasting my time.
At least that is what a clueless newbie believes. As this group is
frequented by people who have more insight into all things pythonesque,
what are your thoughts on this?
Thanks for the help
Rui Maciel
Reedick, Andrew
Meh. That's like asking if you should learn to use a fork or a spoon.
If you're learning how to program, go with Python. (Learning as in
algorithms and data structures.)
If you need to use OO, go with Python. Perl's OO syntax is just
horrific.
If you're using a lot of regexes, need a bit of speed, or need something
a bit more robust than dynamically typed objects randomly breaking your
code, then go with Perl. ;-)
Libraries can also affect your choice. (I had to switch to Perl when
Python's win32com failed.)
Perl's learning curve is "unreadable" syntax, whereas Python's curve
requires knowing about side effects and dealing with strong, dynamic
typing.
Overall, Python is more high level and cleaner looking/readable.
However, Python's dynamically typed objects require additional
effort/expense to debug, and it's regex module is pretty quirky/painful
to use. Perl has a very large library, is fast, is mostly statically
compiled, and doesn't get in the way (automatic type conversions,
several ways to do something, etc..)
Python is probably faster to learn (clearer syntax and OO,) but slower
to master (side effects, strongly but dynamically typed.) With Perl,
once you get the core syntax down, you don't need to master Perl.
Instead you just look up the module/feature you want to use and just use
it. Finally, I find that Perl's documentation is much better than
Python's.
All IMO, IME.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
Gabriel Genellina
escribió:
> Recently I woke up inclined to take up the task of learning another
> programming language. I've already dipped my toes in Perl (I've read
> online
> tutorials and wrote a couple of irrelevant pet projects) but, as the
> computers at my workplace only sport the python interpreter, it probably
> means that learning python will end up serving me better, at least in the
> short run. Plus, you know how Perl goes.
>So far the decision seems to be a no brainer. Yet, Python 3000 will
> arrive
> in a few months. As it isn't backwards compatible with today's Python,
> there is the risk that no matter what I learn until then, I will end up
> having to re-learn at least a considerable part of the language. To put
> it
> in other words, I fear that I will be wasting my time.
Don't be scared by the "backwards incompatible" tag - it's the way to get
rid of nasty things that could not be dropped otherwise. The basics of
Python will continue to be the same, it's not a new, different language;
learning Python 2.X isn't a waste of time.
Python 3 won't be in widespread use until some (long?) time, and some
people won't ever consider it until Python 3.1 arrives; so Python 2.X will
continue being used for a long time.
--
Gabriel Genellina
Terry Reedy
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:47f1140e$0$735$a729...@news.telepac.pt...
| Recently I woke up inclined to take up the task of learning another
| programming language. I've already dipped my toes in Perl (I've read
online
| tutorials and wrote a couple of irrelevant pet projects) but, as the
| computers at my workplace only sport the python interpreter, it probably
| means that learning python will end up serving me better, at least in the
| short run. Plus, you know how Perl goes.
If you intend to use Python on the computer at your workplace, then learn
the version installed there.
| So far the decision seems to be a no brainer. Yet, Python 3000 will
arrive
| in a few months. As it isn't backwards compatible with today's Python,
| there is the risk that no matter what I learn until then, I will end up
| having to re-learn at least a considerable part of the language.
Most of the changes are deletions and additions, rather than changes.
3.0a4 will be out in a few days. If you had no reason to use anything
else, I would consider starting with that. (But the IDLE IDE on Windows
may still not work right.)
| To put it in other words, I fear that I will be wasting my time.
If you learn and use 2.x, then avoid things that are going away. In
particular:
Unless you need to learn about old-style classes, I would not bother with
them and the differences from new, soon to be the only style, classes.
Derive all your classes from object or a subclass thereof.
Use // for integer floor division (ie, when you want 1/2 == 0.
Use 'from __future__ import division' if you use '/' in a file where both
operands
might be ints and you would want 1/2==.5.
| At least that is what a clueless newbie believes. As this group is
| frequented by people who have more insight into all things pythonesque,
| what are your thoughts on this?
Diverse, I am sure ;-)
Terry Jan Reedy
Ant
...
> So far the decision seems to be a no brainer. Yet, Python 3000 will arrive
> in a few months. As it isn't backwards compatible with today's Python,
> there is the risk that no matter what I learn until then, I will end up
> having to re-learn at least a considerable part of the language. To put it
> in other words, I fear that I will be wasting my time.
Not at all. The lead developers have a plan for migrating older
scripts to 3000 automatically (or at least semi-automatically). This
can be done because the core syntax and builtin's are remaining
largely the same. The sort of thing that is changing in a way that
breaks backward compatibility are things such as removing the print
statement (e.g. >>> print "Hello world") with a print function (e.g.
print("Hello world")) and rearranging the standard library.
As Terry said, the major changes are additions and deletions - to
expand on this, the deletions are generally likely to be modules that
are rarely used or are unmaintained.
In any case, the python developers have a very good policy of making
the upgrade path to new versions of Python smooth. Generally new
features are released into the __future__ module in a release ready
for inclusion in the next release. This allows time to play with new
features before the "official" release of the feature comes out.
Module deletions usually hang around for a few releases as
"deprecated" before being permanently removed - again giving time to
catch up.
I believe that the deprecation speed may come rather abruptly with
3000, however the 2.6 release will contain a PyLint program for
identifying changes that will need to be made before migrating to 3k.
In addition, the 2.x branch is AFAIK going to be maintained up to (but
no further than) a 2.9 release. So there will be plenty of time to
adjust!
In short, any time invested in learning Python at this stage (except
perhaps old-style classes as pointed out above) will be time well
spent, as learning Python 3000 will be minor tweaks to what you'll
already know.
And for what it's worth, I've programmed in Haskell, C, Java (Java's
my profession), Javascript and Perl, and dabbled with Ruby, Lisp,
Groovy (and probably others), and Python is by far my favorite
language, not just for the clean syntax, rapid development,
readability 5 years down the line etc, but also for the community,
which is very helpful and knowledgeable.
BTW. I have to disagree with Andrew's comment: "With Perl,
once you get the core syntax down, you don't need to master Perl.
Instead you just look up the module/feature you want to use and just
use
it.". This may be true for knocking up Perl scripts, but for reading
*other peoples* code in any language you need to have a good mastery
of the core language. In Perl this is a quagmire of strange syntax,
special cases, multiple ways to do the same thing and esoterica/magic,
whereas Python's design to make whitespace significant and its "One
(obvious) way to do things" philosophy makes reading other peoples
code much easier. (Of course other peoples code always sucks, but
hey ;-)
Colin J. Williams
> "Rui Maciel" <rui.m...@gmail.com> wrote in message
> news:47f1140e$0$735$a729...@news.telepac.pt...
> | Recently I woke up inclined to take up the task of learning another
> | programming language. I've already dipped my toes in Perl (I've read
> online
> | tutorials and wrote a couple of irrelevant pet projects) but, as the
> | computers at my workplace only sport the python interpreter, it probably
> | means that learning python will end up serving me better, at least in the
> | short run. Plus, you know how Perl goes.
>
> If you intend to use Python on the computer at your workplace, then learn
> the version installed there.
>
> | So far the decision seems to be a no brainer. Yet, Python 3000 will
> arrive
> | in a few months. As it isn't backwards compatible with today's Python,
> | there is the risk that no matter what I learn until then, I will end up
> | having to re-learn at least a considerable part of the language.
>
> Most of the changes are deletions and additions, rather than changes.
>
> 3.0a4 will be out in a few days. If you had no reason to use anything
> else, I would consider starting with that. (But the IDLE IDE on Windows
> may still not work right.)
Replace IDLE by PyScripter and then you
have a good development environment for
Python 3000.
Colin W.
Rui Maciel
group, crank up the tutorials and start getting my head around Python.
Thanks for all the helpful replies. Kudos, everyone!
Rui Maciel
Reedick, Andrew
> -----Original Message-----
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
Eh... reading other people's Python code can be pretty hit or miss too.
Between undeclared variables (did you mean to reuse that variable name?)
and dynamic typing, Python can be really tough to follow. Add in side
effects, over-use of lambdas, and the really hit or miss quality of
Python's documentation, and Python can be just as difficult to follow as
Perl.
The things that make code readable are good comments, good design
(Python emphasizes OO which helps,) and well-structured code (i.e. don't
combine 3-4 operations in a single line.) This holds true for any
language, so I wouldn't go out of my to ding Perl. IME.
> its "One (obvious) way to do things" philosophy
Given some of the solutions people have proposed to code questions in
the past, I'm going to pretend you didn't say that. ;-)
lbon...@yahoo.com
wrote:
> Don't be scared by the "backwards incompatible" tag - it's the way to get
> rid of nasty things that could not be dropped otherwise.
I would consider breaking production code to be "nasty" as well.
Gabriel Genellina
Please explain how the existence of Python 3.0 would break your production
code.
--
Gabriel Genellina
lbon...@yahoo.com
wrote:
> En Tue, 01 Apr 2008 13:57:55 -0300, <lbonaf...@yahoo.com> escribió:
>
> > On Mar 31, 1:36 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
> > wrote:
>
> >> Don't be scared by the "backwards incompatible" tag - it's the way to
> >> get
> >> rid of nasty things that could not be dropped otherwise.
>
> > I would consider breaking production code to be "nasty" as well.
>
> Please explain how the existence of Python 3.0 would break your production
> code.
The existence of battery acid won't hurt me either, unless I come into
contact with it. If one eventually upgrades to 3.0 -- which is
ostensibly the desired path -- their code could break and require
fixing.
Backward compatibility is important. C++ could break all ties with C
to "clean up" as well, but it would be a braindead move that would
break existing code bases upon upgrade.
Eduardo O. Padoan
> On Apr 1, 12:47 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
> wrote:
> > En Tue, 01 Apr 2008 13:57:55 -0300, <lbonaf...@yahoo.com> escribió:
>
> >
> > > On Mar 31, 1:36 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
> > > wrote:
> >
> > >> Don't be scared by the "backwards incompatible" tag - it's the way to
> > >> get
> > >> rid of nasty things that could not be dropped otherwise.
> >
> > > I would consider breaking production code to be "nasty" as well.
> >
>
> > Please explain how the existence of Python 3.0 would break your production
> > code.
>
> The existence of battery acid won't hurt me either, unless I come into
> contact with it. If one eventually upgrades to 3.0 -- which is
> ostensibly the desired path -- their code could break and require
> fixing.
And how would this happen? I dont know of any good software
distribution that upgrades a component to another major revision
without asking first. The desired path is that, if somene wants to
port his software to Python 3.0, that he follow the migration plan.
Final users will install Python 3.0 as python3.0 anyway, with Python
2.x as default 'python' binary.
> Backward compatibility is important. C++ could break all ties with C
> to "clean up" as well, but it would be a braindead move that would
> break existing code bases upon upgrade.
>
C++ is not C. No one "upgrades" from C to C++.
--
Eduardo de Oliveira Padoan
http://www.advogato.org/person/eopadoan/
Bookmarks: http://del.icio.us/edcrypt
lbon...@yahoo.com
wrote:
> On Tue, Apr 1, 2008 at 3:57 PM, <lbonaf...@yahoo.com> wrote:
> > On Apr 1, 12:47 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
> > wrote:
> > > En Tue, 01 Apr 2008 13:57:55 -0300, <lbonaf...@yahoo.com> escribió:
>
> > > > On Mar 31, 1:36 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
> > > > wrote:
>
> > > >> Don't be scared by the "backwards incompatible" tag - it's the way to
> > > >> get
> > > >> rid of nasty things that could not be dropped otherwise.
>
> > > > I would consider breaking production code to be "nasty" as well.
>
> > > Please explain how the existence of Python 3.0 would break your production
> > > code.
>
> > The existence of battery acid won't hurt me either, unless I come into
> > contact with it. If one eventually upgrades to 3.0 -- which is
> > ostensibly the desired path -- their code could break and require
> > fixing.
>
> And how would this happen? I dont know of any good software
> distribution that upgrades a component to another major revision
> without asking first. The desired path is that, if somene wants to
> port his software to Python 3.0, that he follow the migration plan.
Of course, that's the point. If you want to upgrade to the next
version of Python, you have to fix your code. That stinks. Your
other alternative is to remain stuck with Python 2.x, but eventually
the support for that will dry up.
> Final users will install Python 3.0 as python3.0 anyway, with Python
> 2.x as default 'python' binary.
>
> > Backward compatibility is important. C++ could break all ties with C
> > to "clean up" as well, but it would be a braindead move that would
> > break existing code bases upon upgrade.
>
> C++ is not C. No one "upgrades" from C to C++.
You misunderstand. C++ has a lot of "warts" to maintain backwards
compatibility with C. The standards committee could eliminate these
warts to make the language "cleaner", but it would break a lot of
systems.
Eduardo O. Padoan
> > > > Please explain how the existence of Python 3.0 would break your production
> > > > code.
> >
> > > The existence of battery acid won't hurt me either, unless I come into
> > > contact with it. If one eventually upgrades to 3.0 -- which is
> > > ostensibly the desired path -- their code could break and require
> > > fixing.
> >
>
> > And how would this happen? I dont know of any good software
> > distribution that upgrades a component to another major revision
> > without asking first. The desired path is that, if somene wants to
> > port his software to Python 3.0, that he follow the migration plan.
>
> Of course, that's the point. If you want to upgrade to the next
> version of Python, you have to fix your code. That stinks. Your
> other alternative is to remain stuck with Python 2.x, but eventually
> the support for that will dry up.
"Eventually" it will take a decade to happen. 2.x support will not be
dropped untill gets (much) more users than Python 3.x.
> > Final users will install Python 3.0 as python3.0 anyway, with Python
> > 2.x as default 'python' binary.
> >
>
> > > Backward compatibility is important. C++ could break all ties with C
> > > to "clean up" as well, but it would be a braindead move that would
> > > break existing code bases upon upgrade.
> >
>
> > C++ is not C. No one "upgrades" from C to C++.
>
> You misunderstand. C++ has a lot of "warts" to maintain backwards
> compatibility with C. The standards committee could eliminate these
> warts to make the language "cleaner", but it would break a lot of
> systems.
It would not "break" anything that not move from C to C++, this is my point.
People not willing to take the migration path (porting to 2.6, using
the -3 flag, refactoring and re-running the tests untill the warning
are gone, using the 2to3 tool...) will not upgrade. No one will force
you to do it. 2.6 will not desappear from the python.org site anytime
soon.
lbon...@yahoo.com
wrote:
> On Tue, Apr 1, 2008 at 4:20 PM, <lbonaf...@yahoo.com> wrote:
> > You misunderstand. C++ has a lot of "warts" to maintain backwards
> > compatibility with C. The standards committee could eliminate these
> > warts to make the language "cleaner", but it would break a lot of
> > systems.
>
> It would not "break" anything that not move from C to C++, this is my point.
You missed the point completely. C++ has a new version coming out
soon, and as part of it, the less attractive parts of the language
(like C compatibility) are NOT being removed, as that would break a
lot of existing apps.
> People not willing to take the migration path (porting to 2.6, using
> the -3 flag, refactoring and re-running the tests untill the warning
> are gone, using the 2to3 tool...) will not upgrade. No one will force
> you to do it. 2.6 will not desappear from the python.org site anytime
> soon.
Will 2.6 be supported with patches and fixes going forward?
Basilisk96
Think of it this way -
A.) If you start learning Python 2.5 *today*, and then Python3k comes
out in a few months and (at worst) breaks all your code, you will
still have less code to patch than the person who learned Python 2.3
two years ago :)
B.) If you start learning Python 2.5 *tomorrow*... who knows, we might
not be alive tomorrow. Seize the day.
Seriously, I have watched Guido's GoogleTalk on Py3k plans, and the
changes are not all that scary. I'm looking forward to it.
Cheers,
-Basilisk96
Gabriel Genellina
The C++ comitee has a different point of view than the Python developers,
I think.
You don't have to upgrade if you don't want to. Nobody will come and
magically erase your installed 2.X python. 2.X sources won't be wipped out
from the earth surface. Right now people is still using ten-years-old
Python 1.5, and in ten years surely there will be people using Python 2.X
too. (We still support things written in QuickBasic and Turbo Pascal 3.0
for DOS)
There is an upgrade path, with intermediate versions, `from future
import...`, automatic conversion tools (2to3), so you're not alone if you
want to upgrade. The differences aren't so scaring after all, and they
make 3.0 a much clean language.
--
Gabriel Genellina
Steve Holden
Yes.
About the only definite assertion Guido has so far made about the 2.x
series is that it won't go further than 2.9, as he feels that 2.10 is
ambiguous about its position in the series.
You should expect at least three years of Python 2.X after the release
of 3.0 (and the simultaneous release of 2.6) this August.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/