8:42 a.m.
We're just now dealing with Python 2.6, but over on the radar is perhaps
one of the most incompatible upgrades to the language we've seen in
Python 3. I personally haven't tried it yet, but it /aims/ to be
incompatble, which is perhaps one of the most glaring signs a language
designer has lost it that I've seen.
http://docs.python.org/3.0/whatsnew/3.0.html
This isn't a huge problem to those who are only developing on the latest
Fedora, per-se (other than getting over the initial hump), but it's
pretty bad for someone who wants to keep a single codebase across EL 4
(Python 2.3) and up, which I think a lot of us do. That gets to be
darn impossible and we have to double our involvement with code because
we essentially have to maintain a differently-compatible fork for each
project.
(NOTE: this requires the viewpoint that not everyone care just about the
latest Fedora, which might be controversial... but to me, the latest
Fedora is what I'll run as my dev environment but not everyone can
upgrade -- and many folks are also running EL and EPEL deserves our full
support and consideration)
So, what of plans?
Are we looking at also carrying on with packaging 2.N indefinitely when
we do decide to carry 3, because as I know it, the code changes to make
something Python 3 compatible will be severe and that's a big item for
any release, and will probably result in some undiscovered bugs even
after the initial ports (if applied).
I haven't seen /anything/ regarding a compatibility mode for
/usr/bin/python, and I'd hate to have to develop a non-core library that
allows for functions that work the same way on both versions and use
that instead. That would be heinous.
Short of porting everything over to Ruby, oCaml, or
enterprise-Fortran.NET#4000, any ideas on planning for this?
--Michael
8:49 a.m.
We're just now dealing with Python 2.6, but over on the radar is perhaps
one of the most incompatible upgrades to the language we've seen in
Python 3. I personally haven't tried it yet, but it /aims/ to be
incompatble, which is perhaps one of the most glaring signs a language
designer has lost it that I've seen.
http://docs.python.org/3.0/whatsnew/3.0.html
This isn't a huge problem to those who are only developing on the latest
Fedora, per-se (other than getting over the initial hump), but it's
pretty bad for someone who wants to keep a single codebase across EL 4
(Python 2.3) and up, which I think a lot of us do. That gets to be
darn impossible and we have to double our involvement with code because
we essentially have to maintain a differently-compatible fork for each
project.
(NOTE: this requires the viewpoint that not everyone care just about the
latest Fedora, which might be controversial... but to me, the latest
Fedora is what I'll run as my dev environment but not everyone can
upgrade -- and many folks are also running EL and EPEL deserves our full
support and consideration)
So, what of plans?
Are we looking at also carrying on with packaging 2.N indefinitely when
we do decide to carry 3, because as I know it, the code changes to make
something Python 3 compatible will be severe and that's a big item for
any release, and will probably result in some undiscovered bugs even
after the initial ports (if applied).
I haven't seen /anything/ regarding a compatibility mode for
/usr/bin/python, and I'd hate to have to develop a non-core library that
allows for functions that work the same way on both versions and use
that instead. That would be heinous.
Short of porting everything over to Ruby, oCaml, or
enterprise-Fortran.NET#4000, any ideas on planning for this?
Well, this:
http://docs.python.org/3.0/library/2to3.html#to3-reference
should be helpful. The work being done on 2.6 now is an excellent first
step.
Other than that, I think we'll have to treat it like any other major
change, such as gcc-4.3, etc.
It's gonna hurt, and obviously we'll need a compat-python26, but I think
we'll be able to port things over, and have them either use Python3k or
compat- as needed. Not sure when we'd be completely cut over, but I'd
love to see 2.6 the default in F11, which I believe is the plan, and Py3k
in the not too distant future*, F12.
--Michael
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
* or maybe next Sunday A.D. :)
--
in your fear, speak only peace
in your fear, speak only love
-d. bowie
8:54 a.m.
Jon Ciesla wrote:
> We're just now dealing with Python 2.6, but over on the radar
is perhaps
> one of the most incompatible upgrades to the language we've seen in
> Python 3. I personally haven't tried it yet, but it /aims/ to be
> incompatble, which is perhaps one of the most glaring signs a language
> designer has lost it that I've seen.
>
> http://docs.python.org/3.0/whatsnew/3.0.html
>
> This isn't a huge problem to those who are only developing on the latest
> Fedora, per-se (other than getting over the initial hump), but it's
> pretty bad for someone who wants to keep a single codebase across EL 4
> (Python 2.3) and up, which I think a lot of us do. That gets to be
> darn impossible and we have to double our involvement with code because
> we essentially have to maintain a differently-compatible fork for each
> project.
>
> (NOTE: this requires the viewpoint that not everyone care just about the
> latest Fedora, which might be controversial... but to me, the latest
> Fedora is what I'll run as my dev environment but not everyone can
> upgrade -- and many folks are also running EL and EPEL deserves our full
> support and consideration)
>
> So, what of plans?
>
> Are we looking at also carrying on with packaging 2.N indefinitely when
> we do decide to carry 3, because as I know it, the code changes to make
> something Python 3 compatible will be severe and that's a big item for
> any release, and will probably result in some undiscovered bugs even
> after the initial ports (if applied).
>
> I haven't seen /anything/ regarding a compatibility mode for
> /usr/bin/python, and I'd hate to have to develop a non-core library that
> allows for functions that work the same way on both versions and use
> that instead. That would be heinous.
>
> Short of porting everything over to Ruby, oCaml, or
> enterprise-Fortran.NET#4000, any ideas on planning for this?
>
Well, this:
http://docs.python.org/3.0/library/2to3.html#to3-reference
should be helpful. The work being done on 2.6 now is an excellent first
step.
Other than that, I think we'll have to treat it like any other major
change, such as gcc-4.3, etc.
It's gonna hurt, and obviously we'll need a compat-python26, but I think
we'll be able to port things over, and have them either use Python3k or
compat- as needed. Not sure when we'd be completely cut over, but I'd
love to see 2.6 the default in F11, which I believe is the plan, and Py3k
in the not too distant future*, F12.
> --Michael
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
* or maybe next Sunday A.D. :)
You're suggesting running 2.3 at each build time? I hope we can trust
it that much and it knows how to automatically port all possibilities.
Otherwise we get into a fork situation. The initial switchover does
not concern me so much as a dual maintaince problem.
A new gcc didn't really require that I stop using print() in the source,
it was mostly a build thing, no?
--Michael
9:42 a.m.
Jon Ciesla wrote:
>> We're just now dealing with Python 2.6, but over on the radar is
>> perhaps
>> one of the most incompatible upgrades to the language we've seen in
>> Python 3. I personally haven't tried it yet, but it /aims/ to be
>> incompatble, which is perhaps one of the most glaring signs a language
>> designer has lost it that I've seen.
>>
>> http://docs.python.org/3.0/whatsnew/3.0.html
>>
>> This isn't a huge problem to those who are only developing on the
>> latest
>> Fedora, per-se (other than getting over the initial hump), but it's
>> pretty bad for someone who wants to keep a single codebase across EL 4
>> (Python 2.3) and up, which I think a lot of us do. That gets to be
>> darn impossible and we have to double our involvement with code because
>> we essentially have to maintain a differently-compatible fork for each
>> project.
>>
>> (NOTE: this requires the viewpoint that not everyone care just about
>> the
>> latest Fedora, which might be controversial... but to me, the latest
>> Fedora is what I'll run as my dev environment but not everyone can
>> upgrade -- and many folks are also running EL and EPEL deserves our
>> full
>> support and consideration)
>>
>> So, what of plans?
>>
>> Are we looking at also carrying on with packaging 2.N indefinitely when
>> we do decide to carry 3, because as I know it, the code changes to make
>> something Python 3 compatible will be severe and that's a big item for
>> any release, and will probably result in some undiscovered bugs even
>> after the initial ports (if applied).
>>
>> I haven't seen /anything/ regarding a compatibility mode for
>> /usr/bin/python, and I'd hate to have to develop a non-core library
>> that
>> allows for functions that work the same way on both versions and use
>> that instead. That would be heinous.
>>
>> Short of porting everything over to Ruby, oCaml, or
>> enterprise-Fortran.NET#4000, any ideas on planning for this?
>>
>
> Well, this:
>
> http://docs.python.org/3.0/library/2to3.html#to3-reference
>
> should be helpful. The work being done on 2.6 now is an excellent first
> step.
>
> Other than that, I think we'll have to treat it like any other major
> change, such as gcc-4.3, etc.
>
> It's gonna hurt, and obviously we'll need a compat-python26, but I think
> we'll be able to port things over, and have them either use Python3k or
> compat- as needed. Not sure when we'd be completely cut over, but I'd
> love to see 2.6 the default in F11, which I believe is the plan, and
> Py3k
> in the not too distant future*, F12.
>
>
>> --Michael
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>>
>
> * or maybe next Sunday A.D. :)
>
>
You're suggesting running 2.3 at each build time? I hope we can trust
it that much and it knows how to automatically port all possibilities.
No, I was suggesting that this be done manually by maintainers if
possible. Given that some maintainers would lack the time, I think it
would be beneficial to set up a bug for each package with Python code,
assign it to the maintainer, but have a tracking bug so that those
interesting in helping out can go through the packages and pick off all
the Py3k bugs.
Otherwise we get into a fork situation. The initial switchover
does
not concern me so much as a dual maintaince problem.
Again, we wouldn't be switching the whole distro en masse, simply
providing compat- and migrating as possible.
A new gcc didn't really require that I stop using print() in the
source,
it was mostly a build thing, no?
Correct. I'm thinking of this more like the patch_fuzz issue introduced
by the new version of rpm in F-10. I didn't have a copy of rawhide
around, so all my packages got the macro band-aid, and I'll be doubling
back to fix them in the next few weeks.
--Michael
--
in your fear, speak only peace
in your fear, speak only love
-d. bowie
8:56 a.m.
Here's the problem:
"""
Sometimes 2to3 will find a place in your source code that needs to be
changed, but 2to3 cannot fix automatically. In this case, 2to3 will
print a warning beneath the diff for a file. You should address the
warning in order to have compliant 3.x code.
"""
So it means we can't dual maintain code easily between two
branches/versions.
Something to try out now, for sure, though, I'd think ... so we can
anticipate what may happen. Though trying this out without having
Python 3.X built versions of all the libraries any given app might need
to complete it's tests yet is going to be slightly fun.
--Michael
9:11 a.m.
On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
So it means we can't dual maintain code easily between two
branches/versions.
Isn't it the case that you can use 3.x features in 2.6, using the
'from future import ...' syntax?
http://www.python.org/dev/peps/pep-0236/
Rich.
9:19 a.m.
On Fri, Dec 05, 2008 at 03:11:34PM +0000, Richard W.M. Jones wrote:
On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
> So it means we can't dual maintain code easily between two
> branches/versions.
Isn't it the case that you can use 3.x features in 2.6, using the
'from future import ...' syntax?
Which isn't much help if python 2.3, 2.4 and 2.5 don't support
'from future import' and you care about shipping stuff that works
on the 99% of deployed Linux boxes today which don't have 2.6
let alone 3.0.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:39 a.m.
On Fri, December 5, 2008 8:19 am, Daniel P. Berrange wrote:
On Fri, Dec 05, 2008 at 03:11:34PM +0000, Richard W.M. Jones wrote:
> On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
> > So it means we can't dual maintain code easily between two
> > branches/versions.
>
> Isn't it the case that you can use 3.x features in 2.6, using the
> 'from future import ...' syntax?
Which isn't much help if python 2.3, 2.4 and 2.5 don't support
'from future import' and you care about shipping stuff that works
on the 99% of deployed Linux boxes today which don't have 2.6
let alone 3.0.
For heavens sake, the world is not falling.
If you don't want to use the new features, just don't use them.
12:40 p.m.
Stephen Warren wrote:
On Fri, December 5, 2008 8:19 am, Daniel P. Berrange wrote:
> Which isn't much help if python 2.3, 2.4 and 2.5 don't support
> 'from future import' and you care about shipping stuff that works
> on the 99% of deployed Linux boxes today which don't have 2.6
> let alone 3.0.
For heavens sake, the world is not falling.
If you don't want to use the new features, just don't use them.
The problem is that you have to use some of the new features to be valid
python3 code. So being compatible with python <=2.5 and python3.x+
will be painful at best and impossible at worst.
-Toshio
12:38 p.m.
Richard W.M. Jones wrote:
On Fri, Dec 05, 2008 at 09:56:39AM -0500, Michael DeHaan wrote:
> So it means we can't dual maintain code easily between two
> branches/versions.
Isn't it the case that you can use 3.x features in 2.6, using the
'from future import ...' syntax?
http://www.python.org/dev/peps/pep-0236/
Yes. This figures into our plans for migrating code within Fedora to
3.x. However, it doesn't address Michael's concerns about maintaining
code on python <= 2.5.
-Toshio
12:58 p.m.
On Fri, 2008-12-05 at 10:38 -0800, Toshio Kuratomi wrote:
Richard W.M. Jones wrote:
Yes. This figures into our plans for migrating code within Fedora to
3.x. However, it doesn't address Michael's concerns about maintaining
code on python <= 2.5.
-Toshio
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Short of a complete code audit, what would it take to identify what
packages need what degree of modifications?
For example, what if we ran 2to3 on a number of the "core" packages that
we consider to be essential to a Fedora system, and see how much really
needs to be done? This might be a nice reality check to see what the
situation really is.
I'm sure we'll find a lot of surprises, good & bad, if someone can
commit to doing it...
Maybe a great start would be on the packages that Ignacio et al (or is
it just him?) have already converted over to 2.6 compatibility...
9:14 a.m.
On Fri, 2008-12-05 at 08:49 -0600, Jon Ciesla wrote:
>
> We're just now dealing with Python 2.6, but over on the radar is perhaps
> one of the most incompatible upgrades to the language we've seen in
> Python 3. I personally haven't tried it yet, but it /aims/ to be
> incompatble, which is perhaps one of the most glaring signs a language
> designer has lost it that I've seen.
>
> http://docs.python.org/3.0/whatsnew/3.0.html
>
> This isn't a huge problem to those who are only developing on the latest
> Fedora, per-se (other than getting over the initial hump), but it's
> pretty bad for someone who wants to keep a single codebase across EL 4
> (Python 2.3) and up, which I think a lot of us do. That gets to be
> darn impossible and we have to double our involvement with code because
> we essentially have to maintain a differently-compatible fork for each
> project.
>
> (NOTE: this requires the viewpoint that not everyone care just about the
> latest Fedora, which might be controversial... but to me, the latest
> Fedora is what I'll run as my dev environment but not everyone can
> upgrade -- and many folks are also running EL and EPEL deserves our full
> support and consideration)
>
> So, what of plans?
There is no real plan atm.
> Are we looking at also carrying on with packaging 2.N
indefinitely when
> we do decide to carry 3, because as I know it, the code changes to make
> something Python 3 compatible will be severe and that's a big item for
> any release, and will probably result in some undiscovered bugs even
> after the initial ports (if applied).
>
> I haven't seen /anything/ regarding a compatibility mode for
> /usr/bin/python, and I'd hate to have to develop a non-core library that
> allows for functions that work the same way on both versions and use
> that instead. That would be heinous.
>
> Short of porting everything over to Ruby, oCaml, or
> enterprise-Fortran.NET#4000, any ideas on planning for this?
Well, this:
http://docs.python.org/3.0/library/2to3.html#to3-reference
should be helpful. The work being done on 2.6 now is an excellent first
step.
Other than that, I think we'll have to treat it like any other major
change, such as gcc-4.3, etc.
It's gonna hurt, and obviously we'll need a compat-python26, but I think
we'll be able to port things over, and have them either use Python3k or
compat- as needed.
It has been requested for us to do dual installs of python multiple
times now, and in each case it was voted down.
Because with GCC, we just have a second GCC, but with python we need a
second version of every module that uses it. Imagine if a second GCC
required a second version of every package that required a shared
library.
We also have _much less_ resources dedicated to python than we do GCC.
My guess is that if a second python is proposed for py3k, it'll get
voted down again.
Add onto that the fact that lots of python code is going to break in
3.0, and the fact that 3.0 seems utterly broken wrt. unicode, from bits
I've heard.
Then there's the fact that for the next 6-12 months people will want to
be developing things that still work with python-2.4.* (as that's what
is in RHEL-5/CentOS-5).
Not sure when we'd be completely cut over, but I'd
love to see 2.6 the default in F11, which I believe is the plan, and Py3k
in the not too distant future*, F12.
hahaha, I'll put money on python3k not being the default in Fedora 12.
Hell, I'll even put some money on it not being the default in Fedora 14,
at this point.
My personal opinion is that we stay with 2.6.* for as long as possible,
giving everyone time to dual port and the problems to be found/fixed and
then it "should be easy" to have it as a feature and move for one
release.
But I'll point out that Ignacio Vazquez-Abrams did _all_ the work for
2.6 in Fedora 11 ... so feel free to take this as just my opinion.
--
James Antill <james(a)fedoraproject.org>
Fedora
2:21 p.m.
James Antill wrote:
We also have _much less_ resources dedicated to python than we do
GCC.
My guess is that if a second python is proposed for py3k, it'll get
voted down again.
I think migrating without shipping parallel versions of Python at any point
is a completely unrealistic dream. Just look at how many packages still
depend on qt3 and kdelibs3, and how there are still packages depending on
gtk+-1.2 even when plans for GTK+ 3 are already ongoing. We have no reason
to believe Python will be any different.
Kevin Kofler
2:30 p.m.
Kevin Kofler (kevin.kofler(a)chello.at) said:
I think migrating without shipping parallel versions of Python at any
point
is a completely unrealistic dream. Just look at how many packages still
depend on qt3 and kdelibs3, and how there are still packages depending on
gtk+-1.2 even when plans for GTK+ 3 are already ongoing.
The packages that still depend on GTK1 are all effectively dead, IMO. At some
point, you have to cull the corpses.
Bill
2:39 p.m.
On Fri, Dec 5, 2008 at 3:30 PM, Bill Nottingham <notting(a)redhat.com> wrote:
Kevin Kofler (kevin.kofler(a)chello.at) said:
> I think migrating without shipping parallel versions of Python at any point
> is a completely unrealistic dream. Just look at how many packages still
> depend on qt3 and kdelibs3, and how there are still packages depending on
> gtk+-1.2 even when plans for GTK+ 3 are already ongoing.
The packages that still depend on GTK1 are all effectively dead, IMO. At some
point, you have to cull the corpses.
Also, GTK+ 3 is not likely anytime soon, and by soon I mean anytime
before the next 5 years. The discussions so far have a similar
motiviation as Python 3000; effectively a housecleaning without any
really compelling reason to jump.
4:01 p.m.
On Fri, 2008-12-05 at 21:21 +0100, Kevin Kofler wrote:
James Antill wrote:
> We also have _much less_ resources dedicated to python than we do GCC.
> My guess is that if a second python is proposed for py3k, it'll get
> voted down again.
I think migrating without shipping parallel versions of Python at any point
is a completely unrealistic dream.
And yet everyone who's been involved in trying to do that says it's a
giant mess, which they have no wish to repeat. And it has been voted
down when we had only a single significant application that needed an
old version, which would be _much easier_ to manage than your vision of
the future where random amounts of applications have migrated and random
amounts haven't.
Of course, you could be right ... I would just not bet on that
happening.
Just look at how many packages still
depend on qt3 and kdelibs3, and how there are still packages depending on
gtk+-1.2 even when plans for GTK+ 3 are already ongoing. We have no reason
to believe Python will be any different.
My hope is that as future iterations of both the 2.* and 3.* versions
come out (and the applications using them), the porting burden dwindles
to something "easy enough" for a flag day.
And as I said before, my current guess is that it'll be much more like
Apache-httpd's 2.* migration and thus. RHEL-7 (yes, seven) will have a
single python that is from the 2.* version stream.
Yes, py3k was released yesterday. No, that doesn't mean we need to move
to it by next week, month or year.
Also as has been said before, a lot of the timeline depends on the
various upstreams ... we may be forced to make certain less desirable
choices depending on what happens.
--
James Antill <james(a)fedoraproject.org>
Fedora
12:37 p.m.
Jon Ciesla wrote:
It's gonna hurt, and obviously we'll need a compat-python26,
but I think
we'll be able to port things over, and have them either use Python3k or
compat- as needed. Not sure when we'd be completely cut over, but I'd
love to see 2.6 the default in F11, which I believe is the plan, and Py3k
in the not too distant future*, F12.
We're going to avoid compat-python26 if possible. The reason is that
third party modules are needed to make a program work. So we wouldn't
just have a python26 package.... we'd have python26, python26-mozilla,
python26-libxml2, python26-pygtk, and etc.
-Toshio
12:46 p.m.
Jon Ciesla wrote:
> It's gonna hurt, and obviously we'll need a compat-python26, but I think
> we'll be able to port things over, and have them either use Python3k or
> compat- as needed. Not sure when we'd be completely cut over, but I'd
> love to see 2.6 the default in F11, which I believe is the plan, and
> Py3k
> in the not too distant future*, F12.
>
We're going to avoid compat-python26 if possible. The reason is that
third party modules are needed to make a program work. So we wouldn't
just have a python26 package.... we'd have python26, python26-mozilla,
python26-libxml2, python26-pygtk, and etc.
I have to do this at work for 2.3, 2.4 and 2.5. It SUCKS. So I agree,
let's not. :)
-Toshio
--
in your fear, speak only peace
in your fear, speak only love
-d. bowie
8:51 a.m.
On 2008-12-05, 14:42 GMT, Michael DeHaan wrote:
I personally haven't tried it yet, but it /aims/ to be
incompatble, which is perhaps one of the most glaring signs
a language designer has lost it that I've seen.
Guido was preparing on this incompatibility for years, so unless
you were sleeping you should not be surprised.
but it's pretty bad for someone who wants to keep a single
codebase across EL 4 (Python 2.3) and up, which I think a lot
of us do.
The party line is that you should develop against python 2.6
(which doesn't block you from being compatible with Python 2.3)
and then conversion from 2.6 to 3.* would be guaranteed to be
done just with a script.
Matěj
9:14 a.m.
On Friday 05 December 2008 14:51:24 Matej Cepl wrote:
On 2008-12-05, 14:42 GMT, Michael DeHaan wrote:
> I personally haven't tried it yet, but it /aims/ to be
> incompatble, which is perhaps one of the most glaring signs
> a language designer has lost it that I've seen.
Guido was preparing on this incompatibility for years, so unless
you were sleeping you should not be surprised.
For more than 9 years and it intends to fix some inconsistencies that had
grown with the language for more than 18 years (python was initially released
in 1989).
The plan was well laid there are plans to ease the upgrade.
If you (Michael) wish we can consider in a sense that python 2 and python are
two different (although closed related) languages.
--
José Abílio
12:51 p.m.
Matej Cepl wrote:
The party line is that you should develop against python 2.6
(which doesn't block you from being compatible with Python 2.3)
and then conversion from 2.6 to 3.* would be guaranteed to be
done just with a script.
The guarantee that 2to3 will convert your code does not exist.
Additionally to be more compatible with 3.x syntax, you have to enable
3.x features in python-2.6. Use of those features will make your code
incompatible with python <= 2.5.
So you either have 2.x compatible code or 3.x compatible code not both
(even including the script).
-Toshio
12:58 p.m.
2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
Matej Cepl wrote:
>
> The party line is that you should develop against python 2.6
> (which doesn't block you from being compatible with Python 2.3)
> and then conversion from 2.6 to 3.* would be guaranteed to be
> done just with a script.
>
The guarantee that 2to3 will convert your code does not exist.
Additionally to be more compatible with 3.x syntax, you have to enable
3.x features in python-2.6. Use of those features will make your code
incompatible with python <= 2.5.
So you either have 2.x compatible code or 3.x compatible code not both
(even including the script).
-Toshio
Is there not a subset of features which exist in both 2.5 and 3.0
which can be used in 2.6?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
1:25 p.m.
Arthur Pemberton wrote:
Is there not a subset of features which exist in both 2.5 and 3.0
which can be used in 2.6?
Trivial code can work but I wouldn't bet on any applications (with all
their library dependencies) being able to work in both 2.5 and 3.0.
Some things are a lot of work: you can't easily deal with methods in the
stdlib changing between 2.x and 3.x except to write your own version or
either the 3.x or 2.x version.
Other things are changed at a deep level. For instance, str and unicode
in python2.x has become bytes and str(an abstract unicode type) in
python3.x. Even with the 3.x compat mode in python 2.6 there's things
that have subtle bugs. Attempting to write code compatible with both
2.5 and 3.0 will fail miserably.
-Toshio
1:33 p.m.
2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
Arthur Pemberton wrote:
>
> Is there not a subset of features which exist in both 2.5 and 3.0
> which can be used in 2.6?
>
Trivial code can work but I wouldn't bet on any applications (with all
their library dependencies) being able to work in both 2.5 and 3.0.
Some things are a lot of work: you can't easily deal with methods in the
stdlib changing between 2.x and 3.x except to write your own version or
either the 3.x or 2.x version.
I'm sorry, I thought we were only discussing this in reference to
apps/tools that are directly under Fedora's control. And that
everything purely 3rd party would be built against 2.6 or 3.0 as
deemed by upstream. If this is not the case, then I better understand
the depth of the problem.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
2:36 p.m.
Arthur Pemberton wrote:
>> Is there not a subset of features which exist in both 2.5 and 3.0
>> which can be used in 2.6?
>>
> Trivial code can work but I wouldn't bet on any applications (with all
> their library dependencies) being able to work in both 2.5 and 3.0.
> Some things are a lot of work: you can't easily deal with methods in the
> stdlib changing between 2.x and 3.x except to write your own version or
> either the 3.x or 2.x version.
I'm sorry, I thought we were only discussing this in reference to
apps/tools that are directly under Fedora's control. And that
everything purely 3rd party would be built against 2.6 or 3.0 as
deemed by upstream. If this is not the case, then I better understand
the depth of the problem.
Is there a plan for how yum is going to upgrade itself?
--
Les Mikesell
lesmikesell(a)gmail.com
3:03 p.m.
Arthur Pemberton wrote:
>
>>> Is there not a subset of features which exist in both 2.5 and 3.0
>>> which can be used in 2.6?
>>>
>> Trivial code can work but I wouldn't bet on any applications (with all
>> their library dependencies) being able to work in both 2.5 and 3.0.
>> Some things are a lot of work: you can't easily deal with methods in
>> the
>> stdlib changing between 2.x and 3.x except to write your own version or
>> either the 3.x or 2.x version.
>
>
> I'm sorry, I thought we were only discussing this in reference to
> apps/tools that are directly under Fedora's control. And that
> everything purely 3rd party would be built against 2.6 or 3.0 as
> deemed by upstream. If this is not the case, then I better understand
> the depth of the problem.
Is there a plan for how yum is going to upgrade itself?
Should it not execute from the 2.6 version on disk and use rpm to alter
the copy on disk to use 3.0, so that the next run will use 3.0? It'll
require python 3.0, so it'll be in the same execution.
In short, shouldn't it work just like it does now?
--
Les Mikesell
lesmikesell(a)gmail.com
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
in your fear, speak only peace
in your fear, speak only love
-d. bowie
3:51 p.m.
Jon Ciesla wrote:
> Is there a plan for how yum is going to upgrade itself?
Should it not execute from the 2.6 version on disk and use rpm to alter
the copy on disk to use 3.0, so that the next run will use 3.0? It'll
require python 3.0, so it'll be in the same execution.
In short, shouldn't it work just like it does now?
Theoretically yes, but historically python's habit of incompatible
changes have caused problems especially when things were done in the
wrong order or a system was interrupted before the complete set was
installed and then couldn't fix itself.
--
Les Mikesell
lesmikesell(a)gmail.com
3:56 p.m.
On Fri, Dec 5, 2008 at 12:51 PM, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Theoretically yes, but historically python's habit of
incompatible changes
have caused problems especially when things were done in the wrong order or
a system was interrupted before the complete set was installed and then
couldn't fix itself.
interrupted rpm transactions can cause pretty much any sub system to
stop working. Feel free to dive into rpm development and create a fix
for that problem.
-jef
4:08 p.m.
Jeff Spaleta wrote:
On Fri, Dec 5, 2008 at 12:51 PM, Les Mikesell
<lesmikesell(a)gmail.com> wrote:
> Theoretically yes, but historically python's habit of incompatible changes
> have caused problems especially when things were done in the wrong order or
> a system was interrupted before the complete set was installed and then
> couldn't fix itself.
interrupted rpm transactions can cause pretty much any sub system to
stop working. Feel free to dive into rpm development and create a fix
for that problem.
I thought that was a separate problem (in a flurry in the FC2/FC3 era)
but similar in dealing with RPM swapping incompatible db libs underneath
itself. I recall for a while I defensively did a separate run of yum to
just update rpm and yum to minimize the chances of failure or mismatches
pulled from out-of-sync repos before starting a larger update. I
don't think there have been many problems recently, but it will still be
tricky to make the yum/python switch foolproof - especially if you don't
permit multiple versions of python to exist at once.
--
Les Mikesell
lesmikesell(a)gmail.com
5:07 p.m.
On Fri, Dec 5, 2008 at 1:08 PM, Les Mikesell <lesmikesell(a)gmail.com> wrote:
I thought that was a separate problem (in a flurry in the FC2/FC3
era) but
similar in dealing with RPM swapping incompatible db libs underneath itself.
Hey
your the one who brought it up. rpm transactions which abort in
the middle...are a general problem. There is nothing yum or python
specific about it. If an rpm transaction which updates python and all
that depends on that new python stops in the middle before completing
you have a problem. Just as you would have the same problem if the
transaction failed while updating any dependancy chain..including
rpms.
The answer right now is... don't let the rpm transaction stop in the middle.
I recall for a while I defensively did a separate run of yum to just
update
rpm and yum to minimize the chances of failure or mismatches pulled from
out-of-sync repos before starting a larger update. I don't think there have
been many problems recently, but it will still be tricky to make the
yum/python switch foolproof - especially if you don't permit multiple
versions of python to exist at once.
If you can't solve the general problem of fool proofing rpm
transactions..if rpm transactions can fail or be terminated in the
middle..without a way to come back and finish where they left
off...then no there is no way to foolproof an update..even an update
to rpm itself if an important library necessary for rpm operation was
in the transaction.
Do not let rpm transactions fail in the middle. Do not forcibly
terminate them...do not cut power to the system...hold your breath and
walk away from the console.
-jef
3:29 a.m.
On Fri, 2008-12-05 at 14:07 -0900, Jeff Spaleta wrote:
Do not let rpm transactions fail in the middle. Do not forcibly
terminate them...do not cut power to the system...hold your breath and
walk away from the console.
This was one of the problems PackageKit tries to solve. You can start an
install and do ctrl-alt-backspace and then re-login, and the transaction
is still running in the background. It also stops you shutting down
using a system and session inhibit if the transaction is an a
non-cancellable state.
If you /sbin/shutdown as root, or suffer a power failure without a UPS,
then all bets are off :-)
Richard.
1:31 p.m.
On Sat, Dec 6, 2008 at 12:29 AM, Richard Hughes <hughsient(a)gmail.com> wrote:
If you /sbin/shutdown as root, or suffer a power failure without a
UPS,
then all bets are off :-)
Can you prevent a transaction from starting if its a laptop on battery
power and the battery is expected to be "too low" for the transaction
to complete?
-jef
1:36 p.m.
On Sat, 2008-12-06 at 10:31 -0900, Jeff Spaleta wrote:
Can you prevent a transaction from starting if its a laptop on battery
power and the battery is expected to be "too low" for the transaction
to complete?
Well in that case, when the battery gets too low, you suspend. Upon
resume, the transaction will finish. (I've had this happen once)
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:36 p.m.
2008/12/6 Jesse Keating <jkeating(a)redhat.com>:
On Sat, 2008-12-06 at 10:31 -0900, Jeff Spaleta wrote:
>
>
> Can you prevent a transaction from starting if its a laptop on battery
> power and the battery is expected to be "too low" for the transaction
> to complete?
Well in that case, when the battery gets too low, you suspend. Upon
resume, the transaction will finish. (I've had this happen once)
suspend seems highly flaky, not sure if it is something to depend upon.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
4:09 p.m.
Arthur Pemberton wrote:
2008/12/6 Jesse Keating <jkeating(a)redhat.com>:
> On Sat, 2008-12-06 at 10:31 -0900, Jeff Spaleta wrote:
>>
>> Can you prevent a transaction from starting if its a laptop on battery
>> power and the battery is expected to be "too low" for the transaction
>> to complete?
> Well in that case, when the battery gets too low, you suspend. Upon
> resume, the transaction will finish. (I've had this happen once)
suspend seems highly flaky, not sure if it is something to depend upon.
Not sure it is something you want to copy, but I've had Mac laptops
refuse to start system updates because the battery was too low - and I
think even cell phones do that too.
--
Les Mikesell
lesmikesell(a)gmail.com
5:07 p.m.
Les Mikesell wrote:
Not sure it is something you want to copy, but I've had Mac
laptops
refuse to start system updates because the battery was too low - and I
think even cell phones do that too.
PackageKit (at least gnome-packagekit, it might not be implemented yet in
kpackagekit) won't check for updates at all if you're on battery.
Kevin Kofler
10:46 a.m.
Kevin Kofler wrote:
Les Mikesell wrote:
> Not sure it is something you want to copy, but I've had Mac laptops
> refuse to start system updates because the battery was too low - and I
> think even cell phones do that too.
PackageKit (at least gnome-packagekit, it might not be implemented yet in
kpackagekit) won't check for updates at all if you're on battery.
KPackageKit apparently does... at least, it did last night.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
-- from a story by Feech
2:15 p.m.
Matthew Woehlke wrote:
KPackageKit apparently does... at least, it did last night.
Then why didn't you file a bug?
Our default setup is NOT to do that, but KPackageKit sometimes forgets that
setting for whatever reason. It just did that for me too. It's clearly a
bug.
Kevin Kofler
2:42 p.m.
I wrote:
Matthew Woehlke wrote:
> KPackageKit apparently does... at least, it did last night.
Then why didn't you file a bug?
Our default setup is NOT to do that, but KPackageKit sometimes forgets
that setting for whatever reason. It just did that for me too. It's
clearly a bug.
I just filed https://bugzilla.redhat.com/show_bug.cgi?id=475303 . We will
try to figure out what's going wrong.
Kevin Kofler
2:55 p.m.
Kevin Kofler wrote:
Matthew Woehlke wrote:
> KPackageKit apparently does... at least, it did last night.
Then why didn't you file a bug?
Our default setup is NOT to do that, but KPackageKit sometimes forgets that
setting for whatever reason. It just did that for me too. It's clearly a
bug.
Because it's only "clearly a bug" to you? I don't particularly mind if
my computer wants to tell me there are updates when I'm running on
battery. If I wasn't reading this thread, I never would have thought
anything of it.
I don't object to treating it as a bug, it's just that this behavior
doesn't bother me :-).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
-- from a story by Feech
3:23 p.m.
Matthew Woehlke wrote:
Because it's only "clearly a bug" to you? I don't
particularly mind if
my computer wants to tell me there are updates when I'm running on
battery. If I wasn't reading this thread, I never would have thought
anything of it.
Oh, sorry, I lost track of the context. Reporting updates while on battery
isn't obviously a bug, automatically getting updates installed without
being asked (which somebody mentioned elsewhere on the lists, though I'm
not sure it was in reference to KPackageKit or to something else) is (and
that's what the bug I filed against KPackageKit is about). I'm sorry for
the confusion, it's me who got all mixed up.
Still, AFAIK gnome-packagekit doesn't check for updates while on battery and
it may well be that future kpackagekit releases won't do it either, at
least by default. But it is more a missing feature than a bug.
Kevin Kofler
4:01 p.m.
Kevin Kofler wrote:
Matthew Woehlke wrote:
> Because it's only "clearly a bug" to you? I don't particularly mind
if
> my computer wants to tell me there are updates when I'm running on
> battery. If I wasn't reading this thread, I never would have thought
> anything of it.
Oh, sorry, I lost track of the context. Reporting updates while on battery
isn't obviously a bug, automatically getting updates installed without
being asked (which somebody mentioned elsewhere on the lists, though I'm
not sure it was in reference to KPackageKit or to something else) is (and
that's what the bug I filed against KPackageKit is about). I'm sorry for
the confusion, it's me who got all mixed up.
Still, AFAIK gnome-packagekit doesn't check for updates while on battery and
it may well be that future kpackagekit releases won't do it either, at
least by default. But it is more a missing feature than a bug.
Ah, ok. Maybe I should actually go read the bug you filed, then I'd
realize we were miscommunicating :-). Sorry for the mix-up.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
-- from a story by Feech
12:57 a.m.
On Sat, 2008-12-06 at 09:29 +0000, Richard Hughes wrote:
On Fri, 2008-12-05 at 14:07 -0900, Jeff Spaleta wrote:
> Do not let rpm transactions fail in the middle. Do not forcibly
> terminate them...do not cut power to the system...hold your breath and
> walk away from the console.
This was one of the problems PackageKit tries to solve.
In it's usual way, of ignoring the real (but harder to solve) problems
and concentrating on a couple of very simple desktop cases and
implementing the most complicated solution possible ... and then
declaring the problem fixed, after minimal testing.
You can start an
install and do ctrl-alt-backspace and then re-login, and the transaction
is still running in the background.
rpm eats SIGHUP when in a transaction, so yum/rpm should do this too.
However rpm had a "feature" where it would abort if the stdout yum was
using went away, which was ... unexpected.
rpm in Fedora 10 fixed that (not sure which older releases), and
yum-3.2.20+ tries to work around it.
It also stops you shutting down
using a system and session inhibit if the transaction is an a
non-cancellable state.
Which isn't really helpful, esp. as the messages I've seen say
something like "Some program is stopping you from doing this" ... pretty
much guaranteeing the next words out of the users mouth will be "die
when I tell you too, scum sucking laptop, die; die; die!".
If you /sbin/shutdown as root, or suffer a power failure without a
UPS,
then all bets are off :-)
Or press the power button, or rpm gets OOMed, etc. etc.
Which is to say it works about as well as yum itself.
--
James Antill <james(a)fedoraproject.org>
Fedora
2:55 a.m.
On Sun, 2008-12-07 at 01:57 -0500, James Antill wrote:
> This was one of the problems PackageKit tries to solve.
In it's usual way, of ignoring the real (but harder to solve) problems
and concentrating on a couple of very simple desktop cases and
implementing the most complicated solution possible ... and then
declaring the problem fixed, after minimal testing.
Excuse me? Could you care to explain please?
> It also stops you shutting down
> using a system and session inhibit if the transaction is an a
> non-cancellable state.
Which isn't really helpful, esp. as the messages I've seen say
something like "Some program is stopping you from doing this" ... pretty
much guaranteeing the next words out of the users mouth will be "die
when I tell you too, scum sucking laptop, die; die; die!".
Right, and the sort of unstable user to say to their laptop "scum
sucking laptop, die; die; die!" probably deserves to rebuild their rpmdb
on next reboot.
> If you /sbin/shutdown as root, or suffer a power failure without
a UPS,
> then all bets are off :-)
Or press the power button
Power button goes through HAL, so we catch this too.
or rpm gets OOMed, etc. etc.
If you get OOMed, all bets are off. But if you're in OOM, you've got
bigger problems on your plate.
Richard.
3:50 a.m.
Le dimanche 07 décembre 2008 à 08:55 +0000, Richard Hughes a écrit :
> Which isn't really helpful, esp. as the messages I've
seen say
> something like "Some program is stopping you from doing this" ... pretty
> much guaranteeing the next words out of the users mouth will be "die
> when I tell you too, scum sucking laptop, die; die; die!".
Right, and the sort of unstable user to say to their laptop "scum
sucking laptop, die; die; die!" probably deserves to rebuild their rpmdb
on next reboot.
I would be more constructive to tell the user what the blocking program
is (command name, user, PID).
A lot of PK messages suffer from this kind of lack of details which is
not helpful for the user and just makes him want to scream. Please try
to give users *context* instead of vague maddening generic blurbs.
Remember, the user, not PK, is supposed to be in control. No black magic
please.
--
Nicolas Mailhot
11:50 a.m.
On Sun, 2008-12-07 at 10:50 +0100, Nicolas Mailhot wrote:
I would be more constructive to tell the user what the blocking
program is (command name, user, PID).
The application name and perhaps the user seems useful, I'm not sure
about the cmdline or PID data (although we have this logged if needed).
A lot of PK messages suffer from this kind of lack of details which
is
not helpful for the user and just makes him want to scream. Please try
to give users *context* instead of vague maddening generic blurbs.
Right, can you please file a bug against the gnome-packagekit package
and I'll have a look on Monday. Thanks.
Richard.
12:07 p.m.
Le dimanche 07 décembre 2008 à 17:50 +0000, Richard Hughes a écrit :
On Sun, 2008-12-07 at 10:50 +0100, Nicolas Mailhot wrote:
>
> I would be more constructive to tell the user what the blocking
> program is (command name, user, PID).
The application name and perhaps the user seems useful, I'm not sure
about the cmdline or PID data (although we have this logged if needed).
That's for bashing or killing (as appropriate) :p
https://bugzilla.redhat.com/show_bug.cgi?id=475094
--
Nicolas Mailhot
5:41 p.m.
On Fri, 2008-12-05 at 14:36 -0600, Les Mikesell wrote:
Is there a plan for how yum is going to upgrade itself?
Good question, actually. And the answer is this is exactly the reason we
don't officially support "yum upgrades" across major releases.
The upgrade is done in an anaconda environment, completely shielded from
what's happening to the system being upgraded.
3:54 p.m.
Matej Cepl wrote:
On 2008-12-05, 14:42 GMT, Michael DeHaan wrote:
> I personally haven't tried it yet, but it /aims/ to be
> incompatble, which is perhaps one of the most glaring signs
> a language designer has lost it that I've seen.
Guido was preparing on this incompatibility for years, so unless
you were sleeping you should not be surprised.
Not being surprised is one thing, but I don't see how anyone could be
prepared other than not using any python code.
> but it's pretty bad for someone who wants to keep a single
> codebase across EL 4 (Python 2.3) and up, which I think a lot
> of us do.
The party line is that you should develop against python 2.6
(which doesn't block you from being compatible with Python 2.3)
and then conversion from 2.6 to 3.* would be guaranteed to be
done just with a script.
Is there some shortage of names? Why can't a new and incompatible
language be given a different name so people don't try to use it with
the old and different code?
--
Les Mikesell
lesmikesell(a)gmail.com
11:47 a.m.
Les Mikesell wrote:
Is there some shortage of names? Why can't a new and
incompatible
language be given a different name so people don't try to use it with
the old and different code?
Before we go too far down the argument of whether we need one or two
python interpreters in Fedora we need to see what the nature of the
problems are. Python-2.6 plus the from __future__ import * stuff gets
us something very close to compatibile with python-3.0. Python-2.7 and
python-3.1 are supposed to be even closer. The last time I tested, it
was possible to turn on the from __future__ import * features on a file
by file basis. So -- if the compatibility of python-3 and python-2.6+
are good enough Fedora could run python-3 and python-2 targeted
upstreams together under python-2.6+. We need to gather experience
trying to do this before we know, though.
-Toshio
12:35 p.m.
Toshio Kuratomi wrote:
> Is there some shortage of names? Why can't a new and incompatible
> language be given a different name so people don't try to use it with
> the old and different code?
>
Before we go too far down the argument of whether we need one or two
python interpreters in Fedora we need to see what the nature of the
problems are. Python-2.6 plus the from __future__ import * stuff gets
us something very close to compatibile with python-3.0. Python-2.7 and
python-3.1 are supposed to be even closer. The last time I tested, it
was possible to turn on the from __future__ import * features on a file
by file basis. So -- if the compatibility of python-3 and python-2.6+
are good enough Fedora could run python-3 and python-2 targeted
upstreams together under python-2.6+. We need to gather experience
trying to do this before we know, though.
The problem I see here is that even if you decide that you can manage a
cutover for everything included/upstream in fedora, it is a bad idea to
assume that users are ready and willing to do the same with their own
code on the same day - or that they will know not to update until they
can. You'll probably cover most of the cases if you can update mailman,
rhythmbox, yum and the system* tools on the same day, but you never
know. And what is the backout strategy for someone whose apps are broken?
I just don't get why any sane person, especially anyone familiar with
computer languages, would ever want to give something that is not the
same the same name. Does anyone know how the developer(s) manage this
themselves? I have to think they are keeping multiple concurrent
versions installed (and that that is the only reasonable approach).
--
Les Mikesell
lesmikesell(a)gmail.com
12:47 p.m.
On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
I just don't get why any sane person, especially anyone familiar with
computer languages, would ever want to give something that is not the
same the same name. Does anyone know how the developer(s) manage this
themselves? I have to think they are keeping multiple concurrent
versions installed (and that that is the only reasonable approach).
I'm pretty certain that if you look at any language, they've all faced
similar scenarios, major version upgrades that may in fact not be
forward no backward compatible. People have dealt with it and moved on.
No language is perfect.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:03 p.m.
Jesse Keating wrote:
> On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
>
> I just don't get why any sane person, especially anyone familiar with
> computer languages, would ever want to give something that is not the
> same the same name. Does anyone know how the developer(s) manage this
> themselves? I have to think they are keeping multiple concurrent
> versions installed (and that that is the only reasonable approach).
I'm pretty certain that if you look at any language, they've all faced
similar scenarios, major version upgrades that may in fact not be
forward no backward compatible. People have dealt with it and moved on.
No language is perfect.
But where the change was anything more than a bugfix they dealt with it
by permitting the old/new languages to run in parallel until everyone
had time to make the necessary changes. And in the old days of static
compiled binaries and versioned libraries it didn't make such a big
difference since you could keep running your old versions even if the
current compiler couldn't build them. That doesn't work with
interpreted languages and massive plugin usage - everything has to be
versioned together or kept in separate namespaces.
--
Les Mikesell
lesmikesell(a)gmail.com
4:19 p.m.
On Mon, 2008-12-08 at 10:47 -0800, Jesse Keating wrote:
> On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
>
> I just don't get why any sane person, especially anyone familiar with
> computer languages, would ever want to give something that is not the
> same the same name. Does anyone know how the developer(s) manage this
> themselves? I have to think they are keeping multiple concurrent
> versions installed (and that that is the only reasonable approach).
I'm pretty certain that if you look at any language, they've all faced
similar scenarios, major version upgrades that may in fact not be
forward no backward compatible. People have dealt with it and moved on.
No language is perfect.
Never seen C/C++ break backward compatibility on a scale like Python 3.0
will.
And they are compiled, where the impact is 100 fold less than for
interpreted languages ...
I would personally strongly consider having 2.x and 3.0 parallel
installable ...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
4:36 p.m.
On Mon, Dec 8, 2008 at 4:19 PM, Simo Sorce <ssorce(a)redhat.com> wrote:
On Mon, 2008-12-08 at 10:47 -0800, Jesse Keating wrote:
> > On Mon, 2008-12-08 at 12:35 -0600, Les Mikesell wrote:
> >
> > I just don't get why any sane person, especially anyone familiar with
> > computer languages, would ever want to give something that is not the
> > same the same name. Does anyone know how the developer(s) manage this
> > themselves? I have to think they are keeping multiple concurrent
> > versions installed (and that that is the only reasonable approach).
>
> I'm pretty certain that if you look at any language, they've all faced
> similar scenarios, major version upgrades that may in fact not be
> forward no backward compatible. People have dealt with it and moved on.
> No language is perfect.
Never seen C/C++ break backward compatibility on a scale like Python 3.0
will.
And they are compiled, where the impact is 100 fold less than for
interpreted languages ...
I would personally strongly consider having 2.x and 3.0 parallel
installable ...
Isn't Python designed to be parallel installable?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
10:54 a.m.
Arthur Pemberton wrote:
On Mon, Dec 8, 2008 at 4:19 PM, Simo Sorce <ssorce(a)redhat.com>
wrote:
> I would personally strongly consider having 2.x and 3.0 parallel
> installable ...
Isn't Python designed to be parallel installable?
Yes it is. We just want to avoid having to do that if possible because
it could be very painful to do so.
Here's the fear:
python2.x
- python-libfoo-2.0
- spiffy-app-1.2
python3.x
- python-libfoo-2.1
- excellent-app-1.1
python-libfoo-2.0 uses the 2.x API. python-libfoo-2.1 uses the
python-3.x API. In order to get spiffy-app and excellent-app into the
distro we need to have both python2.x and python3.x versions of the
library installed.
Now a security fix is released for python-libfoo-2.1. Does that also
affect python-libfoo-2.0? Can we backport the fix or are the py2.x and
py3.x versions too different? Do we need to have more python coders
available to fix these errors?
Here's the ideal (For Fedora, once again, this does not address
mpdehaan's concerns):
python2.6
- python-libfoo-2.1 (with from __future__ import *)
- spiffy-app-1.2
- excellent-app-1.1 (with from __future__ import *)
If this is possible we can maintain one version of python and one
version of the library. The apps can both consume the library even
though one was coded for python-3.x and the other was coded for python-2.x.
Is this going to be possible or will deepseated assumptions in the new
language prevent this? That's something we can't know for sure until we
actually start trying to run code in mixed mode like this. Some people
had great luck with this earlier in the year[1]_ but I think there were
changes to the stdlibrary since then and I didn't trust that the author
had done a thorough job with the unicode/string/bytes testing.
So let me reiterate:
* python-3.x will not be in Fedora-11 unless it becomes obvious in the
next few weeks that we absolutely must be running it for the next release.
* we need more experience with python-2.6+ & python-3 compatibility
before we decide whether parallel versions of python are necessary.
.. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
-Toshio
1:05 p.m.
2008/12/9 Toshio Kuratomi <a.badger(a)gmail.com>:
Arthur Pemberton wrote:
> On Mon, Dec 8, 2008 at 4:19 PM, Simo Sorce <ssorce(a)redhat.com> wrote:
>> I would personally strongly consider having 2.x and 3.0 parallel
>> installable ...
>
>
> Isn't Python designed to be parallel installable?
>
>
Yes it is. We just want to avoid having to do that if possible because
it could be very painful to do so.
Here's the fear:
python2.x
- python-libfoo-2.0
- spiffy-app-1.2
python3.x
- python-libfoo-2.1
- excellent-app-1.1
python-libfoo-2.0 uses the 2.x API. python-libfoo-2.1 uses the
python-3.x API. In order to get spiffy-app and excellent-app into the
distro we need to have both python2.x and python3.x versions of the
library installed.
Now a security fix is released for python-libfoo-2.1. Does that also
affect python-libfoo-2.0? Can we backport the fix or are the py2.x and
py3.x versions too different? Do we need to have more python coders
available to fix these errors?
Here's the ideal (For Fedora, once again, this does not address
mpdehaan's concerns):
python2.6
- python-libfoo-2.1 (with from __future__ import *)
- spiffy-app-1.2
- excellent-app-1.1 (with from __future__ import *)
If this is possible we can maintain one version of python and one
version of the library. The apps can both consume the library even
though one was coded for python-3.x and the other was coded for python-2.x.
Is this going to be possible or will deepseated assumptions in the new
language prevent this? That's something we can't know for sure until we
actually start trying to run code in mixed mode like this. Some people
had great luck with this earlier in the year[1]_ but I think there were
changes to the stdlibrary since then and I didn't trust that the author
had done a thorough job with the unicode/string/bytes testing.
So let me reiterate:
* python-3.x will not be in Fedora-11 unless it becomes obvious in the
next few weeks that we absolutely must be running it for the next release.
* we need more experience with python-2.6+ & python-3 compatibility
before we decide whether parallel versions of python are necessary.
.. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
-Toshio
Well again. Some people (like Toshio) seem to have a grasp on the
matter. All this banter hasn't produced anything more of use. How
about forming a temp SIG to take care of this trusting they do the
right thing?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
6:24 p.m.
On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
2008/12/9 Toshio Kuratomi <a.badger(a)gmail.com>:
> So let me reiterate:
>
> * python-3.x will not be in Fedora-11 unless it becomes obvious in the
> next few weeks that we absolutely must be running it for the next release.
> * we need more experience with python-2.6+ & python-3 compatibility
> before we decide whether parallel versions of python are necessary.
>
> .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
>
> -Toshio
Well again. Some people (like Toshio) seem to have a grasp on the
matter. All this banter hasn't produced anything more of use. How
about forming a temp SIG to take care of this trusting they do the
right thing?
As opposed to the Python SIG that already exists?
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
8:40 p.m.
2008/12/9 Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>:
On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
> 2008/12/9 Toshio Kuratomi <a.badger(a)gmail.com>:
> > So let me reiterate:
> >
> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
> > next few weeks that we absolutely must be running it for the next release.
> > * we need more experience with python-2.6+ & python-3 compatibility
> > before we decide whether parallel versions of python are necessary.
> >
> > .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
> >
> > -Toshio
>
>
> Well again. Some people (like Toshio) seem to have a grasp on the
> matter. All this banter hasn't produced anything more of use. How
> about forming a temp SIG to take care of this trusting they do the
> right thing?
As opposed to the Python SIG that already exists?
No. Seems like the ideal body to come to a decision and let the rest
of us know.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
5:35 a.m.
On Tue, 2008-12-09 at 20:40 -0600, Arthur Pemberton wrote:
2008/12/9 Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>:
> On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
>> 2008/12/9 Toshio Kuratomi <a.badger(a)gmail.com>:
>> > So let me reiterate:
>> >
>> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
>> > next few weeks that we absolutely must be running it for the next release.
>> > * we need more experience with python-2.6+ & python-3 compatibility
>> > before we decide whether parallel versions of python are necessary.
>> >
>> > .. _[1]: http://python-incompatibility.googlecode.com/svn/trunk/README.txt
>> >
>> > -Toshio
>>
>>
>> Well again. Some people (like Toshio) seem to have a grasp on the
>> matter. All this banter hasn't produced anything more of use. How
>> about forming a temp SIG to take care of this trusting they do the
>> right thing?
>
> As opposed to the Python SIG that already exists?
No. Seems like the ideal body to come to a decision and let the rest
of us know.
Well, most of the active members of the Python SIG have chimed in on
this, and we're all channeling Frankie.
Now, I do believe this is an important subject and we do need to gauge
the impact Python 3000 has on Fedora, but I believe that we are grossly
unequipped to do so at this time. I'd like to revisit this topic in
about a year (perhaps sooner, depending on circumstances), but for now
everyone just relax.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
6:14 a.m.
> >> > * python-3.x will not be in Fedora-11 unless it
becomes obvious in the
> >> > next few weeks that we absolutely must be running it for the next
release.
> >> > * we need more experience with python-2.6+ & python-3
compatibility
> >> > before we decide whether parallel versions of python are necessary.
> >> >
> >> > .. _[1]:
http://python-incompatibility.googlecode.com/svn/trunk/README.txt
> >> >
> >> > -Toshio
> >>
> >>
> >> Well again. Some people (like Toshio) seem to have a grasp on the
> >> matter. All this banter hasn't produced anything more of use. How
> >> about forming a temp SIG to take care of this trusting they do the
> >> right thing?
> >
> > As opposed to the Python SIG that already exists?
>
> No. Seems like the ideal body to come to a decision and let the rest
> of us know.
Well, most of the active members of the Python SIG have chimed in on
this, and we're all channeling Frankie.
Now, I do believe this is an important subject and we do need to gauge
the impact Python 3000 has on Fedora, but I believe that we are grossly
unequipped to do so at this time. I'd like to revisit this topic in
about a year (perhaps sooner, depending on circumstances), but for now
everyone just relax.
I would have thought we'd want to wait for a number of point releases
before putting it in anyway. Invariably there will be issues with a 0
release and you'd want to wait a couple of months for things to bed
down. With 2.6 being a release to allow easier migration to 3 I would
have thought its the perfect candidate for F-11 and by the time its
out there will be a much better picture of how we'd stand for v3.
Peter
11:55 a.m.
2008/12/10 Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>:
On Tue, 2008-12-09 at 20:40 -0600, Arthur Pemberton wrote:
> 2008/12/9 Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>:
> > On Tue, 2008-12-09 at 13:05 -0600, Arthur Pemberton wrote:
> >> 2008/12/9 Toshio Kuratomi <a.badger(a)gmail.com>:
> >> > So let me reiterate:
> >> >
> >> > * python-3.x will not be in Fedora-11 unless it becomes obvious in the
> >> > next few weeks that we absolutely must be running it for the next
release.
> >> > * we need more experience with python-2.6+ & python-3
compatibility
> >> > before we decide whether parallel versions of python are necessary.
> >> >
> >> > .. _[1]:
http://python-incompatibility.googlecode.com/svn/trunk/README.txt
> >> >
> >> > -Toshio
> >>
> >>
> >> Well again. Some people (like Toshio) seem to have a grasp on the
> >> matter. All this banter hasn't produced anything more of use. How
> >> about forming a temp SIG to take care of this trusting they do the
> >> right thing?
> >
> > As opposed to the Python SIG that already exists?
>
> No. Seems like the ideal body to come to a decision and let the rest
> of us know.
Well, most of the active members of the Python SIG have chimed in on
this, and we're all channeling Frankie.
Now, I do believe this is an important subject and we do need to gauge
the impact Python 3000 has on Fedora, but I believe that we are grossly
unequipped to do so at this time. I'd like to revisit this topic in
about a year (perhaps sooner, depending on circumstances), but for now
everyone just relax.
Just to be clear, does that mean no Python 3.0 in parallel either?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
12:14 p.m.
On Wed, 2008-12-10 at 11:55 -0600, Arthur Pemberton wrote:
Just to be clear, does that mean no Python 3.0 in parallel either?
That has already been turned down multiple times. Watch my blog if you
want a parallel-installable package for 3.x. I plan to update my SRPM to
final once the 2.6 work in Fedora is done.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
12:58 p.m.
On 10.12.2008 19:14, Ignacio Vazquez-Abrams wrote:
On Wed, 2008-12-10 at 11:55 -0600, Arthur Pemberton wrote:
> Just to be clear, does that mean no Python 3.0 in parallel either?
That has already been turned down multiple times.
Those things (and the discussion around it, like this one) will drive me
away from Fedora sooner or later.
For me the whole thing boils down to: There is a software that some
people want (developers for example; and there are a lot of developers
that use Fedora afaics...); it's open-source, it doesn't hurt upstream
if we ship it (like kernel-modules), so let's just ship it.
Anyway:
Watch my blog if you
want a parallel-installable package for 3.x. I plan to update my SRPM to
final once the 2.6 work in Fedora is done.
Do you plan to submit it to RPM Fusion?
Cu
knurd
1:40 p.m.
On Wed, 2008-12-10 at 19:58 +0100, Thorsten Leemhuis wrote:
On 10.12.2008 19:14, Ignacio Vazquez-Abrams wrote:
> Watch my blog if you
> want a parallel-installable package for 3.x. I plan to update my SRPM to
> final once the 2.6 work in Fedora is done.
Do you plan to submit it to RPM Fusion?
I... had not planned to, but I can if there's sufficient interest. I
have no interest in maintaining duplicates of all the modules however. I
will help with packaging though. *Help with*, not do.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
12:29 p.m.
Arthur Pemberton wrote:
> Well, most of the active members of the Python SIG have chimed in on
> this, and we're all channeling Frankie.
>
> Now, I do believe this is an important subject and we do need to gauge
> the impact Python 3000 has on Fedora, but I believe that we are grossly
> unequipped to do so at this time. I'd like to revisit this topic in
> about a year (perhaps sooner, depending on circumstances), but for now
> everyone just relax.
Just to be clear, does that mean no Python 3.0 in parallel either?
How do you expect people to modify and test their own code without a
parallel install?
--
Les Mikesell
lesmikesell(a)gmail.com
12:59 p.m.
Les Mikesell wrote:
Arthur Pemberton wrote:
>
>> Well, most of the active members of the Python SIG have chimed in on
>> this, and we're all channeling Frankie.
>>
>> Now, I do believe this is an important subject and we do need to gauge
>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>> unequipped to do so at this time. I'd like to revisit this topic in
>> about a year (perhaps sooner, depending on circumstances), but for now
>> everyone just relax.
>
>
> Just to be clear, does that mean no Python 3.0 in parallel either?
How do you expect people to modify and test their own code without a
parallel install?
As stated multiple times, the initial port will be to python-2.6+ with
python-3 features turned on. Then we'll see where we're at.
It's possible that the remaining porting work will be small at that
point and we can migrate easily. It's also possible that it's still a
major undertaking to go from py-2.6 w/ python-3 features to py3. But we
won't know until code starts being ported so there's no use trying to
guess what we need to do now.
-Toshio
1:17 p.m.
2008/12/10 Toshio Kuratomi <a.badger(a)gmail.com>:
Les Mikesell wrote:
> Arthur Pemberton wrote:
>>
>>> Well, most of the active members of the Python SIG have chimed in on
>>> this, and we're all channeling Frankie.
>>>
>>> Now, I do believe this is an important subject and we do need to gauge
>>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>>> unequipped to do so at this time. I'd like to revisit this topic in
>>> about a year (perhaps sooner, depending on circumstances), but for now
>>> everyone just relax.
>>
>>
>> Just to be clear, does that mean no Python 3.0 in parallel either?
>
> How do you expect people to modify and test their own code without a
> parallel install?
>
As stated multiple times, the initial port will be to python-2.6+ with
python-3 features turned on. Then we'll see where we're at.
It's possible that the remaining porting work will be small at that
point and we can migrate easily. It's also possible that it's still a
major undertaking to go from py-2.6 w/ python-3 features to py3. But we
won't know until code starts being ported so there's no use trying to
guess what we need to do now.
-Toshio
I think he meant "unofficial" work, as in not official porting of
packages. Just regular dev work.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
1:29 p.m.
Arthur Pemberton wrote:
2008/12/10 Toshio Kuratomi <a.badger(a)gmail.com>:
> Les Mikesell wrote:
>> Arthur Pemberton wrote:
>>>> Well, most of the active members of the Python SIG have chimed in on
>>>> this, and we're all channeling Frankie.
>>>>
>>>> Now, I do believe this is an important subject and we do need to gauge
>>>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>>>> unequipped to do so at this time. I'd like to revisit this topic in
>>>> about a year (perhaps sooner, depending on circumstances), but for now
>>>> everyone just relax.
>>>
>>> Just to be clear, does that mean no Python 3.0 in parallel either?
>> How do you expect people to modify and test their own code without a
>> parallel install?
>>
> As stated multiple times, the initial port will be to python-2.6+ with
> python-3 features turned on. Then we'll see where we're at.
>
> It's possible that the remaining porting work will be small at that
> point and we can migrate easily. It's also possible that it's still a
> major undertaking to go from py-2.6 w/ python-3 features to py3. But we
> won't know until code starts being ported so there's no use trying to
> guess what we need to do now.
>
> -Toshio
I think he meant "unofficial" work, as in not official porting of
packages. Just regular dev work.
Pretty much the same answer. Port to python-2.6 with python-3 features
turned on. We don't, at this point, have enough information to tell if
that's sufficient or not.
-Toshio
1:36 p.m.
Arthur Pemberton wrote:
>>>> Well, most of the active members of the Python SIG have chimed in on
>>>> this, and we're all channeling Frankie.
>>>>
>>>> Now, I do believe this is an important subject and we do need to gauge
>>>> the impact Python 3000 has on Fedora, but I believe that we are grossly
>>>> unequipped to do so at this time. I'd like to revisit this topic in
>>>> about a year (perhaps sooner, depending on circumstances), but for now
>>>> everyone just relax.
>>>
>>> Just to be clear, does that mean no Python 3.0 in parallel either?
>> How do you expect people to modify and test their own code without a
>> parallel install?
>>
> As stated multiple times, the initial port will be to python-2.6+ with
> python-3 features turned on. Then we'll see where we're at.
>
> It's possible that the remaining porting work will be small at that
> point and we can migrate easily. It's also possible that it's still a
> major undertaking to go from py-2.6 w/ python-3 features to py3. But we
> won't know until code starts being ported so there's no use trying to
> guess what we need to do now.
>
I think he meant "unofficial" work, as in not official porting of
packages. Just regular dev work.
Yes, I meant end users who have written their own code trusting that the
interpreter you ship will continue to run it.
--
Les Mikesell
lesmikesell(a)gmail.com
3:42 p.m.
Les Mikesell <lesmikesell(a)gmail.com> wrote:
[...]
I just don't get why any sane person, especially anyone familiar
with
computer languages, would ever want to give something that is not the
same the same name. Does anyone know how the developer(s) manage this
themselves? I have to think they are keeping multiple concurrent
versions installed (and that that is the only reasonable approach).
You mean like C? There was plain K&R C, then futzing around with lint, then
several popular C extensions, then along came ANSI C (C89), then C99; all the
while there were all sorts of "interesting" GCC extensions included,
changed, retracted, added in the standard or replaced in it by a completely
different way of doing the same thing...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
5:12 p.m.
Horst H. von Brand wrote:
Les Mikesell <lesmikesell(a)gmail.com> wrote:
[...]
> I just don't get why any sane person, especially anyone familiar with
> computer languages, would ever want to give something that is not the
> same the same name. Does anyone know how the developer(s) manage this
> themselves? I have to think they are keeping multiple concurrent
> versions installed (and that that is the only reasonable approach).
You mean like C? There was plain K&R C, then futzing around with lint, then
several popular C extensions, then along came ANSI C (C89), then C99; all the
while there were all sorts of "interesting" GCC extensions included,
changed, retracted, added in the standard or replaced in it by a completely
different way of doing the same thing...
And yet, in all that time, I never had a problem continuing to run a
previously working C program even in the extremely rare cases where an
updated compiler wouldn't build a new copy. Python doesn't work that way.
--
Les Mikesell
lesmikesell(a)gmail.com
4:24 a.m.
Les Mikesell wrote:
And yet, in all that time, I never had a problem continuing to run a
previously working C program even in the extremely rare cases where an
updated compiler wouldn't build a new copy. Python doesn't work that way.
New major versions of GCC have almost always resulted in a few C
programs within the distribution needing to be updated to work with it.
You might not have to run it this much but any major distribution
certainly would have. It is not a python specific problem though python
does change more often than C does.
Rahul
4:33 a.m.
On Tue, Dec 09, 2008 at 03:54:48PM +0530, Rahul Sundaram wrote:
Les Mikesell wrote:
>
>And yet, in all that time, I never had a problem continuing to run a
>previously working C program even in the extremely rare cases where an
>updated compiler wouldn't build a new copy. Python doesn't work that way.
New major versions of GCC have almost always resulted in a few C
programs within the distribution needing to be updated to work with it.
You might not have to run it this much but any major distribution
certainly would have. It is not a python specific problem though python
does change more often than C does.
This is not a comparable scenario. The new GCC releases are identifying
bugs which always existed in your code, not changing the language. As
such once you fix the bugs, your code continues to work on old & new
GCC just fine. The equivalent scenario would be a new GLibC release
which changed a bunch of APIs you were using, making it impossible to
write code which works on both old & new at new. Even then, the linker
provides version scripts which allow you to provide multiple definitions
of the same ELF symbol so you can maintain ABI compatability across old
and new version even if you changed API contracts.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
8:16 a.m.
Daniel P. Berrange wrote:
This is not a comparable scenario. The new GCC releases are identifying
bugs which always existed in your code, not changing the language. As
such once you fix the bugs, your code continues to work on old & new
GCC just fine.
It is not the exact same scenaro but we are talking about backward
compatibility of languages in general. If new GCC breaks my C code or a
new Python interpretor breaks my python code, it is still breaking what
was working before. C specification is not breakfast reading so almost
everybody just go with what a compiler like GCC supports.
Isn't a similar situation responsible for
https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable
Rahul
8:27 a.m.
On Tue, 2008-12-09 at 19:46 +0530, Rahul Sundaram wrote:
Daniel P. Berrange wrote:
>
> This is not a comparable scenario. The new GCC releases are identifying
> bugs which always existed in your code, not changing the language. As
> such once you fix the bugs, your code continues to work on old & new
> GCC just fine.
It is not the exact same scenaro but we are talking about backward
compatibility of languages in general. If new GCC breaks my C code or a
new Python interpretor breaks my python code, it is still breaking what
was working before. C specification is not breakfast reading so almost
everybody just go with what a compiler like GCC supports.
Isn't a similar situation responsible for
https://fedoraproject.org/wiki/Common_F10_bugs#DNS_Resolver_not_Reliable
I hope you realize the difference between a few programs not *compiling*
anymore, but that keep working no problem.
And *all* programs not running, until you fix them, *and* all the
modules not yet converted you depend on, including C bindings which are
not exactly breakfast coding for python programmers...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
8:52 a.m.
Simo Sorce wrote:
I hope you realize the difference between a few programs not
*compiling*
anymore, but that keep working no problem.
Sure but that is a side effect of interpreted (python) vs compiled ( C)
code and not the strength of backward compatibility of a language. When
it comes to Free software within a Fedora environment which is supposed
to be self hosting, working but not compiling code is certainly a issue
as well.
Rahul
8:52 a.m.
On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
We're just now dealing with Python 2.6, but over on the radar is
perhaps
one of the most incompatible upgrades to the language we've seen in
Python 3. I personally haven't tried it yet, but it /aims/ to be
incompatble, which is perhaps one of the most glaring signs a language
designer has lost it that I've seen.
http://docs.python.org/3.0/whatsnew/3.0.html
This isn't a huge problem to those who are only developing on the latest
Fedora, per-se (other than getting over the initial hump), but it's
pretty bad for someone who wants to keep a single codebase across EL 4
(Python 2.3) and up, which I think a lot of us do. That gets to be
darn impossible and we have to double our involvement with code because
we essentially have to maintain a differently-compatible fork for each
project.
(NOTE: this requires the viewpoint that not everyone care just about the
latest Fedora, which might be controversial... but to me, the latest
Fedora is what I'll run as my dev environment but not everyone can
upgrade -- and many folks are also running EL and EPEL deserves our full
support and consideration)
So, what of plans?
Are we looking at also carrying on with packaging 2.N indefinitely when
we do decide to carry 3, because as I know it, the code changes to make
something Python 3 compatible will be severe and that's a big item for
any release, and will probably result in some undiscovered bugs even
after the initial ports (if applied).
I haven't seen /anything/ regarding a compatibility mode for
/usr/bin/python, and I'd hate to have to develop a non-core library that
allows for functions that work the same way on both versions and use
that instead. That would be heinous.
Short of porting everything over to Ruby, oCaml, or
enterprise-Fortran.NET#4000, any ideas on planning for this?
--Michael
I'm not a Python developer, but I have been reading with a lot of
interest the upgrade in Fedora to 2.6 as well as the release of this new
dynamic programming language named "Python 3000". It seems that the
prevailing wisdom, which fits with the scenario you have mentioned, is
to make everything work now with 2.6, and then the 2to3 utility will
make the move to 3000 much easier, if not painless.
Of course, again, not being Pythonic myself, this all sounds good to me,
but the devilish details are not apparent either.
8:57 a.m.
On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
Short of porting everything over to Ruby, oCaml, or
enterprise-Fortran.NET#4000, any ideas on planning for this?
I think we should continue on to 2.7 and 2.8; this will give us the time
we need to bring the compatibility versions into EL and inch us closer
to Python 3000.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
9:13 a.m.
Ignacio Vazquez-Abrams (ivazqueznet(a)gmail.com) said:
On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
> Short of porting everything over to Ruby, oCaml, or
> enterprise-Fortran.NET#4000, any ideas on planning for this?
I think we should continue on to 2.7 and 2.8; this will give us the time
we need to bring the compatibility versions into EL and inch us closer
to Python 3000.
Only one version of EL, though. It's not like RHEL 4/5 are going
to move to new python.
Bill
12:30 p.m.
Bill Nottingham wrote:
Ignacio Vazquez-Abrams (ivazqueznet(a)gmail.com) said:
> On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
>> Short of porting everything over to Ruby, oCaml, or
>> enterprise-Fortran.NET#4000, any ideas on planning for this?
> I think we should continue on to 2.7 and 2.8; this will give us the time
> we need to bring the compatibility versions into EL and inch us closer
> to Python 3000.
Only one version of EL, though. It's not like RHEL 4/5 are going
to move to new python.
but rhel-6 will be based on f11 and if f11 won't ve p3000 then nor el-6
which will hurt many people even in 2015...
--
Levente "Si vis pacem para bellum!"
12:56 p.m.
Farkas Levente wrote:
Bill Nottingham wrote:
> Only one version of EL, though. It's not like RHEL 4/5 are going
> to move to new python.
but rhel-6 will be based on f11 and if f11 won't ve p3000 then nor el-6
which will hurt many people even in 2015...
Short answer yes.
Longer answer, if it's based on F11, it should have at least python-2.6.
If it has 2.6, then something resembling python3 code will be allowed.
I qualify that since there are incompatibilities between what 2.6 with
python3 syntax and python3.0 do. Whether the incompatibilities are
something we can deal with or not is something we need experience with
to find out.
-Toshio
9:09 a.m.
For Windows cross-compilation of Python libraries, we decided that
Python 2.x's build system is crazy, so we would only support Python 3
from the beginning. The reason is so that we can get build system
patches upstream easily without having to maintain patches against all
the different branches (ie. against 2.5, 2.6, 3.0, devel).
So if you want your Python program to work with the Fedora MinGW
cross-compiler, you'd better try it out with the 'python -3' option
and fix any deprecated bits.
Rich.
... Or take the opportunity to jump to a safe language .. we've
already got an OCaml cross-compiler.
9:18 a.m.
Richard W.M. Jones (rjones(a)redhat.com) said:
So if you want your Python program to work with the Fedora MinGW
cross-compiler, you'd better try it out with the 'python -3' option
and fix any deprecated bits.
Rich.
... Or take the opportunity to jump to a safe language .. we've
already got an OCaml cross-compiler.
Yes, let's move to something 'safer', which doesn't have ABI
compatibility
ANYWHERE. That makes perfect sense.
Bill
9:42 a.m.
On Fri, Dec 05, 2008 at 10:18:18AM -0500, Bill Nottingham wrote:
Richard W.M. Jones (rjones(a)redhat.com) said:
> ... Or take the opportunity to jump to a safe language .. we've
> already got an OCaml cross-compiler.
Yes, let's move to something 'safer', which doesn't have ABI
compatibility
ANYWHERE. That makes perfect sense.
You can get the same illusion of ABI compatibility as in C by simply
wrapping your OCaml library in a C wrapper and publishing the C header
file as the ABI. I even wrote a tool to do this automatically. Real
ABI compatibility is a tricky problem that only works in very limited
cases (eg. you extend the interface with new functions and never
modify even the internals of existing functions).
Rich.
10:07 a.m.
On Fri, 2008-12-05 at 15:42 +0000, Richard W.M. Jones wrote:
[snip pointless trolling]
Real
ABI compatibility is a tricky problem that only works in very limited
cases (eg. you extend the interface with new functions and never
modify even the internals of existing functions).
ABI does not mean what you think it means:
http://en.wikipedia.org/wiki/Application_binary_interface#Content
--
James Antill <james(a)fedoraproject.org>
Fedora
9:09 a.m.
On Fri, Dec 05, 2008 at 09:42:43AM -0500, Michael DeHaan wrote:
We're just now dealing with Python 2.6, but over on the radar is perhaps
one of the most incompatible upgrades to the language we've seen in
Python 3. I personally haven't tried it yet, but it /aims/ to be
incompatble, which is perhaps one of the most glaring signs a language
designer has lost it that I've seen.
http://docs.python.org/3.0/whatsnew/3.0.html
This isn't a huge problem to those who are only developing on the latest
Fedora, per-se (other than getting over the initial hump), but it's
pretty bad for someone who wants to keep a single codebase across EL 4
(Python 2.3) and up, which I think a lot of us do. That gets to be
darn impossible and we have to double our involvement with code because
we essentially have to maintain a differently-compatible fork for each
project.
(NOTE: this requires the viewpoint that not everyone care just about the
latest Fedora, which might be controversial... but to me, the latest
Fedora is what I'll run as my dev environment but not everyone can
upgrade -- and many folks are also running EL and EPEL deserves our full
support and consideration)
So, what of plans?
Are we looking at also carrying on with packaging 2.N indefinitely when
we do decide to carry 3, because as I know it, the code changes to make
something Python 3 compatible will be severe and that's a big item for
any release, and will probably result in some undiscovered bugs even
after the initial ports (if applied).
I haven't seen /anything/ regarding a compatibility mode for
/usr/bin/python, and I'd hate to have to develop a non-core library that
allows for functions that work the same way on both versions and use
that instead. That would be heinous.
IMHO the only viable option is to maintain both python 2.x and 3.x
in parallel. It is essentially a brand new language which just
happens to share the same base name. Like Perl 5 & Perl 6.
It is going to be a very long time before every upstream for all our
python bits support 3.x syntax and we don't want to have to undertake
the work to re-write them all ourselves.
The delibrate break of syntax is going to cause a major PITA for
upstream projects because there's no way they can stop shipping
2.x compatible code just because some people want to use 3.x. So
every upstream pretty much has to now maintain two sets of python
bindings :-(
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:32 a.m.
On Fri, 2008-12-05 at 15:09 +0000, Daniel P. Berrange wrote:
IMHO the only viable option is to maintain both python 2.x and 3.x
in parallel. It is essentially a brand new language which just
happens to share the same base name. Like Perl 5 & Perl 6.
It's much less like Perl-5/Perl-6, IMO, but even if you convince FESCo
of this mental contortion and you have dual sets of _every_ python
module. The API is very similar and uses the same shared library
name ... so what do you do about all the C programs that link with
libpython?
repoquery --whatrequires 'libpython2.5.so.*'
...are you going to offer two versions of rhythmbox?
--
James Antill <james(a)fedoraproject.org>
Fedora
2:29 p.m.
James Antill wrote:
The API is very similar and uses the same shared library
name ... so what do you do about all the C programs that link with
libpython?
repoquery --whatrequires 'libpython2.5.so.*'
The same thing we do about kdelibs3 and kdelibs 4 coexisting: move one (or
both) of the 2 conflicting -devel symlinks to a subdirectory of the libdir
and have the dependent packages use -L flags.
But is there even a conflict at all? libpython2.5.so != libpython3.0.so.
And if there is one, maybe try to get upstream to fix it?
...are you going to offer two versions of rhythmbox?
But Python is not an application, it's a programming language and a set of
libraries. Shipping 2 versions of an application doesn't make much sense
(and in fact we don't do that for KDE 3 and 4), but libraries (e.g.
kdelibs3/kdelibs4) and programming languages are different. Getting
everything which depends on the library/language ported at the same time is
almost always infeasible for incompatible versions.
Kevin Kofler
3:46 p.m.
On Fri, 2008-12-05 at 21:29 +0100, Kevin Kofler wrote:
James Antill wrote:
> The API is very similar and uses the same shared library
> name ... so what do you do about all the C programs that link with
> libpython?
>
> repoquery --whatrequires 'libpython2.5.so.*'
The same thing we do about kdelibs3 and kdelibs 4 coexisting: move one (or
both) of the 2 conflicting -devel symlinks to a subdirectory of the libdir
and have the dependent packages use -L flags.
You are confused, this isn't the same as KDE because _KDE isn't a
programming language_.
> ...are you going to offer two versions of rhythmbox?
But Python is not an application, it's a programming language and a set of
libraries. Shipping 2 versions of an application doesn't make much sense
(and in fact we don't do that for KDE 3 and 4), but libraries (e.g.
kdelibs3/kdelibs4) and programming languages are different. Getting
everything which depends on the library/language ported at the same time is
almost always infeasible for incompatible versions.
Again, you are confused. Yes, you can ship two different libraries that
two different applications can use ... like gtk1/gtk2, but you can't mix
them within an application.
And that's much more common within a programming language. For example:
http://live.gnome.org/RhythmboxPlugins/WritingGuide
...you have:
application => libpython* => plugin [ => python modules ]
...here you _must_ ship one layer of python throughout, saying "it
should be compatible" works about as well as saying "we should be able
to run kde3 and kde4 in a single applications" ... you can ask for it,
and a pony at the same time, but don't hold your breath.
--
James Antill <james(a)fedoraproject.org>
Fedora
3:54 p.m.
James Antill wrote:
Again, you are confused. Yes, you can ship two different libraries
that
two different applications can use ... like gtk1/gtk2, but you can't mix
them within an application.
And that's much more common within a programming language. For example:
http://live.gnome.org/RhythmboxPlugins/WritingGuide
...you have:
application => libpython* => plugin [ => python modules ]
...here you _must_ ship one layer of python throughout, saying "it
should be compatible" works about as well as saying "we should be able
to run kde3 and kde4 in a single applications" ... you can ask for it,
and a pony at the same time, but don't hold your breath.
Rhythmbox will have to pick one version of Python to support (probably the
default version in Fedora), but that doesn't mean other programs won't want
to use the other version.
Kevin Kofler
9:28 a.m.
On Fri, 2008-12-05 at 09:42 -0500, Michael DeHaan wrote:
We're just now dealing with Python 2.6, but over on the radar is
perhaps
one of the most incompatible upgrades to the language we've seen in
Python 3.
[snip]
So, what of plans?
You do realize that this thread has occurred multiple times now? :)
Are we looking at also carrying on with packaging 2.N indefinitely
when
we do decide to carry 3, because as I know it, the code changes to make
something Python 3 compatible will be severe and that's a big item for
any release, and will probably result in some undiscovered bugs even
after the initial ports (if applied).
Carrying multiple versions of python becomes pretty infeasible very
quickly. It's easy enough to package just python itself, but any
non-trivial user is going to require modules also. So how do you decide
which modules to bring in, how to handle the fact that they may have
moved on to python 3 only, etc. It's a big huge mess.
We'll likely stick with 2.x for a while and watch as python3 matures and
fix things up as we can against 2.6+. Once there seems to be a critical
mass or compelling reason, we'll get to have a flag day. Yes it will
hurt. And for those who also develop things for older distros, yes,
they'll probably need to fork off an old-python or whatever branch and
probably only do bugfixes for some of those distros. But this is no
different from apache 1.x -> 2.x, anyone doing kernel development, or a
number of other cases that have occurred over the years.
Jeremy
10:06 a.m.
On Fri, Dec 5, 2008 at 8:42 AM, Michael DeHaan <mdehaan(a)redhat.com> wrote:
We're just now dealing with Python 2.6, but over on the radar is perhaps one
of the most incompatible upgrades to the language we've seen in Python 3. I
personally haven't tried it yet, but it /aims/ to be incompatble, which is
perhaps one of the most glaring signs a language designer has lost it that
I've seen.
Was that last line really necessary for your post?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
12:39 p.m.
On Fri, 2008-12-05 at 10:06 -0600, Arthur Pemberton wrote:
On Fri, Dec 5, 2008 at 8:42 AM, Michael DeHaan
<mdehaan(a)redhat.com> wrote:
>
> We're just now dealing with Python 2.6, but over on the radar is perhaps one
> of the most incompatible upgrades to the language we've seen in Python 3. I
> personally haven't tried it yet, but it /aims/ to be incompatble, which is
> perhaps one of the most glaring signs a language designer has lost it that
> I've seen.
Was that last line really necessary for your post?
The implicit looming flamewar here should be taken upstream. Fedora
policy is to follow upstream, wherever it may take us.
12:57 p.m.
On Friday, 05 December 2008 at 19:39, Callum Lerwick wrote:
On Fri, 2008-12-05 at 10:06 -0600, Arthur Pemberton wrote:
> On Fri, Dec 5, 2008 at 8:42 AM, Michael DeHaan <mdehaan(a)redhat.com> wrote:
> >
> > We're just now dealing with Python 2.6, but over on the radar is perhaps
one
> > of the most incompatible upgrades to the language we've seen in Python 3.
I
> > personally haven't tried it yet, but it /aims/ to be incompatble, which is
> > perhaps one of the most glaring signs a language designer has lost it that
> > I've seen.
>
>
> Was that last line really necessary for your post?
The implicit looming flamewar here should be taken upstream. Fedora
policy is to follow upstream, wherever it may take us.
Sure it is not to follow blindly. Talking with upstream about problems
and solutions will earn you extra points.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
1:25 p.m.
Callum Lerwick wrote:
>> We're just now dealing with Python 2.6, but over on the radar is perhaps one
>> of the most incompatible upgrades to the language we've seen in Python 3. I
>> personally haven't tried it yet, but it /aims/ to be incompatble, which is
>> perhaps one of the most glaring signs a language designer has lost it that
>> I've seen.
>
> Was that last line really necessary for your post?
The implicit looming flamewar here should be taken upstream. Fedora
policy is to follow upstream, wherever it may take us.
Just push the problems of changing API on regardless of the damage it
causes to users who will be running their own and 3rd party code?
The only reasonable way to ship changes that aren't backwards-compatible
once you have a user base is to allow multiple versions to run
concurrently so everyone can migrate their components separately and at
their own pace.
--
Les Mikesell
lesmikesell(a)gmail.com
3:42 p.m.
Arthur Pemberton wrote:
> We're just now dealing with Python 2.6, but over on the radar is perhaps one
> of the most incompatible upgrades to the language we've seen in Python 3. I
> personally haven't tried it yet, but it /aims/ to be incompatble, which is
> perhaps one of the most glaring signs a language designer has lost it that
> I've seen.
Was that last line really necessary for your post?
Incompatibility isn't a relative thing. More/most, etc., are irrelevant
because compatibility is a yes or no question. If you want a language
that you can expect to run your programs unchanged in the future, you
should have learned years ago that python wasn't it.
--
Les Mikesell
lesmikesell(a)gmail.com
12:32 p.m.
Michael DeHaan wrote:
This isn't a huge problem to those who are only developing on the latest
Fedora, per-se (other than getting over the initial hump), but it's
pretty bad for someone who wants to keep a single codebase across EL 4
(Python 2.3) and up, which I think a lot of us do. That gets to be
darn impossible and we have to double our involvement with code because
we essentially have to maintain a differently-compatible fork for each
project.
This is a problem that hasn't been brought up before. We can keep
Fedora going on python-2.6, 2.7 (and 2.8 if it occurs) and gradually
move code close to py3.x-ish syntax by using the "from __future__ import
*" mechanism. But that doesn't help with older distros running
python-2.5 or less. I don't believe there's anyway around that, though.
As we move to python-2.6+ w/ 3.x features we'll have this problem no
matter when we actually move to python-3. So we eventually (unless we
hold off on moving to python3 until python-2.6 is standard on all RHEL
releases) will be maintaining two trees of code no matter what.
If we maintain a python2 package and a python3 package in one version of
Fedora we'll have even more work. Right now we can have an EL-5 and
Fedora-9&10 package that are compatible with 2.5. A different version
can run on Fedora11 with the syntax ported to python-2.6's understanding
of what 3.x will be like. If we have both python2-2.6 and python3-3.0
in Fedora11 we'll have to maintain separate py2 and py3 packages for
every python module we ship as well. We should avoid this if we can.
Note that I think this decision is only partially within the powers of
the Fedora Project to decide. If 80% of our upstream libraries move to
py3, we'll need to move to py3 sooner. If 80% refuse to move off of
py2, we can take our time working on migration code.
-Toshio
12:40 p.m.
2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
Michael DeHaan wrote:
>
> This isn't a huge problem to those who are only developing on the latest
> Fedora, per-se (other than getting over the initial hump), but it's
> pretty bad for someone who wants to keep a single codebase across EL 4
> (Python 2.3) and up, which I think a lot of us do. That gets to be
> darn impossible and we have to double our involvement with code because
> we essentially have to maintain a differently-compatible fork for each
> project.
>
This is a problem that hasn't been brought up before. We can keep
Fedora going on python-2.6, 2.7 (and 2.8 if it occurs) and gradually
move code close to py3.x-ish syntax by using the "from __future__ import
*" mechanism. But that doesn't help with older distros running
python-2.5 or less. I don't believe there's anyway around that, though.
As we move to python-2.6+ w/ 3.x features we'll have this problem no
matter when we actually move to python-3. So we eventually (unless we
hold off on moving to python3 until python-2.6 is standard on all RHEL
releases) will be maintaining two trees of code no matter what.
If we maintain a python2 package and a python3 package in one version of
Fedora we'll have even more work. Right now we can have an EL-5 and
Fedora-9&10 package that are compatible with 2.5. A different version
can run on Fedora11 with the syntax ported to python-2.6's understanding
of what 3.x will be like. If we have both python2-2.6 and python3-3.0
in Fedora11 we'll have to maintain separate py2 and py3 packages for
every python module we ship as well. We should avoid this if we can.
Note that I think this decision is only partially within the powers of
the Fedora Project to decide. If 80% of our upstream libraries move to
py3, we'll need to move to py3 sooner. If 80% refuse to move off of
py2, we can take our time working on migration code.
-Toshio
Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
ensure that all code is compatible with 3. And still have 3 in
parallel for those who want it. So we target 2.6+ , but have 3.0 there
to ensure everything would work with it, and for early adopters/devs
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
12:45 p.m.
On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
ensure that all code is compatible with 3. And still have 3 in
parallel for those who want it. So we target 2.6+ , but have 3.0 there
to ensure everything would work with it, and for early adopters/devs
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
It would be very hard to write 2.6 code that is completely compatible
with 3.0, because 3.0 has changed many fundamental language constructs,
including even the "print" statement, which in 3.0 is a function (syntax
change).
I am not sure how far the from __future__ import feature will work for
such changes as that.
12:50 p.m.
On Fri, Dec 5, 2008 at 12:45 PM, Basil Mohamed Gohar
<abu_hurayrah(a)hidayahonline.org> wrote:
On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
> 2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
>
> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
> ensure that all code is compatible with 3. And still have 3 in
> parallel for those who want it. So we target 2.6+ , but have 3.0 there
> to ensure everything would work with it, and for early adopters/devs
>
> --
> Fedora 9 : sulphur is good for the skin
> ( www.pembo13.com )
>
It would be very hard to write 2.6 code that is completely compatible
with 3.0, because 3.0 has changed many fundamental language constructs,
including even the "print" statement, which in 3.0 is a function (syntax
change).
I believe 'print' is a poor example as it is very easy to fix. Are
there other, more problematic ones?
I am not sure how far the from __future__ import feature will work
for
such changes as that.
Neither am I.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
1:11 p.m.
Arthur Pemberton wrote:
On Fri, Dec 5, 2008 at 12:45 PM, Basil Mohamed Gohar
<abu_hurayrah(a)hidayahonline.org> wrote:
> On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
>> 2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
>>
>> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
>> ensure that all code is compatible with 3. And still have 3 in
>> parallel for those who want it. So we target 2.6+ , but have 3.0 there
>> to ensure everything would work with it, and for early adopters/devs
>>
>> --
>> Fedora 9 : sulphur is good for the skin
>> ( www.pembo13.com )
>>
> It would be very hard to write 2.6 code that is completely compatible
> with 3.0, because 3.0 has changed many fundamental language constructs,
> including even the "print" statement, which in 3.0 is a function (syntax
> change).
I believe 'print' is a poor example as it is very easy to fix. Are
there other, more problematic ones?
Yes, print is a poor example for the 2.6=>3.0 compatibility test (it is
a good example for 2.5=>3.0 compatibility, though, as there's no way to
redefine a keyword from within python.)
The problem area that I'm most aware of is unicode handling. There have
been some major improvements to this that make it more sane. However,
there's also been some regressions. Some of those regressions lead to
code that looks like it should work but silently fail to do what's
expected on *nix in some corner cases.
-Toshio
1:25 p.m.
2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
Arthur Pemberton wrote:
> On Fri, Dec 5, 2008 at 12:45 PM, Basil Mohamed Gohar
> <abu_hurayrah(a)hidayahonline.org> wrote:
>> On Fri, 2008-12-05 at 12:40 -0600, Arthur Pemberton wrote:
>>> 2008/12/5 Toshio Kuratomi <a.badger(a)gmail.com>:
>>>
>>> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
>>> ensure that all code is compatible with 3. And still have 3 in
>>> parallel for those who want it. So we target 2.6+ , but have 3.0 there
>>> to ensure everything would work with it, and for early adopters/devs
>>>
>>> --
>>> Fedora 9 : sulphur is good for the skin
>>> ( www.pembo13.com )
>>>
>> It would be very hard to write 2.6 code that is completely compatible
>> with 3.0, because 3.0 has changed many fundamental language constructs,
>> including even the "print" statement, which in 3.0 is a function
(syntax
>> change).
>
> I believe 'print' is a poor example as it is very easy to fix. Are
> there other, more problematic ones?
>
Yes, print is a poor example for the 2.6=>3.0 compatibility test (it is
a good example for 2.5=>3.0 compatibility, though, as there's no way to
redefine a keyword from within python.)
The problem area that I'm most aware of is unicode handling. There have
been some major improvements to this that make it more sane. However,
there's also been some regressions. Some of those regressions lead to
code that looks like it should work but silently fail to do what's
expected on *nix in some corner cases.
-Toshio
Fair enough. Think I'll shutup for now as there seem to be smarter
stakeholders involved than I. However, would just like to say that it
will be nice to have 3.0 in parallel (but not built against) as soon
as possible. Especially as Python is pushing a head in areas such as
web dev.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
1:11 p.m.
On Fri, 2008-12-05 at 20:45 +0200, Basil Mohamed Gohar wrote:
It would be very hard to write 2.6 code that is completely
compatible
with 3.0, because 3.0 has changed many fundamental language constructs,
including even the "print" statement, which in 3.0 is a function (syntax
change).
I am not sure how far the from __future__ import feature will work for
such changes as that.
Sigh...
from __future__ import print_function
...can everyone who isn't involved in writing python code, and/or not
read about 2.6 / 3.0 before this thread please not comment?
As Toshio Kuratomi said extremely well, in the grand parent to this
post:
Note that I think this decision is only partially within the
powers of the Fedora Project to decide. If 80% of our upstream
libraries move to py3, we'll need to move to py3 sooner. If 80%
refuse to move off of py2, we can take our time working on
migration code.
...so as I said, we don't have concrete plans yet ... and some of that
is because it depends on available resources within the project, but a
lot of that is because we have to follow upstream and it's not obvious
how fast (the majority of) python developers upstream will move.
--
James Antill <james(a)fedoraproject.org>
Fedora
5:30 p.m.
James Antill wrote:
On Fri, 2008-12-05 at 20:45 +0200, Basil Mohamed Gohar wrote:
> It would be very hard to write 2.6 code that is completely compatible
> with 3.0, because 3.0 has changed many fundamental language constructs,
> including even the "print" statement, which in 3.0 is a function (syntax
> change).
>
> I am not sure how far the from __future__ import feature will work for
> such changes as that.
>
Sigh...
from __future__ import print_function
...can everyone who isn't involved in writing python code, and/or not
read about 2.6 / 3.0 before this thread please not comment?
Not defined in older versions of python however, hence the need to
branch code, hence a problem with EPEL supporting code.
--Michael
As Toshio Kuratomi said extremely well, in the grand parent to this
post:
Note that I think this decision is only partially within the
powers of the Fedora Project to decide. If 80% of our upstream
libraries move to py3, we'll need to move to py3 sooner. If 80%
refuse to move off of py2, we can take our time working on
migration code.
...so as I said, we don't have concrete plans yet ... and some of that
is because it depends on available resources within the project, but a
lot of that is because we have to follow upstream and it's not obvious
how fast (the majority of) python developers upstream will move.
1:08 a.m.
On Sat, 2008-12-06 at 18:30 -0500, Michael DeHaan wrote:
Not defined in older versions of python however, hence the need to
branch code, hence a problem with EPEL supporting code.
True, 2.5.x and earlier won't be compatible. Which means that
RHEL-5/CentOS-5 python won't be compatible with any code that uses this
feature of py3k and/or 2.6.x (via. the from future import).
This is _far_ from unprecedented though, lack of decorators and/or
yield alone makes the python in RHEL-4/CentOS-4 incompatible for any
modern development. And I've had to upgrade boxes because of this, and
told a lot of people "Yeh, any recent yum just isn't going to work
there ... sucks".
This wasn't the end of the world then, and didn't mean we wanted/needed
to hold python back in Fedora. I don't see anything materially different
now.
--
James Antill <james(a)fedoraproject.org>
Fedora
12:51 p.m.
James Antill wrote:
On Sat, 2008-12-06 at 18:30 -0500, Michael DeHaan wrote:
> Not defined in older versions of python however, hence the need to
> branch code, hence a problem with EPEL supporting code.
>
True, 2.5.x and earlier won't be compatible. Which means that
RHEL-5/CentOS-5 python won't be compatible with any code that uses this
feature of py3k and/or 2.6.x (via. the from future import).
This is _far_ from unprecedented though, lack of decorators and/or
yield alone makes the python in RHEL-4/CentOS-4 incompatible for any
modern development. And I've had to upgrade boxes because of this, and
told a lot of people "Yeh, any recent yum just isn't going to work
there ... sucks".
That's a backwards compatibility example.
I'm talking about a break in forwards compatibility.
This wasn't the end of the world then, and didn't mean we
wanted/needed
to hold python back in Fedora. I don't see anything materially different
now.
(A) This is a different issue than the above. This is equivalent to
older Python targetting code not being run on the /new/, not newer code
running on the old.
Completely different problem.
(B) Nobody said the world was ending :)
1:04 p.m.
Arthur Pemberton wrote:
Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
ensure that all code is compatible with 3. And still have 3 in
parallel for those who want it. So we target 2.6+ , but have 3.0 there
to ensure everything would work with it, and for early adopters/devs
It is an oversimplification but how much is something we need experience
in order to discover. 2.6 != 3.x even though they are close. There
will be a 2.7 and a 3.1 and some of those problems should be addressed
in those two releases. Until we actually build experience trying to do
this, though, we don't know to what extent our work on making things
work on 2.6 will carry over to 3.x.
Note, the port we've just done to 2.6 is not all that's needed.
python-2.6 tries to have a 2.x mode and a 3.x mode (some changes are too
deep to truly have this but it tries). We'll have to start porting code
to 2.6 with 3.x features turned on at some point.
Also note, this is a valid plan for Fedora but it doesn't address
mpdehaan's issue with supporting python <= 2.5 (which I don't think is
solvable in any elegant manner.)
-Toshio
5:09 p.m.
Toshio Kuratomi wrote:
Arthur Pemberton wrote:
> Maybe I am oversimplifying. But what about using 2.6+ (<3.0) and
> ensure that all code is compatible with 3. And still have 3 in
> parallel for those who want it. So we target 2.6+ , but have 3.0 there
> to ensure everything would work with it, and for early adopters/devs
>
>
It is an oversimplification but how much is something we need experience
in order to discover. 2.6 != 3.x even though they are close. There
will be a 2.7 and a 3.1 and some of those problems should be addressed
in those two releases. Until we actually build experience trying to do
this, though, we don't know to what extent our work on making things
work on 2.6 will carry over to 3.x.
Note, the port we've just done to 2.6 is not all that's needed.
python-2.6 tries to have a 2.x mode and a 3.x mode (some changes are too
deep to truly have this but it tries). We'll have to start porting code
to 2.6 with 3.x features turned on at some point.
Also note, this is a valid plan for Fedora but it doesn't address
mpdehaan's issue with supporting python <= 2.5 (which I don't think is
solvable in any elegant manner.)
-Toshio
Exactly, it's not solvable in any elegant manner.
The parallel versions provides a solution for upstream, if at any point
at which we go from 2.X to 3.0 by dropping 2.X will cause us to lose a
lot of packages -- or lose package updates for EPEL as maintainers stop
being able to focus on that. Requiring an EPEL user to upgrade his
Python to use an app isn't going to happen -- that defeats most of the
points of stability for EL.
Source conversation cannot be mathematically proven and definitely
cannot be fully automated. It's a developers tool that results in two
separately maintained branches. For many applications this will be way
too much for developers, and they will continue to maintain one or the
other -- with differing preferences. (Upstream's goals aren't always to
work with a compatible Python version that we have in Fedora -- perhaps
it's an app who's main audience is EL 5 but also wants to work in
Fedora). For this, we really /do/ need the split versions.
I understand why this was shot down in the past. Then changes were
minor, now they are intentionally larger.
These have to be treated as two different languages, even if they are
95% similar. (Imagine if you will, Python 2.X and 3.X being chimp and
human, and Perl 5 and Perl 6 perhaps being archeopetryx and more
modern-day bird) -- they still cannot interbreed.
For those who have implied I haven't know about this, yes, I've known
about this, I've been writing Python code for at least 5-6 years. It's
just an excellent time to talk about it since it was just now
"released", so that we have a solid plan for now, and if we need to
start thinking incrementally we can.
I'm not so much trying to spell out doom, but we need to know what we
are going to do -- and more importantly -- what the impact on our
package list will be if we do something like drop 2.X.
--Michael
5668
days inactive
5673
days old
108 comments
30 participants
participants (30)
-
Arthur Pemberton -
Basil Mohamed Gohar -
Bill Nottingham -
Callum Lerwick -
Colin Walters -
Daniel P. Berrange -
Dominik 'Rathann' Mierzejewski -
Farkas Levente -
Horst H. von Brand -
Ignacio Vazquez-Abrams -
James Antill -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
Jon Ciesla -
José Abílio Matos -
Kevin Kofler -
Les Mikesell -
Matej Cepl -
Matthew Woehlke -
Michael DeHaan -
Nicolas Mailhot -
Peter Robinson -
Rahul Sundaram -
Richard Hughes -
Richard W.M. Jones -
Simo Sorce -
Stephen Warren -
Thorsten Leemhuis -
Toshio Kuratomi