Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68581 > unrolled thread

running python 2 vs 3

Back to article view | Back to comp.lang.python

Contents

  running python 2 vs 3 notbob <notbob@nothome.com> - 2014-03-20 14:58 +0000
    Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 17:21 +0200
      Re: running python 2 vs 3 notbob <notbob@nothome.com> - 2014-03-20 16:00 +0000
        Re: running python 2 vs 3 Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-03-20 11:14 -0500
          Re: running python 2 vs 3 notbob <notbob@nothome.com> - 2014-03-20 17:10 +0000
            Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 04:30 +1100
            Re: running python 2 vs 3 Gary Herron <gary.herron@islandtraining.com> - 2014-03-20 10:45 -0700
            Re: running python 2 vs 3 John Gordon <gordon@panix.com> - 2014-03-20 19:07 +0000
              Re: running python 2 vs 3 Terry Reedy <tjreedy@udel.edu> - 2014-03-20 18:05 -0400
                Re: running python 2 vs 3 alex23 <wuwei23@gmail.com> - 2014-03-21 12:37 +1000
            Re: running python 2 vs 3 Michael Torrie <torriem@gmail.com> - 2014-03-20 15:44 -0600
      Re: running python 2 vs 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-20 18:56 +0000
      Re: running python 2 vs 3 Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-20 20:07 +0100
        Re: running python 2 vs 3 Ned Batchelder <ned@nedbatchelder.com> - 2014-03-20 16:26 -0400
          Re: running python 2 vs 3 notbob <notbob@nothome.com> - 2014-03-20 21:16 +0000
          Re: running python 2 vs 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-21 00:32 +0000
            Re: running python 2 vs 3 Ned Batchelder <ned@nedbatchelder.com> - 2014-03-20 21:06 -0400
              Re: running python 2 vs 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-21 03:16 +0000
                Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 14:34 +1100
            Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 12:10 +1100
            Re: running python 2 vs 3 Ned Batchelder <ned@nedbatchelder.com> - 2014-03-20 21:20 -0400
      Re: running python 2 vs 3 Alan Meyer <ameyer2@yahoo.com> - 2014-03-20 15:53 -0400
        Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 22:08 +0200
          Re: running python 2 vs 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-20 20:22 +0000
            Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 22:30 +0200
              Re: running python 2 vs 3 Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-03-20 15:43 -0500
              Re: running python 2 vs 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-20 20:44 +0000
                Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 22:50 +0200
                  Re: running python 2 vs 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-20 21:36 +0000
                  Re: running python 2 vs 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-21 00:59 +0000
                    Re: running python 2 vs 3 Roy Smith <roy@panix.com> - 2014-03-20 21:06 -0400
                      Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 13:18 +1100
                      Re: running python 2 vs 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-21 09:40 +0000
                        Re: running python 2 vs 3 alister <alister.nospam.ware@ntlworld.com> - 2014-03-21 12:09 +0000
                    Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 12:15 +1100
              Re: running python 2 vs 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-20 22:39 +0000
          Re: running python 2 vs 3 Ned Batchelder <ned@nedbatchelder.com> - 2014-03-20 16:27 -0400
            Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 22:42 +0200
              Re: running python 2 vs 3 Ned Batchelder <ned@nedbatchelder.com> - 2014-03-20 16:53 -0400
                Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 22:59 +0200
                  Re: running python 2 vs 3 Chris Kaynor <ckaynor@zindagigames.com> - 2014-03-20 14:18 -0700
                  Re: running python 2 vs 3 Ned Batchelder <ned@nedbatchelder.com> - 2014-03-20 17:31 -0400
                    Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-21 00:23 +0200
                      Re: running python 2 vs 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-20 22:42 +0000
                      Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 10:18 +1100
                        Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-21 07:49 +0200
                          Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 16:54 +1100
                            Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-21 08:08 +0200
                              Re: running python 2 vs 3 Rustom Mody <rustompmody@gmail.com> - 2014-03-20 23:51 -0700
                Re: running python 2 vs 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-21 00:37 +0000
                  Re: running python 2 vs 3 Ethan Furman <ethan@stoneleaf.us> - 2014-03-20 18:23 -0700
                Re: running python 2 vs 3 Rustom Mody <rustompmody@gmail.com> - 2014-03-20 19:20 -0700
          Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 10:04 +1100
        Re: running python 2 vs 3 Mark H Harris <harrismh777@gmail.com> - 2014-03-20 15:10 -0500
          Re: running python 2 vs 3 notbob <notbob@nothome.com> - 2014-03-20 21:28 +0000
            Re: running python 2 vs 3 Mark H Harris <harrismh777@gmail.com> - 2014-03-20 16:46 -0500
            Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-21 00:17 +0200
            Re: running python 2 vs 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-21 00:29 +0000
      Re: running python 2 vs 3 Dan Stromberg <drsalists@gmail.com> - 2014-03-20 13:38 -0700
        Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 22:46 +0200
    Re: running python 2 vs 3 Mark H Harris <harrismh777@gmail.com> - 2014-03-20 11:11 -0500
      Re: running python 2 vs 3 notbob <notbob@nothome.com> - 2014-03-20 17:23 +0000
        Re: running python 2 vs 3 Chris Angelico <rosuav@gmail.com> - 2014-03-21 04:29 +1100
          Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 19:45 +0200
        Re: running python 2 vs 3 Mark H Harris <harrismh777@gmail.com> - 2014-03-20 12:42 -0500
          Re: running python 2 vs 3 Marko Rauhamaa <marko@pacujo.net> - 2014-03-20 19:47 +0200
            Re: running python 2 vs 3 Ned Batchelder <ned@nedbatchelder.com> - 2014-03-20 14:45 -0400
            Re: running python 2 vs 3 Mark H Harris <harrismh777@gmail.com> - 2014-03-20 14:36 -0500
        Re: running python 2 vs 3 Terry Reedy <tjreedy@udel.edu> - 2014-03-20 17:52 -0400
          Re: running python 2 vs 3 notbob <notbob@nothome.com> - 2014-03-20 22:19 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#68623

[Multipart message — attachments visible in raw view] — view raw

On Thu, Mar 20, 2014 at 1:59 PM, Marko Rauhamaa <marko@pacujo.net> wrote:

> Well, with proper care, I suppose the same code base could support perl
> as well. ;)
>

Go even farther; how about C, PHP, and bash? I'm sure if you tried, you
could mix in some Python as well.
http://en.wikipedia.org/wiki/Polyglot_(computing)

Chris

[toc] | [prev] | [next] | [standalone]

#68626

On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
> Ned Batchelder <ned@nedbatchelder.com>:
>
>> It's an extreme case, but the latest released version of coverage.py
>> supports Python 2.3 through 3.3 with one code base. To do it, there's
>> a compatibility layer (akin to six). Then you stay away from features
>> that aren't available on all versions. In a few places, you might need
>> to have version checks, and the code can get a little idiomatic to
>> continue to work.
>
> Well, with proper care, I suppose the same code base could support perl
> as well. ;)

I'm not sure how to take this comment.  I feel like you are mocking my 
choice.  I wanted to make coverage.py available to as broad an audience 
as possible, something that I think is worthwhile.  Yes, there was an 
engineering cost, but the tradeoff was worth it.

>
>
> Marko
>


-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#68635

Ned Batchelder <ned@nedbatchelder.com>:
> On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
>> Well, with proper care, I suppose the same code base could support perl
>> as well. ;)
>
> I'm not sure how to take this comment. I feel like you are mocking my
> choice. I wanted to make coverage.py available to as broad an audience
> as possible, something that I think is worthwhile. Yes, there was an
> engineering cost, but the tradeoff was worth it.

I can't judge if your particular choice was the right one. My only point
is that python2 and python3 are so far apart as to be regarded as
independent languages.


Marko

[toc] | [prev] | [next] | [standalone]

#68638

On 20/03/2014 22:23, Marko Rauhamaa wrote:
> Ned Batchelder <ned@nedbatchelder.com>:
>> On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
>>> Well, with proper care, I suppose the same code base could support perl
>>> as well. ;)
>>
>> I'm not sure how to take this comment. I feel like you are mocking my
>> choice. I wanted to make coverage.py available to as broad an audience
>> as possible, something that I think is worthwhile. Yes, there was an
>> engineering cost, but the tradeoff was worth it.
>
> I can't judge if your particular choice was the right one. My only point
> is that python2 and python3 are so far apart as to be regarded as
> independent languages.
>

And I still say this is complete nonsense.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#68641

On Fri, Mar 21, 2014 at 9:23 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ned Batchelder <ned@nedbatchelder.com>:
>> On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
>>> Well, with proper care, I suppose the same code base could support perl
>>> as well. ;)
>>
>> I'm not sure how to take this comment. I feel like you are mocking my
>> choice. I wanted to make coverage.py available to as broad an audience
>> as possible, something that I think is worthwhile. Yes, there was an
>> engineering cost, but the tradeoff was worth it.
>
> I can't judge if your particular choice was the right one. My only point
> is that python2 and python3 are so far apart as to be regarded as
> independent languages.

They're definitely not independent languages. The biggest change is
str/unicode->bytes/str, and you can get part of that in Python 2.6/2.7
with "from __future__ import unicode_literals". You may still run into
problems with some functions that expect str and won't take unicode
(or vice versa), but it's easy to make code that runs across both
versions that way. Then toss in "from __future__ import
print_function" and happily use the expanded features of print, or go
for the lowest common denominator:

print("some single string")

which works happily in all versions of Python.

I've written code that runs on 2.6+/3.2+. (Or maybe it's 3.1+;
whichever version Debian Squeeze ships with.) It's pretty easy. It's
certainly a lot easier than writing code that runs as either Pike or
C++, for instance. THOSE are independent languages. (And yes, I've
written that sort of code. Had a #define block up the top to handle
some naming differences, and then restricted myself to a *really*
narrow set of common operations. Was a neat way to prove correctness,
though.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#68675

Chris Angelico <rosuav@gmail.com>:

> go for the lowest common denominator:
>
> print("some single string")
>
> which works happily in all versions of Python.

Whenever I have used "print" in my code, it has been with a >>
redirection.


Marko

[toc] | [prev] | [next] | [standalone]

#68676

On Fri, Mar 21, 2014 at 4:49 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> go for the lowest common denominator:
>>
>> print("some single string")
>>
>> which works happily in all versions of Python.
>
> Whenever I have used "print" in my code, it has been with a >>
> redirection.

Then you're probably not using "sys.stdout.write" but some other file
object's write method.

Also, I find it highly unusual that you never use print in its most
basic and intended form.

ChrisA

[toc] | [prev] | [next] | [standalone]

#68678

Chris Angelico <rosuav@gmail.com>:

> Then you're probably not using "sys.stdout.write" but some other file
> object's write method.

Correct, sys.stderr.write would have been a more accurate choice.

> Also, I find it highly unusual that you never use print in its most
> basic and intended form.

Printing to the stdout (hardcoded) is a relatively rare need. Mostly,
I've used "print" for diagnostic messages, and whenever I've had to
create actual output, I've parameterized the target object.


Marko

[toc] | [prev] | [next] | [standalone]

#68679

On Friday, March 21, 2014 11:38:42 AM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :

> > Then you're probably not using "sys.stdout.write" but some other file
> > object's write method.

> Correct, sys.stderr.write would have been a more accurate choice.

> > Also, I find it highly unusual that you never use print in its most
> > basic and intended form.

> Printing to the stdout (hardcoded) is a relatively rare need. Mostly,
> I've used "print" for diagnostic messages, and whenever I've had to
> create actual output, I've parameterized the target object.

Hear Hear!
Ive no opinion on whether python 2 or 3 print is better.

However I believe that people trying to help noobs would be actually
more helpful if they indicated that using prints all over code is not kosher.

Then whats the use/sense of print?? Debugging...

[toc] | [prev] | [next] | [standalone]

#68649

On Thu, 20 Mar 2014 16:53:25 -0400, Ned Batchelder wrote:

> On 3/20/14 4:42 PM, Marko Rauhamaa wrote:
>> Ned Batchelder <ned@nedbatchelder.com>:
>>
>>> Plenty of people have adopted a dual-support strategy, with one code
>>> base that supports both Python 2 and Python 3. The six module can help
>>> a great deal with this.
>>
>> I wonder how easy the resulting code is to the eyes and how easy it is
>> for the casual maintainer to accidentally break the delicate balance.
>> In a word, I wouldn't go there. Stay with Python2 as long as you must
>> and then, migrate and leave it behind.
> 
> This is fine advice for applications, but tools, libraries, and
> frameworks may want to support more than one version at the same time.

+1

Actually, even applications may want to support multiple versions. If I 
have a Python script that does something, I might not want to tie it to 
one specific version. In principle there's not much difference between 
"this will run under Python 2.6 and 2.7" and "this will run under Python 
2.7 and 3.3". In practice, it's a little trickier to cross the 2/3 
barrier than the 2.6/2.7 barrier. But it is still quite achievable, with 
a little extra effort. 

But you know that even better than I -- I take my hat off to you for 
supporting all the way back to Python 2.3, that is far more dedicated 
than I am.

In my experience, such as it is, the hard part about writing code that 
works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions.


> It's an extreme case, but the latest released version of coverage.py
> supports Python 2.3 through 3.3 with one code base.  To do it, there's a
> compatibility layer (akin to six).  Then you stay away from features
> that aren't available on all versions.  In a few places, you might need
> to have version checks, and the code can get a little idiomatic to
> continue to work.
> 
> It's a tradeoff: you have to decide for yourself whether the effort is
> worth the benefit.  I was glad to be able to drop support for 2.3, 2.4,
> and 2.5, and now only support 2.6-3.4 in coverage.py.

Sounds like your experience agrees with mine.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#68662

On 03/20/2014 05:37 PM, Steven D'Aprano wrote:
>
> In my experience, such as it is, the hard part about writing code that
> works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions.

+1000!  (yes, that's factorial  ;)

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#68657

On Friday, March 21, 2014 2:23:25 AM UTC+5:30, Ned Batchelder wrote:
> On 3/20/14 4:42 PM, Marko Rauhamaa wrote:
> > Ned Batchelder :
> >> Plenty of people have adopted a dual-support strategy, with one code
> >> base that supports both Python 2 and Python 3. The six module can help
> >> a great deal with this.
> > I wonder how easy the resulting code is to the eyes and how easy it is
> > for the casual maintainer to accidentally break the delicate balance. In
> > a word, I wouldn't go there. Stay with Python2 as long as you must and
> > then, migrate and leave it behind.

> This is fine advice for applications, but tools, libraries, and 
> frameworks may want to support more than one version at the same time.

> It's an extreme case, but the latest released version of coverage.py 
> supports Python 2.3 through 3.3 with one code base.  To do it, there's a 
> compatibility layer (akin to six).  Then you stay away from features 
> that aren't available on all versions.  In a few places, you might need 
> to have version checks, and the code can get a little idiomatic to 
> continue to work.

> It's a tradeoff: you have to decide for yourself whether the effort is 
> worth the benefit.  I was glad to be able to drop support for 2.3, 2.4, 
> and 2.5, and now only support 2.6-3.4 in coverage.py.

Ned is talking to (and from) a lib-writer perspective
Marko is talking from noob perspective (which is what the OP looks like)

Good to choose our hats appropriately

[toc] | [prev] | [next] | [standalone]

#68639

On Fri, Mar 21, 2014 at 7:08 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Alan Meyer <ameyer2@yahoo.com>:
>
>> I presume it would still be a good idea to test both python
>> interpreters against any script that you didn't knowingly write with a
>> feature that will only work in one of the two python versions.
>>
>> If it works fine in both - and many will, then use:
>>
>>      #!/usr/bin/env python
>>
>> Only use the "python2" or "python3" versions if you really have a
>> reason to do so.
>>
>> Yes?  No?
>
> No. Even if you managed to do that, it would mean getting the worst of
> both worlds. The language dialects are too far apart. When you start
> your Python project, you decide between Python 2 and Python 3 and go all
> in.

They're not that far apart. It's not difficult to write code that runs
happily on both. However, it does mean you can't take advantage of
Python 3 features, so it's probably better to write for one or the
other, unless you specifically want wide distribution. For your own
projects, just put whichever you need.

ChrisA

[toc] | [prev] | [next] | [standalone]

#68607

On 3/20/14 2:53 PM, Alan Meyer wrote:
> #!/usr/bin/env python
>
> Only use the "python2" or "python3" versions if you really have a reason
> to do so.

It gets tricky for distribution (you need docs for your distros, imho) 
because #!/usr/bin/env python  means different things on different 
systems.

I actually have three major versions of python2 and 2 major versions of 
python3 on my primary system at this point. On my machine python2.6 is 
"python".  That is because that system shipped with 2.6 and many of the 
subsystem stuff depends on python2.6 /

When I call python2 that means python2.7.6 /

When I call python3 that means python3.3.4 /

I can also call python2.7, which is 2.7.2 /

You get the idea.   There is no one set rule, because there are many 
distros (gnu/linux) that use python at various versions, and they all us 
different setups.  Really , you need an install script to snoop out the 
configurables.

marcus

[toc] | [prev] | [next] | [standalone]

#68624

On 2014-03-20, Mark H Harris <harrismh777@gmail.com> wrote:

> When I call python2 that means python2.7.6 /
>
> When I call python3 that means python3.3.4 /
>
> I can also call python2.7, which is 2.7.2 /
>
> You get the idea.   There is no one set rule, because there are many 
> distros (gnu/linux) that use python at various versions, and they all us 
> different setups.  Really , you need an install script to snoop out the 
> configurables.

Weeping Chryst on the cross!!.  No wonder the latest O'Reilly book,
Learning Python, 5th ed, is 1600 pgs.  I coulda swore someone sed
python is easy.  ;)

nb   

[toc] | [prev] | [next] | [standalone]

#68628

On 3/20/14 4:28 PM, notbob wrote:
> No wonder the latest O'Reilly book, Learning Python, 5th ed,
is 1600 pgs.  I coulda swore someone sed python is easy.  ;)
> nb

Python is easy, but its not simple.
Python is elegant, and full of art, but it has no paucity of constructs, 
types, and opportunities for confusion.

My goal for designing SimplyPy (for instance)is to present the beautiful 
heart of python (as Mark Summerfield calls it) and subsume the 
complexities of the fulness of python within a simple interface, BUT 
without limiting it.

Python is easy enough to teach children (I've done it), but its 
"complete and elegant enough" for the most scientific of professionals.

You do not need to know the fulness of python in order to use it. It is 
possible (even elegant) to use python (in a Rexx style) not at all 
recognized as "pythonized" code, and yet very very simple and powerful.

The beauty of python, in my view, is the flexibility and extensibility 
of the namespace with something more than the minimalist approach of 
Lisp, BUT with the elegance of the language called python.

Get Mark Summerfield's Programming Python 3.  Its really quite good, and 
in my opinion better that the O'Reilly book, especially for new users.

Just an opinion of course.

marcus

[toc] | [prev] | [next] | [standalone]

#68632

notbob <notbob@nothome.com>:

> Weeping Chryst on the cross!!. No wonder the latest O'Reilly book,
> Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed
> python is easy. ;)

It's not that bad. There are two principal dialects: python2 and
python3. Take the oldest python version you have to support and write
your code for that version.

Python documentation carefully explains what language and library
facilities are available in whichever version.


Marko

[toc] | [prev] | [next] | [standalone]

#68647

On Thu, 20 Mar 2014 21:28:43 +0000, notbob wrote:

> On 2014-03-20, Mark H Harris <harrismh777@gmail.com> wrote:
> 
>> When I call python2 that means python2.7.6 /
>>
>> When I call python3 that means python3.3.4 /
>>
>> I can also call python2.7, which is 2.7.2 /
>>
>> You get the idea.   There is no one set rule, because there are many
>> distros (gnu/linux) that use python at various versions, and they all
>> us different setups.  Really , you need an install script to snoop out
>> the configurables.
> 
> Weeping Chryst on the cross!!.  No wonder the latest O'Reilly book,
> Learning Python, 5th ed, is 1600 pgs.  I coulda swore someone sed python
> is easy.  ;)


This has nothing to do with Python. It has to do with the way executables 
(applications) are mapped to file names on Unix and Unix-like systems. 
And that in turn is not terribly different from the way that it works on 
Windows as well.

When you type "python" at the command prompt, your system locates an 
executable named "python", then runs it. If you wanted to be annoying, 
you could alias or link the python name to a completely different 
language. Or use a different name altogether:

steve@orac:~$ alias snake=python
steve@orac:~$ snake
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.


This has nothing to do with Python, it's the way Linux works.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#68614

On Thu, Mar 20, 2014 at 8:21 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> notbob <notbob@nothome.com>:
>
>> I've installed python 3.3 on my Slack box, which by default comes with
>> python 2.7. I know how to fire up the different IDLE environments, but
>> how do I differentiate between the scripts? IOW, up till now, I've
>> used .py on all my 2.7 files. How do I know not to run a .py in
>> python3 or visa versa? Or do I? What's the excepted convention for
>> differentiating between the two?
>
> That's a bit of a sore spot.
>
> On a linux box, the initial line of the script indicates the
> interpreter:
>
>    #!/usr/bin/env python2
>
> for Python 2.x
>
>    #!/usr/bin/env python3
>
> for Python 3.x.
>
> All tutorials will tell you to start it with
>
>    #!/usr/bin/env python

Actually, I formerly used /usr/bin/env, but have recently (within the
last couple of years) stopped.

This is because the env trick doesn't play nicely with top IME.  Also,
it's a trick.

[toc] | [prev] | [next] | [standalone]

#68618

Dan Stromberg <drsalists@gmail.com>:

> Actually, I formerly used /usr/bin/env, but have recently (within the
> last couple of years) stopped.
>
> This is because the env trick doesn't play nicely with top IME. Also,
> it's a trick.

I'm not sure I like it either, but it's a standard idiom in Pythonland.


Marko

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web