HomeDistributionsSecurityCryptographyGamesFAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 12-05-2008, 01:42 PM
Michael DeHaan
 
Default The looming Python 3(000) monster

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 01:49 PM
"Jon Ciesla"
 
Default The looming Python 3(000) monster

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 01:51 PM
Matej Cepl
 
Default The looming Python 3(000) monster

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 01:52 PM
Basil Mohamed Gohar
 
Default The looming Python 3(000) monster

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 01:54 PM
Michael DeHaan
 
Default The looming Python 3(000) monster

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 01:56 PM
Michael DeHaan
 
Default The looming Python 3(000) monster

Well, this:

http://docs.python.org/3.0/library/2to3.html#to3-reference






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



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 01:57 PM
Ignacio Vazquez-Abrams
 
Default The looming Python 3(000) monster

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@gmail.com>

PLEASE don't CC me; I'm already subscribed
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 02:09 PM
"Richard W.M. Jones"
 
Default The looming Python 3(000) monster

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 02:09 PM
"Daniel P. Berrange"
 
Default The looming Python 3(000) monster

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-05-2008, 02:11 PM
"Richard W.M. Jones"
 
Default The looming Python 3(000) monster

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 09:16 AM.

VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org