D'Arcy Cain <darcy%NetBSD.org@localhost> writes:
> On 12-03-02 12:22 PM, Greg Troxel wrote:
>> Sorry, I meant only 2.x.
>>
>> It seems that no one expects all 2.x code to just work with 3.x. But I
>> may be wrong on that too.
>
> Not entirely true. In fact, 2.7 has features and options to make
> the transition smoother. You can write your 2.7 code such that
> it runs under 3.x in many cases. They also have a 2to3 utility
> to automate deeper changes.
That confirms what I meant; the operation of replacing 2.x with 3.x,
(with arbitrary code that works under 2.x) is in general unsafe. I
didn't mean to say that I thought it failed in all cases, or that any
case where it didn't work was super hard to fix. Just that an example
of a problem would not necessarily be viewed as a 3.x bug (or a defect
in the 2.x program, where while it worked it was buggy according to the
language specification).
> In general though, I believe that developers have to choose between
> 2.x and 3.x for their basic development platform.
OK - that's what I thought.
So what does the python community recommend for naming? As I understand
it, in pkgsrc we have pythonX.Y for 2.Y and 3.Y, so users get build-time
binding to the python version (and, by extension, the installed
modules). Is it normal for ${PREFIX}/bin/python3 to refer to the
currently-installed version of 3.Y? And do they then want python2, to
accomodate simultaneous use of python 2.x code? Or unsuffixed python,
and if so to what should that point?
Is it the case that any program that works under 3.0 is expected to work
under 3.1 and 3.2, to the extent that if 3.2 is installed no significant
numbe of rational people would ever want 3.0 and 3.1? (That seems to be
true for perl 5.14 (vs 5.12 and 5.10) - that's sort of what I mean.)
(I really don't know the answers to these questions; my point in asking
is that maybe pkgsrc should be treating python differently than it does
now.)