The looming Python 3(000) monster

Daniel P. Berrange berrange at redhat.com
Tue Dec 9 10:33:36 UTC 2008


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




More information about the fedora-devel-list mailing list