Re: Beginner needs advice
memilanuk
> Here's my background:
>
> I'm a Windows based Visual FoxPro developer, and I want to start
> programming in Python. I'll be sticking to Windows (XP & 7) and my
> immediate needs are to manage & display large groups of jpg's, tiff's
> etc... so I need form based & graphics capable libraries (in addition to
> basic programming skills, of course).
>
> So Python 2 or 3? Add on packages/libraries? Tutorials?
>
> Thanks!
>
> -Lew
>
If Visual Foxpro is your thing, maybe Dabo (www.dabodev.com) would be of
interest to you. The developers are former Visual Foxpro programmers...
Jean-Michel Pichavant
> So, if I read between the lines correctly, you recommend Python 3?
> Does the windows version install with a development environment?
If you want to use python 3, make sure before that all the good stuff
you need (==modules) have been ported to python 3.
If you are a complete beginner, I would advise python 2.7.
JM
Colin J. Williams
> So, if I read between the lines correctly, you recommend Python 3? Does
> the windows version install with a development environment?
>
It would be safer to stick with Python 2.7 initially and then consider
the transition to 3.2 later.
No, there is not more than Idle.
PyScripter provides an excellent development environment. See:
http://en.wikipedia.org/wiki/PyScripter
Colin W.
harrismh777
> It would be safer to stick with Python 2.7 initially and then consider
> the transition to 3.2 later.
I must disagree with Colin's statement. If you are a complete beginner
with Python... then there is going to a learning curve for you... and
that curve should be 3.2--- period.
It is true that some modules are not ready for 3.x, and it is also true
that many installed systems (probably most) do not have 3.x installed.
But that is not the point. The point is that 3.x is completely
incompatible with 2.x (some call it a dialect, but that is a lie).
Python3 is the future of the language, and if you're new to Python, then
learn 3.x, move forward and don't look back... seriously.
kind regards,
m harris
Steven D'Aprano
> 3.x is completely incompatible with 2.x (some call it a dialect,
> but that is a lie).
"Completely incompatible"? A "lie"?
import math
import random
my_list = [3, 5, 7, 9]
n = random.choice(my_list)
if n%3:
func = math.sin
else:
func = math.cos
y = func(math.pi/n)*10
L = ['spam']*(int(y))
for item in L:
print(item)
is valid syntax in every version of Python from 1.5 to 3.2, and it does
the same thing in all of them. Would you care to revise your claims?
--
Steven
harrismh777
> Would you care to revise your claims?
No.
You have erected a straw-man... once again.
Most 2.x code *will not* run correctly in 3.x/ Most of the best
improvements and enhancements of 3.x will not back-port to below 2.7,
and almost none of them will back-port before 2.6 (class decorations,
for instance).
Some interfaces have changed! cmp keyword, but lets not bring that up
again....
Many syntaxes have changed or have disappeared...
... and some commands (like reload for instance) either don't exist in
3.x, or have been hidden, replaced, or changed...
All of these things are for the better, I must add. But, the point is
that 3.x is completely incompatible with 2.x in real ways. Arguing that
this is *not true* because you are able to create a code block that just
happens 'to work' in all versions (and that hasn't been verified yet)
does not in *any* way 'prove' that 3.x is a compatible dialect--- far
from it... its a straw-man argument.
kind regards,
m harris
Ethan Furman
> So, if I read between the lines correctly, you recommend Python 3? Does
> the windows version install with a development environment?
Dabo, last I checked, uses wxPython, which uses wxWidgets (sp?), which
is not yet ported to Python 3. So if you got that route you'll need to
stay with 2.7.
~Ethan~
Chris Angelico
> Most 2.x code *will not* run correctly in 3.x/ Most of the best
> improvements and enhancements of 3.x will not back-port to below 2.7, and
> almost none of them will back-port before 2.6 (class decorations, for
> instance).
What's with the "below 2.7"? If you're comparing 3.x and 2.x, wouldn't
it be most plausible to compare 3.2 and 2.7?
And, the biggest reason for 2.x code not running on 3.x is probably
the print function. (Guess made without any data beyond my own
personal corpus of Python 2 code.) That's something that can be
corrected by, oh, I dunno, the 2to3 translator maybe? And the
__future__ import makes 2.6+ work the same way as 3.x.
> All of these things are for the better, I must add. But, the point is that
> 3.x is completely incompatible with 2.x in real ways. Arguing that this is
> *not true* because you are able to create a code block that just happens 'to
> work' in all versions (and that hasn't been verified yet) does not in *any*
> way 'prove' that 3.x is a compatible dialect--- far from it... its a
> straw-man argument.
You're correct that one code block does not prove the point. But your
argument is just as flimsy. To say that "most" 2.x code is
incompatible with 3.x is to deny the 2to3 utility, and you're ignoring
the people who deliberately write code that can cross-execute on
either version - which is really not that difficult, if you take some
care and use __future__ directives.
Chris Angelico
harrismh777
> To say that "most" 2.x code is
> incompatible with 3.x is to deny the 2to3 utility,
Oh, yes absolutely. Please don't misunderstand... anyone... I'm not
saying that code cannot be migrated... migration can usually occur
between incompatible releases and and between languages!... all I'm
saying is that 3.x is not compatible with 2.x code (completely not
compatible), and if you're a noob there is no reason to learn 2.x/
Learn 3.x and pickup whatever needs to be gained from 2.x if it comes
up... we're talking about learning python as a newbie--- go with 3.x and
never look back... seriously...
> and you're ignoring
> the people who deliberately write code that can cross-execute on
> either version - which is really not that difficult,
That's what I do... but I'm not a newbie. I have existing code that
needs to be migrated, and I have an interest in creating research apps
that will run on existing 2.x systems but will be ready and waiting for
the time when the system moves to 3.x. I need to know both 2.6 and 3.2
very well. And I'll be honest about this, it is very frustrating. There
are literally hundreds of changes and variations (its all in the
details). Many Pythonists are not honest about this... because they
don't want to scare folks away from 3.x, and I don't really blame them.
But the true picture is that 3.x is (way better) and completely
incompatible with 2.x. Lying about this isn't helpful to anyone coming
on board with Python. Just tell them the truth...
kind regards,
m harris
Ethan Furman
> Chris Angelico wrote:
>> To say that "most" 2.x code is
>> incompatible with 3.x is to deny the 2to3 utility,
>
> saying is that 3.x is not compatible with 2.x code (completely not
> compatible)
>
>> the people who deliberately write code that can cross-execute on
>> either version - which is really not that difficult,
>
> That's what I do...
>
> on board with Python. Just tell them the truth...
Um -- how can you have on the one hand "completely not compatible" and
on the other "code that can cross-execute on either version"?
~Ethan~
Thomas Rachel
> On Fri, 27 May 2011 09:40:53 -0500, harrismh777 wrote:
>
>> 3.x is completely incompatible with 2.x (some call it a dialect,
>> but that is a lie).
>
> "Completely incompatible"? A "lie"?
Hard word, but it is true. Many things can and will fall on your feet
when moving.
There are very many subtle differences.
> import math
> import random
> my_list = [3, 5, 7, 9]
> n = random.choice(my_list)
> if n%3:
> func = math.sin
> else:
> func = math.cos
>
> y = func(math.pi/n)*10
> L = ['spam']*(int(y))
> for item in L:
> print(item)
>
>
> is valid syntax in every version of Python from 1.5 to 3.2, and it does
> the same thing in all of them.
C and C++ guys complain if these languages are intermixed. Even there it
is possible to write a program which is valid in both of them.
Nevertheless, they are two different languages.
So are Py2 and Py3, IMHO.
Thomas
Steven D'Aprano
> But the true picture is that 3.x is (way better) and completely
> incompatible with 2.x. Lying about this isn't helpful to anyone coming
> on board with Python. Just tell them the truth...
Take your own advice and stop accusing others of lying when it is you
spreading falsehoods about Python 3.
It is simply NOT TRUE that Python 3 is "completely incompatible" with
Python 2. You keep making this accusation, but even the most cursory look
at Python syntax, keywords, built-in objects, execution model, and
standard library show that most things keep the same interface, and most
of the remainder change in backward compatible ways.
There are some backwards incompatibilities, but nearly all of them can be
resolved by an automated fixer, no human intelligence required.
Far from being "completely incompatible", the truth is that Python 2.7
and 3.2 are more like 99% compatible. This is why there are 168
identical .py files in the Python 2.7 and 3.2a standard libraries.
[steve@sylar ~]$ diff -rqbs --exclude="*.py[co]" /usr/local/lib/
python2.7/ /usr/local/lib/python3.2/ | grep identical | grep \\.py | wc -l
168
Calling Python 2 and Python 3 "different languages", as you have done, is
simply wrong. Lisp and Python are different languages; Ruby and Python
are different languages. Forth and Python are different languages. Python
2 and 3 are not. They are the same language that share nearly everything
in common but have a few significant differences.
Calling them "completely incompatible" is completely inaccurate.
--
Steven
Steven D'Aprano
> Steven D'Aprano wrote:
>> Would you care to revise your claims?
>
> No.
>
>
> You have erected a straw-man... once again.
You keep using that term, but it is clear to me that you don't have the
foggiest idea of what the straw-man fallacy is.
A straw man is not when somebody points out holes in your argument, or
unwanted implications that you didn't realise were there. It is when
somebody makes claims on your behalf that you did not make to discredit
you, not because you don't understand the implications of your own
argument.
You stated that Python 2 and Python 3 are COMPLETELY INCOMPATIBLE -- your
words, not mine. You have repeated that claim, in this very post, and
others, despite having been shown that they are not completely
incompatible at all, that it is possible to write both forward and
backward compatible code that works in every version of Python from 1.5
through 3.2 inclusive.
Yes, it is true that you can also write code that works in 2.5 but not
3.2, but so what? You can also write code that works in 2.5 but not 2.6:
raise "some error" # works in 2.5 and older
Or 2.4 and 2.5:
True = 23 # works in 2.4 and older
or 2.3 and 2.4:
None = 42 # works in 2.3 and older
Do you think that Python 2.3, 2.4, 2.5 and 2.6 are four completely
different languages, and if not, why not?
Python 3 is not the first backwards incompatible version of Python.
[...]
> All of these things are for the better, I must add. But, the point is
> that 3.x is completely incompatible with 2.x in real ways.
And you've done it again, despite the fact that you can write compatible
code that works in all versions of Python from 1.5 to 3.2, and easily
write non-trivial code that works in 2.7 and 3.2. For larger projects,
it's probably better to keep a separate 2.x and 3.x fork, but that's for
convenience, nothing more: numpy, for example, supports 2 and 3 out of a
single code base.
http://www.mail-archive.com/numpy-discussion%40scipy.org/msg26524.html
Perhaps you don't understand what "completely" means and are confusing it
with "slightly".
--
Steven
Thorsten Kampe
> Am 27.05.2011 17:52 schrieb Steven D'Aprano:
> > On Fri, 27 May 2011 09:40:53 -0500, harrismh777 wrote:
> >> 3.x is completely incompatible with 2.x (some call it a dialect,
> >> but that is a lie).
> >
> > "Completely incompatible"? A "lie"?
>
> Hard word, but it is true. Many things can and will fall on your feet
> when moving.
I think we should stop talking about (in)compatability because everyone
seems to associate something different with that term (incompatible =
"no Python2 to code will run with Python3", "not all Python2 code will
run with Python3").
The question is: if you want (or have) to run your code under Python3,
how likely is that it will run unmodified? My experience is: unless the
code is especially written with Python3 compatability or just a short
snippet, it's actually quite unlikely that it will run.
I modified three programs/modules (none of them written with Python3 in
mind - I was thinking that Python 3000 would come out some day after
Perl 6, PHP 6 and GNU Hurd; how could I know that the Python developers
actually mean business?)
One is a tool box kind of module. I had to insert lots of "list()" and
add a complete function that would deal with the different behaviour of
"sort". Probably easy to find the problems if you have extensive unit
tests but without it was a tedious nightmare.
The second a kind of script template. gettext.install has no "unicode =
True". Easy fix but I wondered why Python 3 does not ignore the keyword
simply.
The third, a more real world complete application using PyQt. Took me
about a day to fix. The problem was not just with the code but also with
the tools (pyuic4, pyrcc4). Without the PyQt mailing list this wouldn't
have been possible. Still: a complete workday (or even more) for 150
lines of code.
Thorsten
Thorsten Kampe
> My experience is: unless the code is especially written with Python3
Oops, I meant "unless the code is specifically written with Python3
compatability in mind [...]"
Thorsten
Chris Angelico
<thor...@thorstenkampe.de> wrote:
> The question is: if you want (or have) to run your code under Python3,
> how likely is that it will run unmodified? My experience is: unless the
> code is especially written with Python3 compatability or just a short
> snippet, it's actually quite unlikely that it will run.
>
But what about the 2to3 tool? If you use that, then how much more is
there to deal with?
I installed Python 3 and found that a little bandwidth monitor stopped
working. After running it through 2to3, there were only a couple of
things needing fixing, including the HTTPS library (it didn't like my
Unicode strings, I had to go b" " for them), but the bulk of it was
fine.
Chris Angelico
Steven D'Aprano
> * Thomas Rachel (Sat, 28 May 2011 07:06:53 +0200)
>> Am 27.05.2011 17:52 schrieb Steven D'Aprano:
>> > On Fri, 27 May 2011 09:40:53 -0500, harrismh777 wrote:
>> >> 3.x is completely incompatible with 2.x (some call it a dialect, but
>> >> that is a lie).
>> >
>> > "Completely incompatible"? A "lie"?
>>
>> Hard word, but it is true. Many things can and will fall on your feet
>> when moving.
>
> I think we should stop talking about (in)compatability because everyone
> seems to associate something different with that term (incompatible =
> "no Python2 to code will run with Python3", "not all Python2 code will
> run with Python3").
There is a difference between "completely incompatible" and merely
"incompatible to some degree". It just takes *one* tiny incompatibility
to stop a program running, so "will it run unmodified?" is hardly a good
measure of the degree of incompatibility.
Python 2.5 and 2.6 are incompatible to some degree. I recently had to
port a client's program from 2.3 to 2.6. I did it in two steps: about two
hours to get it working in 2.5, then the same to get it working in 2.6,
and then about a day of effort to iron out all the display issues in
Tkinter (such as text being shown in giant letters).
Judging by the binary Yes/No "does it run unmodified?" test, I'd have to
say that Python 2.3, 2.5 and 2.6 are "completely different" -- which
would be foolish. Nobody sensible applies such a simple-minded, overly
strict test to minor releases, or even between major releases like 1.5
versus 2.0. What would be the point? It is not the least bit helpful to
learn that your 2.3 code doesn't run unmodified in 2.6. (Learning that it
does, on the other hand, is useful. But such code is in a minority.)
And yet some people are willing to throw commonsense away and apply such
an obviously unsuitable test to Python 3. These people vehemently insist
that the differences between Python 2.7 and 3.2 are of the same
qualitative kind as between Ruby and PHP (they're *different languages*
you see, not merely different dialects of the same language, and anyone
who tells you different is not just mistaken but *lying*).
> The question is: if you want (or have) to run your code under Python3,
> how likely is that it will run unmodified?
That's not a useful question. The useful question is to ask how much
effort is it to make the code run in the new version. The effort might be
zero (but probably isn't), or it might be a minute, or an hour, or a day,
or six months... that depends partly on the complexity of your code and
partly on the differences between Python 2.x and 3.x.
A trivial app might take three minutes to port from Python 2.5 to 3.2. A
complicated app might take three months to port from 2.5 to 2.6. What
generalization do we make from this?
> My experience is: unless the
> code is especially written with Python3 compatability or just a short
> snippet, it's actually quite unlikely that it will run.
You describe taking a full day to upgrade a 150 line PyQt application.
Only it wasn't a 150 line application, was it? By your own admission,
much of the problems were in the library, PyQt, so it was more like
150,000 lines. (Or whatever the size of PyQt is...)
Rather than "it took a full day to upgrade 150 lines to use Python 3,
that's terrible!", it is more like "it only took a day to upgrade my 150
line app *and* work around a whole lot of problems with a huge library,
that's really great!"
--
Steven
D'Arcy J.M. Cain
Thomas Rachel
<nutznetz-0c1b6768-bfa9...@spamschutz.glglgl.de>
wrote:
> > "Completely incompatible"? A "lie"?
>
> Hard word, but it is true. Many things can and will fall on your feet
> when moving.
>
> There are very many subtle differences.
The space between "Completely incompatible" and "many subtle
differences" is about the size of the Grand Canyon.
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Uncle Ben
Just this past Tuesday, I blindly downloaded 3.1 and found that at the
level I am workloing, all it took to get my 2.7 code to run was to put
parens around the print arguments and double the slashes in integer
division. I didn't even use the 2to3 automation.
But I am a noob to Python, which is my tenth computer language. Maybe
when I get more ambitious I will find more serious differences.
harrismh777
> Um -- how can you have on the one hand "completely not compatible" and
> on the other "code that can cross-execute on either version"?
Great question ! .. .it has to do with education.
... if you learn 2.x (only) and attempt to program on the 3.x platform,
(without helps, education, migration tools, etc) you will fail... and
you will be frustrated. Why? 3.x is not compatible with 2.x knowledge.
If you learn 3.2 (only) and attempt to program on 2.x you will fail,
and you will be frustrated. Why? Because the two languages are
different and incompatible.
Now then, can you learn both?... sure. Can you migrate one to the
other with enough knowledge and effort?... yup. Is it possible (with
enough cleverness) to write code that will run on "both" without
modification... yes... Are the two languages compatible? No!
Where this really counts of course is real-world apps. It is relatively
easy to write trivial code blocks that demonstrate that nothing has
changed in 3.x/ ... and they are *all* misleading. The truth is that
hundreds of details have changed making the two 'versions' actually
different languages.
If I use the '89 version (1) K&R to write a C program, and compile it
on the current gcc without mods it will run. If I use the 2.5 python
manual to write a python program and try to run it on 3.2 it will fail
(for many, many reasons). This is my definition of completely
incompatible. The two languages are different; period.
The problem is that they "look" similar. :)
kind regards,
m harris
Chris Angelico
> The problem is that they "look" similar. :)
C looks like every other bracey language in the world. Is that a
problem? According to Wikipedia, there's quite a lot of them:
http://en.wikipedia.org/wiki/List_of_programming_languages_by_category#Curly-bracket_languages
I would say that the difference between the difference between Python
2 and Python 3 and the difference between C and Javascript (there,
parse THAT one without parentheses!) is that the latter have a
fundamentally different data philosophy. Both versions of Python are
the same language, because they "think" the same way; high level
objects that can be multiply-referenced, and are disposed of when no
longer needed. (That sounds like an implementation detail -
refcounting - but I don't really care how it does it under the hood,
as long as I can have multiple variables pointing to the same object,
and have objects not need explicit deallocation.) Little syntactic
differences like whether 'print' is a function or a statement, and
whether the simple slash operator between two ints returns a float,
and the fact that Unicode is the default string type, are
comparatively minor; on 'most every philosophical point, the two
dialects agree.
Chris Angelico
Terry Reedy
> Just this past Tuesday, I blindly downloaded 3.1 and found that at the
> level I am workloing, all it took to get my 2.7 code to run was to put
> parens around the print arguments and double the slashes in integer
> division. I didn't even use the 2to3 automation.
1//2 works in 2.7 and earlier.
from __future__ import division
gives 1/2 == 0.5 and in 3.x
print('abc') is the same as print 'abc'
The parens only make a difference with 2 or more items.
--
Terry Jan Reedy
harrismh777
> Both versions of Python are
> the same language, because they "think" the same way;
I appreciate your thought. And there is an obvious continuity in
philosophy between 2.x and 3.x; in fact even a cursory study of the
history of python demonstrates a concerted effort to build on the best
points of 2.x while eliminating the worst. 3.x builds upon and adds to
2.x, as (loosely) C++ builds on and adds to C. Perhaps python3 should
have been named Python+ ! ( I think I've already told yous guys that
I invoke python3 on my desk machine with--- Anaconda
I see your point. But, knowing that 3.x "thinks" like 2.x is not
helpful when we all know that languages don't think, people do. People
need to be able to understand the 'details' of the language in order to
be able to think with it...
> Little syntactic
> differences like whether 'print' is a function or a statement, and
> whether the simple slash operator between two ints returns a float,
> and the fact that Unicode is the default string type, are
> comparatively minor; on 'most every philosophical point, the two
> dialects agree.
Minor, yes, .... until you need to make something work--- only to be
frustrated to find that a detail that was not expected has risen to bite
a sensitive place... :)
I am amazed at how many folks are not using 3.x/ Why? (beats me),
but how do I know they're not using it...? Because, if they were
trying to use it with 2.x knowledge they would be complaining bloody
murder.. for instance, how do we reload a module in 2.x... with, um,
reload. This has always been the way... every book says so, and every
one of us has re-invoked a .py file by using relaod. Reload doesn't
even work on 3.x without an import. If you don't know that, well, you're
sol until you figure it out, read it, or somebody tells you. This ought
not to be. Even the environments of these two languages are
incompatible (partially) :)
PS Something nobody has pointed out yet is that "completely
incompatible" is redundant. ... its like saying totally destroyed.
I was trying to be funny, but nobody unpinned it... I'm disappointed.
Some of the posts here are referring to the two languages as partially
incompatible.... reminds me of that line from Princess Bride... "...
he's not dead, hes only mostly dead!... and mostly dead is partly
alive!" To say that 3.x is partly compatible with 2.x is silly, but to
say that 3.x 'thinks' the same way as 2.x is almost pythonesque... I
almost like that... :)
kind regards,
m harris
Chris Angelico
> Chris Angelico wrote:
>> Both versions of Python are
>> the same language, because they "think" the same way;
> when we all know that languages don't think, people do.
I was being (deliberately) sloppy with the English language there, but
I was referring to the fundamental philosophies of Python, which are
common across both versions (and, presumably, most/all of them can be
seen in Python 1 too; I've never used Python 1).
>> Little syntactic
>> differences like whether 'print' is a function or a statement, and
>> whether the simple slash operator between two ints returns a float,
>> and the fact that Unicode is the default string type, are
>> comparatively minor; on 'most every philosophical point, the two
>> dialects agree.
>
> Minor, yes, .... until you need to make something work--- only to be
> frustrated to find that a detail that was not expected has risen to bite a
> sensitive place... :)
I get far worse than those when I switch between languages and forget
operator precedence, or forget that function X has its parameters the
other way around, or whatever. They are minor, and if you're not 100%
familiar with the language you're writing in, you should probably have
its docs handy anyway.
The print function will bite you instantly, you'll know what's wrong
as soon as you try to run it. Unicode strings, too, will usually throw
a nice tidy exception. The only one that's going to really sting you
is division, and it's so easy to deal with that one as you code
(always use // for flooring).
> instance, how do we reload a module in 2.x... with, um, reload. This has
> always been the way... every book says so, and every one of us has
> re-invoked a .py file by using relaod. Reload doesn't even work on 3.x
> without an import.
>From what I gather, Python simply isn't designed with that sort of
"live reload" in mind. Just terminate it and start over, it's easier.
If you want a system where you reload parts of it without bringing
things down, either build it manually (loading another piece of code,
and maybe reassigning some state variables that have your functions),
or pick a different language - Pike does this excellently. That's not
an indictment of Python; it's simply that Python is not everything.
> Some of the posts here are referring to the two languages as partially
> incompatible.... reminds me of that line from Princess Bride... "... he's
> not dead, hes only mostly dead!... and mostly dead is partly alive!" To say
> that 3.x is partly compatible with 2.x is silly, but to say that 3.x
> 'thinks' the same way as 2.x is almost pythonesque... I almost like that...
Mostly compatible is still partly incompatible? Sure. But "mostly
compatible" is Python 2.6.6 and Python 2.7.1, too. It's easy to write
one codebase that runs under multiple Python versions; certainly it's
a lot easier than writing one source file that's both Python and C,
for instance. And the same lines of code will be doing the same work
(unlike most polyglottisms, where one language's code is another
language's comments). There is a subset of Python 2 that is also a
subset of Python 3, and this intersection is quite large.
Chris Angelico
harrismh777
> A straw man is not when somebody points out holes in your argument, or
> unwanted implications that you didn't realise were there. It is when
> somebody makes claims on your behalf that you did not make to discredit
> you, not because you don't understand the implications of your own
> argument.
The straw-man fallacy is when you erect a "straw man" to "represent" the
actual man (or idea) which can be easily knocked down, and then you
proceed to knock it down (the straw-man) as though the "straw man" was
the actual man, or idea... proving your point as-it-were against your
opponent when in fact you have only just knocked down the straw-man...
leaving the real man standing.
This fallacy has a couple of nuances (sometimes combined with metaphor
or analogy fallacy) and you are a master at presenting both...
thankfully you usually don't try to present both at the same time! :)
In this present case the straw-man was not "me," rather the straw-man
was the python language itself. You chose a code-snippet (one small puny
dangle that doesn't prove a thing) and used it to speak for the entire
language! As though one code-block is enough to demonstrate
compatibility for the entire language in all of its nuances and details.
To prove something positive with a test case requires that you provide
*all* test cases, or that you provide an algorithm that accounts for
*all* test cases... you cannot prove compatibility with a code-snippet.
On the other hand, all you have to do to prove incompatibility is to
show "one" (1) test case where compatibility fails... and of course for
the present case there are many that can be shown, in fact, hundreds of
them.
The thing that nobody has presented here yet is that *all* the books
declare that 3.x is incompatible with 2.x/ ... some of them go out of
their way to tell the reader that they are only going to deal with 3.x
and not 2.x in any way... and others go out of their way to point out
the hundreds of nuances in details between the two languages. (and a
good thing too, for those of us who must work with both! ) So this fact
is not alluding the press... the point being not to bust anybody in the
chops, but to point out that it is not helpful to move the community
forward with a new language and get mass adoption (not just early
adopters) to lie about the differences between the two sets... yes, for
trivial code blocks that use prime constructs, integer math, and the
print statement, not much has changed. But in real world applications
of the language there are many hundreds of details that have changed or
been added (deleted) which will make life difficult for the uninitiated.
Don't mislead people by saying that very little has changed. Tell them
that the philosophy is the same (what Chris called python 'think' ) but
be honest about the details of syntax, environment, layout, and
morphology.
kind regards,
m harris
kind regards,
m harris
Dotan Cohen
> You have erected a straw-man... once again.
>
I think that is a red herring, not a strawman.
> Most 2.x code *will not* run correctly in 3.x/ Most of the best
> improvements and enhancements of 3.x will not back-port to below 2.7, and
> almost none of them will back-port before 2.6 (class decorations, for
> instance).
>
Although it is true that 2.x code will not run in a 3.x environment,
the changes to the code are minimal. This would be akin to saying that
a 2008 Peugeot 407 will not drive on a Canadian road because the
license plate is a different shape. Just go an put a different plastic
license plate holder on the Peugeot and it will run fine on the
Canadian road. The changes to bring Python 2 code into Python 3 code
are minimal, and it would be a terrific learning experience for the OP
to go back and revise his old code to do just that.
Furthermore, the OP is not just learning Python for the fun of
learning Python. If that were the case, then I would agree that Python
3 is the way to go. The OP needs to use imaging libraries which may
not yet work in Python 3 (I have not checked, but it is very likely
that they do not). Therefore Python 3 is a non-starter in any case.
--
Dotan Cohen
Ian Kelly
> In this present case the straw-man was not "me," rather the straw-man was
> the python language itself. You chose a code-snippet (one small puny dangle
> that doesn't prove a thing) and used it to speak for the entire language!
> As though one code-block is enough to demonstrate compatibility for the
> entire language in all of its nuances and details. To prove something
> positive with a test case requires that you provide *all* test cases, or
> that you provide an algorithm that accounts for *all* test cases... you
> cannot prove compatibility with a code-snippet.
You have just misrepresented Steven's argument, which is rather ironic
considering that you're the one who brought up straw-men. Steven did
not use one code snippet to demonstrate that Python 2 and Python 3 are
fully compatible. The code snippet merely demonstrated that Python 2
and 3 are not "totally incompatible" as you had claimed.
I realize you are now asserting that compatibility is a boolean
condition, and that "totally incompatible" is a redundant phrase that
you tossed out as a joke. I don't know whether you're sincere or
backpedaling, but in any case this assertion is flatly ludicrous.
Following your definition, *nothing* is compatible with anything else.
If you disagree, then I invite you to list one example of two
different things that are compatible.
And finally, would you please just knock off the fallacy crap? If you
assert something, and another person counters with a straw-man, and
you respond by dismissing his argument as a straw-man, your response
is valid. But if you assert something, and another person makes a
counter-argument, to whom you invariably respond by crying
"Straw-man!" or "False analogy!" (or in your case, "Analogy!"; you
seem to view all analogies as false) regardless of what that person
actually said -- even if that person does *sometimes* actually commit
those fallacies -- then you yourself are employing an ad hominem.
Steven D'Aprano
> Minor, yes, .... until you need to make something work--- only to be
> frustrated to find that a detail that was not expected has risen to bite
> a sensitive place... :)
Just like when migrating from Python 2.3 to 2.6. And 1.5 and 2.0, and 2.0
and 2.2, and 2.2 and 2.3.
> I am amazed at how many folks are not using 3.x/ Why? (beats me),
Because:
(1) the major operating systems either don't provide Python at all
(Windows), or are conservatively still using Python 2.6 or even
2.5 (Mac OS, most Linux distros);
(2) the Python website still recommends that "Python 2.x is the
status quo, Python 3.x is the shiny new thing"
<http://wiki.python.org/moin/Python2orPython3> ;
and
(3) the most of the big frameworks and libraries have either just
recently been upgraded to support 3.x, or haven't yet been
upgraded.
There's very little mystery about it. Migration to 3.x is going according
to plan. The majority aren't expected to migrate until probably 3.4 or
even 3.5.
> but how do I know they're not using it...? Because, if they were
> trying to use it with 2.x knowledge they would be complaining bloody
> murder.. for instance, how do we reload a module in 2.x... with, um,
> reload. This has always been the way... every book says so,
*Every* book? Even these?
http://diveintopython3.org/
http://www.qtrac.eu/py3book.html
http://www.mindviewinc.com/Books/Python3Patterns/Index.php
Please quote chapter and verse.
[...]
> PS Something nobody has pointed out yet is that "completely
> incompatible" is redundant.
That's because it is not redundant. There is a difference between 1%
compatible and 99% compatible and 100% incompatible.
> ... its like saying totally destroyed. I
> was trying to be funny, but nobody unpinned it... I'm disappointed.
>
> Some of the posts here are referring to the two languages as partially
> incompatible.... reminds me of that line from Princess Bride... "...
> he's not dead, hes only mostly dead!... and mostly dead is partly
> alive!" To say that 3.x is partly compatible with 2.x is silly,
What a ridiculous statement, and one which flies in the face of major
projects like numpy which support 2.x and 3.x out of a single code base.
I invite you to consider the difference between a legally dead person
moments before being resuscitated by a paramedic, versus a chicken that
has just been beheaded and is still running around the yard, versus a
million-year-old fossilized bone that has turned to stone. Who could
possibly justify saying that all three are equally dead?
Beware the tyranny of the discontinuous mind.
http://www.sciencemusings.com/2007/07/tyranny-of-discontinuous-mind.html
Both life and compatibility are matters of degree, not binary states. For
proper operation, an electrical device might require a 6V 250mA
transformer, but it might work well enough with one that provides just 5V
and 240mA, provided you don't stress the device too much.
We often design our physical devices to force compatibility to be all-or-
nothing, e.g. you can't fit a USB plug into an audio jack, no matter how
you try. But that's enforced by the design, not because compatibility is
inherently true/false. Compatibility is inherently continuous, a matter
of degree.
This is especially true when it comes to languages, both natural and
programming. British English and American English are perhaps 99.5%
compatible, but "table a motion" means completely opposite things in
British and American English. (In Britain, it means to deal with it
immediately; in the USA, it means to postpone it.) Should we conclude
from this that British and American English are "different languages" and
"completely incompatible"?
The differences between Python 2 and 3 are less than those between
American and British English. To describe them as "different languages",
as if going from Python 2 to 3 was like translating English to Italian,
is absurd.
--
Steven
Jason Tackaberry
> I realize you are now asserting that compatibility is a boolean
> condition, and that "totally incompatible" is a redundant phrase that
> you tossed out as a joke.
As a casual lurker reading this thread, I believe he is equating
"completely incompatible" with "not completely compatible." At least,
his arguments make more sense if I read him as arguing from the "not
completely compatible" position. It's possible he is intentionally
equivocating for dramatic effect.
But they are different -- both connotatively and denotatively -- and to
argue against the claim that Python 2 and 3 are "completely
incompatible" it seems to me sufficient to provide a single non-trivial
counter-example, which Steven has already done.
Cheers,
Jason.
Chris Angelico
> Python 2.x and Pythin 3.x are two different dialects just like Humans
> (Python 3.x) and Chimpanzees (Python 2.x) are similar (compatible) but
> very different versions of talking apes (languages). Sure humans
> (Python 3.x) and chimps (Python 2.x) share some similarities (much
> more than say humans (Python3.x) and fish (Lisp) do) however there are
> many incompatible differences.
>
Chimpanzees do not use language in the same way that humans do, and in
any case, it's pretty ridiculous to talk of the 'Human language' in
anything other than a fantasy roleplaying game. It's more comparable
to call Py2 "scientific English"and Py3 "medical English". There are
differences (what's a calorie?), but for the most part, they are the
same language.
Chris Angelico
harrismh777
LOL
> I invite you to consider the difference between a legally dead person
> moments before being resuscitated by a paramedic,
( ... alive )
> versus a chicken that
> has just been beheaded and is still running around the yard,
( ... alive )
> versus a
> million-year-old fossilized bone that has turned to stone.
( ... mostly 'dead' )
> Who could
> possibly justify saying that all three are equally dead?
LOL ( the first two [ roflol ] are 'partly' alive... )
( the third is just mostly dead... )
>
> Beware the tyranny of the discontinuous mind.
>
Sic Semper Tyrannus !
> Compatibility is inherently continuous, a matter
> of degree.
Compatible by degrees is incompatible. Just 'how' incompatible
determines whether the factor(s) are utterly useless, or just difficult
to negotiate.
(uh, oh,... me suspects another analogy fallacy coming up... )
> This is especially true when it comes to languages, both natural and
> programming.
( Yup... analogy fallacy for Ænglisc speakers... )
> British English and American English are perhaps 99.5%
> compatible, but "table a motion" means completely opposite things in
> British and American English. (In Britain, it means to deal with it
> immediately; in the USA, it means to postpone it.) Should we conclude
> from this that British and American English are "different languages" and
> "completely incompatible"?
We Americans have not spoken 'English' in well over two hundred
years... :) roflol
However, I guarantee that if I'm dumped unaided in Piccadilly I'll
be able to hail a cab, pay my £12.00 and get myself to Liverpool Street
Station, find the bathroom, and be on the correct train just in time for
dinner, all without looking into the English dictionary.
On the other hand (playing along with this analogy fallacy) if I
dump a python newbie unaided in the middle of 2.5 and ask them to format
a simple polytonic Greek unicode string and output it with print to
stdout (redirected to a file) they will fail... maybe even if they have
a dictionary !
>
> The differences between Python 2 and 3 are less than those between
> American and British English.
absurd and unsubstantiated claim... quickly now call the bobbies,
call the bobbies !!!
To describe them as "different languages",
> as if going from Python 2 to 3 was like translating English to Italian,
> is absurd.
... no, um, its more like migrating ye old Ænglisc... (the Ænglisc
of say, "Beowulf" ) to modern English.... still assuming the English
analogy fallacy holds... which,... it doesn't...
Ever tried to read Beowulf in the original? Ever tried to write Ænglisc ?
kind regards,
m harris
harrismh777
> You have just misrepresented Steven's argument, which is rather ironic
> considering that you're the one who brought up straw-men. Steven did
> not use one code snippet to demonstrate that Python 2 and Python 3 are
> fully compatible. The code snippet merely demonstrated that Python 2
> and 3 are not "totally incompatible" as you had claimed.
Ian gets the Christmas turkey for pinning the irony on me fair 'n
square... 'demonstrating' the straw-man is intimately and infinitely
more delicious than just defining it... besides, the tables must be
turned me thinks... :)
>
> I realize you are now asserting that compatibility is a boolean
> condition, and that "totally incompatible" is a redundant phrase that
> you tossed out as a joke. I don't know whether you're sincere or
> backpedaling, but in any case this assertion is flatly ludicrous.
> Following your definition,*nothing* is compatible with anything else.
> If you disagree, then I invite you to list one example of two
> different things that are compatible.
one man, and one woman....
>
> And finally, . . . you
> seem to view all analogies as false) regardless of what that person
> actually said
... all analogies are argumentative fallacy. Now, the analogy event
(or ontological state of the analogy) may in fact be true... but that
event or state can *never* be used to assert truth in 'different event'
or fact of 'another state' as the 'same thing(s)'.
The truth or fallacy of an argument should never be asserted by the
use of an analogy regardless how well the analogy illustrates the point.
Some folks believe that a good illustration of a point can be used to
prove the point true (or false), when in fact the illustration (the
analogy event) is often nothing more than entertaining explanation
(Steven's are some of the best, I admit !)
-- even if that person does*sometimes* actually commit
> those fallacies -- then you yourself are employing an ad hominem.
... oh ho ho... lol yes... again... guilty as charged.
kind regards,
m harris
harrismh777
> At least,
> his arguments make more sense if I read him as arguing from the "not
> completely compatible" position. It's possible he is intentionally
> equivocating for dramatic effect.
yes
Rhodri James
wrote:
> Steven D'Aprano wrote:
>> Compatibility is inherently continuous, a matter
>> of degree.
>
> Compatible by degrees is incompatible. Just 'how' incompatible
> determines whether the factor(s) are utterly useless, or just difficult
> to negotiate.
>
> (uh, oh,... me suspects another analogy fallacy coming up... )
>
>> This is especially true when it comes to languages, both natural and
>> programming.
>
> ( Yup... analogy fallacy for Ænglisc speakers... )
I don't know about you, but I speak English not "Anglish". This is how an
aesc is pronounced, after all.
>> British English and American English are perhaps 99.5%
>> compatible, but "table a motion" means completely opposite things in
>> British and American English. (In Britain, it means to deal with it
>> immediately; in the USA, it means to postpone it.) Should we conclude
>> from this that British and American English are "different languages"
>> and
>> "completely incompatible"?
>
> We Americans have not spoken 'English' in well over two hundred
> years... :) roflol
Quite the contrary, in fact. Much American usage of English actually
better preserves the styles of eighteenth century English usage, having
managed to avoid some of the "corrections" of Victorian grammarians.
> However, I guarantee that if I'm dumped unaided in Piccadilly I'll
> be able to hail a cab, pay my £12.00 and get myself to Liverpool Street
> Station, find the bathroom, and be on the correct train just in time for
> dinner, all without looking into the English dictionary.
And I guarantee that you'd get odd looks for at least one of those. You
may not notice; we Brits are used to translating the large amount of US TV
we get back into British English.
> On the other hand (playing along with this analogy fallacy) if I
> dump a python newbie unaided in the middle of 2.5 and ask them to format
> a simple polytonic Greek unicode string and output it with print to
> stdout (redirected to a file) they will fail... maybe even if they have
> a dictionary !
Now this is an analogy fallacy, and an obvious one at that.
--
Rhodri James *-* Wildebeest Herder to the Masses
Ian Kelly
>> I realize you are now asserting that compatibility is a boolean
>> condition, and that "totally incompatible" is a redundant phrase that
>> you tossed out as a joke. I don't know whether you're sincere or
>> backpedaling, but in any case this assertion is flatly ludicrous.
>> Following your definition,*nothing* is compatible with anything else.
>> If you disagree, then I invite you to list one example of two
>> different things that are compatible.
>
> one man, and one woman....
Now you're equivocating. The discussion has been about whether Python
2 and Python 3 are compatible in the "interchangeable" sense, not in
the "capable of functioning together" sense.
Terry Reedy
> Ever tried to read Beowulf in the original? Ever tried to write Ænglisc ?
I have, and it is a lot further from modern American than Python 2 and 3
are from each other.
--
Terry Jan Reedy
Terry Reedy
>
> However, I guarantee that if I'm dumped unaided in Piccadilly I'll be
> able to hail a cab, pay my £12.00 and get myself to Liverpool Street
> Station, find the bathroom, and be on the correct train just in time for
> dinner, all without looking into the English dictionary.
Because natural language is redundant and most speakers are forgiving,
while computer language are stripped on much redundancy and their
interpreters tend to be unforgiving, so a single missing comma or space
can raise a SyntaxError. Python is designed to do so, and allow/require
correction, rather than guess and go on.
This is not so bad; what if the cabbie does not understand you but say
OK, guesses the destination, ignores any protestations, and asks for £30
at the wrong destination. Following people who deafly say OK and take
you whereever is a real hazard in some countries. Some tourist guides
even warn about the practice.
Anyway, 'L i v e r p o o l S t r e e t S t a t i o n' is such a
trivial utterance as to not be comparable to anything as complicated as
a typical 5-line function.
--
Terry Jan Reedy
Chris Angelico
> On Mon, May 30, 2011 at 6:43 PM, harrismh777 <harri...@charter.net> wrote:
>>> different things that are compatible.
>>
>> one man, and one woman....
>
> 2 and Python 3 are compatible in the "interchangeable" sense, not in
> the "capable of functioning together" sense.
Indeed. If a man has a scripting language, and a woman has a scripting
language, the two would differ because there are things each can do
that the other cannot. But there's a lot of things that both can do,
so the two languages would be highly similar in purpose and
functionality.
Hmm. If you did write those two scripting languages, we would finally
be able to type "man woman" to get docs on how to talk to women...
Chris Angelico
harrismh777
> Hmm. If you did write those two scripting languages, we would finally
> be able to type "man woman" to get docs on how to talk to women...
Which just wouldn't be fair, because her use of man man would lead
her no closer to understanding how men speak... (er, think, um... )
:)
>
Benjamin Kaplan
<wlf...@ix.netcom.com> wrote:
> On Mon, 30 May 2011 21:34:09 -0400, Terry Reedy <tjr...@udel.edu>
> declaimed the following in gmane.comp.python.general:
>
>> On 5/30/2011 8:32 PM, harrismh777 wrote:
>>
>>
>> are from each other.
>>
> Heck... Python 2 and 3 are modern vs Shakespearian English...
> Chaucer is closer to Python vs Ruby... Beowulf? Might as well be APL...
> --
No, Python 2 vs 3 is more of American English vs British English.
People who speak one of them work under the philosophy that "if y'all
would just speak English we wouldn't have these problems"
Ben Finney
> Well... He did say "find the bathroom", not ask for directions to
> whatever euphemism is in current usage (water closet, W/C, loo ?)
The room which contains the bath is the bathroom.
Assuming that the toilet is in the same room as the bath is parochial.
If he wants the toilet, “bathroom” is a euphemism, and he should instead
ask for directions to the toilet.
--
\ “When we talk to God, we're praying. When God talks to us, |
`\ we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 |
_o__) |
Ben Finney
MRAB
> Dennis Lee Bieber<wlf...@ix.netcom.com> writes:
>
>> Well... He did say "find the bathroom", not ask for directions to
>> whatever euphemism is in current usage (water closet, W/C, loo ?)
>
> The room which contains the bath is the bathroom.
>
> Assuming that the toilet is in the same room as the bath is parochial.
>
> If he wants the toilet, “bathroom” is a euphemism, and he should instead
> ask for directions to the toilet.
>
Dotan Cohen
> different things that are compatible.
>
Men and women.
MS Office and Open Office.
IE6 and HTML.
Ian Kelly
>> If you disagree, then I invite you to list one example of two
>> different things that are compatible.
>>
>
> Men and women.
This is a slightly different sense of the word compatible than we have
been discussing: able to work together to perform a function, not
interchangeable.
> MS Office and Open Office.
Nope. Remember, the assertion by harrismh777 was that "all you have
to do to prove incompatibility is to show 'one' (1) test case where
compatibility fails". As one example, any Calc document that uses the
EASTERSUNDAY function will fail in Excel, since Excel does not provide
it. I could easily come up with other examples (let's not even get
into the differences in macros), but one is all I need.
> IE6 and HTML.
:-)
Dotan Cohen
> On Tue, May 31, 2011 at 11:56 AM, Dotan Cohen <dotan...@gmail.com> wrote:
>>> If you disagree, then I invite you to list one example of two
>>> different things that are compatible.
>>>
>>
>> Men and women.
>
> This is a slightly different sense of the word compatible than we have
> been discussing: able to work together to perform a function, not
> interchangeable.
>
>> MS Office and Open Office.
>
> to do to prove incompatibility is to show 'one' (1) test case where
> EASTERSUNDAY function will fail in Excel, since Excel does not provide
> it. I could easily come up with other examples (let's not even get
> into the differences in macros), but one is all I need.
>
>> IE6 and HTML.
>
> :-)
>
Ian, I'm surprised, you of all people might have noticed that my
sarcasm was intended to point out exactly that no two things are
compatible, least of all those things designed with compatibility as a
design spec!