From: Stephen Hansen on
On 6/27/10 7:35 PM, John Bokma wrote:
> On top of that, I don't think it's that hard to make a small program
> that one associates with .py files which checks the first line and feeds
> the .py to the correct version of Python based on the information in the
> aformentioned first line.

http://effbot.org/zone/exemaker.htm does approximately that and has been
very useful for me.

--

... Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

From: Paul Rubin on
Terry Reedy <tjreedy(a)udel.edu> writes:
> Python3 is about finishing transitions. The last stage in a transition
> that replaces something old with something new is to remove the old,..

Main problem is that by the time Python3 has stopped being disruptive,
Python4 will be underway. Python3 is incompatible enough with Python2
to cause hassle and headaches, but not incompatible enough for the
benefits to be more than slight. So making more radical changes will
require undergong the transition and disruption twice. I think it would
have been better to just do it once.
From: geremy condra on
On Sun, Jun 27, 2010 at 10:35 PM, John Bokma <john(a)castleamber.com> wrote:

<snip>

>>>> Might as well spare yourself the trouble and install linux or *bsd. It's
>>>> probably easier.
>>>
>>> Ah, yeah, and then run all those Windows applications one requires on
>>> Wine...
>>
>> If you're bound to a platform, use it. My advice is just to get bound to
>> a platform that does what you need it to do, and in my experience it's
>> quite a bit easier to teach linux to do what you wanted windows to do
>> than the other way around.
>
> I've used several operating systems over many years and each OS has its
> own issues. I am currently using mostly Linux and it's far from the
> flawless OS some people seem to think it is. While it's true that some
> things are easier on OS A than on OS B changing your operating system
> because one (minor) thing "doesn't work" is often not an option.

Sure, linux has its flaws- but it does include a working shell OOTB, which
is what raised this question in the first place.

> On top of that, I don't think it's that hard to make a small program
> that one associates with .py files which checks the first line and feeds
> the .py to the correct version of Python based on the information in the
> aformentioned first line.

I could spend my time reinventing all kinds of wheels. I'm just not sure
why I'd want to.

> Another option (instead of installing a better shell) might be to make
> several VMs, each with their own Python version. Run subversion (or any
> other version control system) on your host, and you can test whatever
> you want.

Is this seriously your solution? Can you see why I would rather have a
working shell than have to automate test suites across a half dozen
VMs?

> There are plenty of people who are very happy with coding under an MS
> OS. I now and then miss those days :-).

Ok, and for those people things like cygwin exist. My point is just that it
is frequently easier to do an actual linux install.

Geremy Condra
From: Steven D'Aprano on
On Sun, 27 Jun 2010 16:03:40 -0700, Eric_Dexter(a)msn.com wrote:

> It should be easier to have a large number of python versions on one
> machine... I am realy fond of 2.5 so I am probily going to start
> compiling them or just include the python2.5 exe if I port stuff and
> settle it that way..

I have Python 1.5, 2.0, 2.4, 2.5, 2.6, 3.0, 3.1 and LikePython currently
installed on my system. Apart from having to use `make altinstall`
instead of `make install`, it was easy to install them all.

Of course, the only ones I *regularly* use are 2.5, 2.6 and 3.1, but it's
sometimes handy to go back to 1.5 and see just how far we've come.




--
Steven
From: Stephen Hansen on
On 6/27/10 7:55 PM, Paul Rubin wrote:
> Terry Reedy<tjreedy(a)udel.edu> writes:
>> Python3 is about finishing transitions. The last stage in a transition
>> that replaces something old with something new is to remove the old,..
>
> Main problem is that by the time Python3 has stopped being disruptive,
> Python4 will be underway. Python3 is incompatible enough with Python2
> to cause hassle and headaches, but not incompatible enough for the
> benefits to be more than slight. So making more radical changes will
> require undergong the transition and disruption twice. I think it would
> have been better to just do it once.

There's no reason to assume Python 4 will be anything like Python 3 was
that I'm aware of. In fact, I'd bet large bunches of money that it will
be backwards compatible and evolutionary: a major release doesn't -have-
to be extremely disruptive.

Considering a couple people on Py-dev seemed (IIRC!) to object to the
entire idea of a 2.10 from my lurking on the principle that its invalid
(even if a lot of software don't treat version numbers as decimals, but
just separate fields), it wouldn't surprise me that as we continue along
with set releases of Python, 3.9 will roll around and 4.0 will come
next, without it being some massive shift again. Not that it might not
bring fun and interesting new mind-reading capabilities, but I'm not
sure I see that there needs to be another Major Event. At least, not so
soon as 4.0.

--

... Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/