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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#68655

On 3/20/14 9:06 PM, Ned Batchelder wrote:
> On 3/20/14 8:32 PM, Steven D'Aprano wrote:
>> On Thu, 20 Mar 2014 16:26:39 -0400, Ned Batchelder wrote:
>>
>>> On 3/20/14 3:07 PM, Eric Jacoboni wrote:
>>>> Le 20/03/2014 16:21, Marko Rauhamaa a écrit :
>>>>
>>>>
>>>>> All tutorials will tell you to start it with
>>>>>
>>>>>      #!/usr/bin/env python
>>>>>
>>>>> which will start python2 on all (?) existing linux distros, but is
>>>>> expected to start python3 within the next decade.
>>>>
>>>> With Arch-Linux, python is python3...
>>>>
>>>>
>>> Yes, and they have been told many times that this was foolish and wrong,
>>> but it persists, much to our pain.
>>
>> How bizarre. I've been looking forward with great pleasure to Fedora
>> moving to Python 3 as the standard system Python, expecting that this
>> move from one of the big distros will start a chain reaction of others
>> doing the same thing. Perhaps Arch-Linux is guilty of being prematurely
>> Python 3, a little like those people hauled up to explain themselves to
>> the House Unamerican Activities Committee to explain why they were a
>> "premature anti-fascist".
>>
>
> My understanding is that Fedora's move will not include making the word
> "python" mean Python 3.  Their move means that Python 3 will be
> installed by default, and that their Python programs that are part of
> the distro will be Python 3 programs.  They can still refer to it as
> "python3".

 From http://fedoraproject.org/wiki/Changes/Python_3_as_Default :

    Users shouldn't notice any changes, ... /usr/bin/python will still
    point to Python 2 and depending on result of discussions with FPC,
    "yum install python-foo" will still install Python 2 version of
    the package.




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

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

#68602

On 3/20/2014 11:21 AM, Marko Rauhamaa wrote:

> 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
>
> which will start python2 on all (?) existing linux distros, but is
> expected to start python3 within the next decade.
>
>
> Marko

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?

    Alan

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

#68606

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.


Marko

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

#68609

On 20/03/2014 20:08, Marko Rauhamaa 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.
>
> Marko
>

I do not agree that the dialects are too far apart, not that it really 
matters.  There are several libraries available to enable code to run 
under both versions.  The starter is 2to3 which had been in the standard 
library for what seems like an eternity to me.

-- 
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]

#68613

Mark Lawrence <breamoreboy@yahoo.co.uk>:

> The starter is 2to3 which had been in the standard library for what
> seems like an eternity to me.

No problem there. It helps you transition from python2 to python3.

However, python3 is here and you should be able to write genuine python3
code with the appropriate bytes and string facilities. It would be very
confusing to try to mix the two regimes.

I must say, though, that Python3 destroyed "print" forever for me. To
avoid nausea, I write sys.stdout.write() in all Python3 code.


Marko

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

#68616

On Thu, Mar 20, 2014 at 3:30 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> I must say, though, that Python3 destroyed "print" forever for me. To
> avoid nausea, I write sys.stdout.write() in all Python3 code.

To each their own :).  I can't stand using 'print' as a statement.
It's a very nice trick to be able to write a script, think "oh, all
those prints should really be sending that output somewhere else", and
then instead of changing every individual print, just define a
different 'print' function at the top of the file (which may be as
simple as `print = functools.partial(print, file=sys.stderr)` or
`print = logging.debug`).

-- 
Zach

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

#68617

On 20/03/2014 20:30, Marko Rauhamaa wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk>:
>
>> The starter is 2to3 which had been in the standard library for what
>> seems like an eternity to me.
>
> No problem there. It helps you transition from python2 to python3.
>
> However, python3 is here and you should be able to write genuine python3
> code with the appropriate bytes and string facilities. It would be very
> confusing to try to mix the two regimes.
>
> I must say, though, that Python3 destroyed "print" forever for me. To
> avoid nausea, I write sys.stdout.write() in all Python3 code.
>

Not for me, I was using from __future__ import print_function for years 
so got used to typing those two extra brackets, plus print very kindly 
inserts the newlines for me.

-- 
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]

#68619

Mark Lawrence <breamoreboy@yahoo.co.uk>:

> On 20/03/2014 20:30, Marko Rauhamaa wrote:
>> I must say, though, that Python3 destroyed "print" forever for me. To
>> avoid nausea, I write sys.stdout.write() in all Python3 code.
>
> Not for me, I was using from __future__ import print_function for
> years so got used to typing those two extra brackets, plus print very
> kindly inserts the newlines for me.

That very realization helped me wean myself from "print." Its sole
raison d'être is the insertion of the newline, which it would be nicer
to micromanage anyway; that's how it's done in other programming
languages as well: C, perl, guile, ... (Well, ok, "echo" is the
exception.)


Marko

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

#68627

On 20/03/2014 20:50, Marko Rauhamaa wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk>:
>
>> On 20/03/2014 20:30, Marko Rauhamaa wrote:
>>> I must say, though, that Python3 destroyed "print" forever for me. To
>>> avoid nausea, I write sys.stdout.write() in all Python3 code.
>>
>> Not for me, I was using from __future__ import print_function for
>> years so got used to typing those two extra brackets, plus print very
>> kindly inserts the newlines for me.
>
> That very realization helped me wean myself from "print." Its sole
> raison d'être is the insertion of the newline, which it would be nicer
> to micromanage anyway; that's how it's done in other programming
> languages as well: C, perl, guile, ... (Well, ok, "echo" is the
> exception.)
>
>
> Marko
>

The end keyword argument to the print function defaults to newline but 
you can make it anything you like, see 
http://docs.python.org/3/library/functions.html#print

-- 
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]

#68650

On Thu, 20 Mar 2014 22:50:45 +0200, Marko Rauhamaa wrote:

> Mark Lawrence <breamoreboy@yahoo.co.uk>:
> 
>> On 20/03/2014 20:30, Marko Rauhamaa wrote:
>>> I must say, though, that Python3 destroyed "print" forever for me. To
>>> avoid nausea, I write sys.stdout.write() in all Python3 code.
>>
>> Not for me, I was using from __future__ import print_function for years
>> so got used to typing those two extra brackets, plus print very kindly
>> inserts the newlines for me.
> 
> That very realization helped me wean myself from "print." Its sole
> raison d'être is the insertion of the newline, which it would be nicer
> to micromanage anyway; that's how it's done in other programming
> languages as well: C, perl, guile, ... (Well, ok, "echo" is the
> exception.)

echo is not "the" exception. *Many* languages handle the newline when 
printing: Pascal, Ruby, Io, Dylan, Haskell, Rebol, Tcl, Perl6, Java, 
Ocaml, ... either add a newline by default, or provide two functions for 
printing, one which adds newline and one which doesn't.

The rule of three applies here: anything you do in three different places 
ought to be managed by a function. Printing a newline at the end of a 
line of output is *incredibly* common. Any language which fails to 
provide a print-with-newline function is, frankly, sub-standard.



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

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

#68651

In article <532b8f0d$0$29994$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> The rule of three applies here: anything you do in three different places 
> ought to be managed by a function.

I prefer the rule of two :-)

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

#68661

On Fri, Mar 21, 2014 at 12:06 PM, Roy Smith <roy@panix.com> wrote:
> In article <532b8f0d$0$29994$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>> The rule of three applies here: anything you do in three different places
>> ought to be managed by a function.
>
> I prefer the rule of two :-)

The way I explain it is: Three is a rule of thumb. Sometimes it's
blatantly obvious at two, and other times you need four or five
similar pieces of code before you can see which part should become the
function. If the code's absolutely identical and reasonably
long/complex, then yes, two's all you need, but how often is that?
Usually it's similar, rather than congruent... err I mean identical.
That's where the third usage comes in. Or if it's maybe 2-3 lines,
used in two places, it doesn't necessarily need to be a function.
Again, a third usage is a strong hint that it should be broken out.

The rule doesn't say that anything that *isn't* in three places yet
should *not* be broken out. :)

ChrisA

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

#68681

On 21/03/2014 02:18, Chris Angelico wrote:
> On Fri, Mar 21, 2014 at 12:06 PM, Roy Smith <roy@panix.com> wrote:
>> In article <532b8f0d$0$29994$c3e8da3$5496439d@news.astraweb.com>,
>>   Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>>
>>> The rule of three applies here: anything you do in three different places
>>> ought to be managed by a function.
>>
>> I prefer the rule of two :-)
>
> The way I explain it is: Three is a rule of thumb. Sometimes it's
> blatantly obvious at two, and other times you need four or five
> similar pieces of code before you can see which part should become the
> function. If the code's absolutely identical and reasonably
> long/complex, then yes, two's all you need, but how often is that?
> Usually it's similar, rather than congruent... err I mean identical.
> That's where the third usage comes in. Or if it's maybe 2-3 lines,
> used in two places, it doesn't necessarily need to be a function.
> Again, a third usage is a strong hint that it should be broken out.
>
> The rule doesn't say that anything that *isn't* in three places yet
> should *not* be broken out. :)
>
> ChrisA
>

Everybody, and especially Antipodeans, knows that there is no rule 6 and 
by definition what rule 7 is :)

-- 
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]

#68685

On Fri, 21 Mar 2014 09:40:40 +0000, Mark Lawrence wrote:

> On 21/03/2014 02:18, Chris Angelico wrote:
>> On Fri, Mar 21, 2014 at 12:06 PM, Roy Smith <roy@panix.com> wrote:
>>> In article <532b8f0d$0$29994$c3e8da3$5496439d@news.astraweb.com>,
>>>   Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>>>
>>>> The rule of three applies here: anything you do in three different
>>>> places ought to be managed by a function.
>>>
>>> I prefer the rule of two :-)
>>
>> The way I explain it is: Three is a rule of thumb. Sometimes it's
>> blatantly obvious at two, and other times you need four or five similar
>> pieces of code before you can see which part should become the
>> function. If the code's absolutely identical and reasonably
>> long/complex, then yes, two's all you need, but how often is that?
>> Usually it's similar, rather than congruent... err I mean identical.
>> That's where the third usage comes in. Or if it's maybe 2-3 lines, used
>> in two places, it doesn't necessarily need to be a function. Again, a
>> third usage is a strong hint that it should be broken out.
>>
>> The rule doesn't say that anything that *isn't* in three places yet
>> should *not* be broken out. :)
>>
>> ChrisA
>>
>>
> Everybody, and especially Antipodeans, knows that there is no rule 6 and
> by definition what rule 7 is :)

Im sticking with rule 4

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

#68654

On Fri, Mar 21, 2014 at 11:59 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> The rule of three applies here: anything you do in three different places
> ought to be managed by a function. Printing a newline at the end of a
> line of output is *incredibly* common. Any language which fails to
> provide a print-with-newline function is, frankly, sub-standard.

I wouldn't go that far. There are plenty of languages where the
default (printf, write, werror, etc) doesn't add the newline, and I
wouldn't call the *language* sub-standard for that. But yes, it does
bug me now and then. I use my "say" function to produce one or more
lines of output in Gypsum, and it guarantees complete lines (because
the system works with lines, not streams of characters); and then if I
use the "werror" function to write to stderr, I have to remember to
add the newline. However, I think Py2's print statement has way too
many weirdnesses - the trailing comma (reminiscent of BASIC, where I
never liked it either), the whole "soft space" concept, etc. Py3's
print function, with the keyword end="", is a lot better, though still
a tad verbose. (I don't know of any solution to that.)

ChrisA

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

#68637

On Thu, 20 Mar 2014 22:30:57 +0200, Marko Rauhamaa wrote:

> To avoid nausea, I write sys.stdout.write() in all Python3 code.

Now that's funny.


I-know-I-shouldn't-respond-to-obvious-trolling-but-I-can't-help-myself-ly 
yrs,

-- 
Steven D'Aprano

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

#68612

On 3/20/14 4:08 PM, Marko Rauhamaa 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.

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.

>
>
> Marko
>


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

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

#68615

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.


Marko

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

#68620

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.

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.

>
>
> Marko
>


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

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

#68621

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. ;)


Marko

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

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

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

csiph-web