Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties

Voor het eerst sinds 1991 zal er een nieuwe versie van Python worden uitgebracht die niet met oudere varianten compatibel is. 'Python 3000' moet volgend jaar verschijnen.

De Python Software Foundation, de organisatie die Pythons intellectueel eigendom bewaakt en promoot, heeft deze week bekendgemaakt dat er volgend jaar twee nieuwe versies van de taal zullen verschijnen. Om te beginnen zal rond februari een bèta van Python 2.6 worden uitgebracht. Deze 'overgangsversie' is bedoeld om programmeurs de kans te geven om te ontdekken of hun software compatibel met de nieuwe taalvariant is. Versie 3.0 van de taal, die ook wel bekend staat als Python 3000, zou volgens de planning in augustus moeten verschijnen.

Python 3.0 krijgt onder andere nieuwe I/O-libraries om cross-platformontwikkeling makkelijker te maken, en ondersteuning voor internationalisering. Ook wordt van het 'print'-statement een functie gemaakt. 'We grijpen de nieuwe versie aan om de problemen met het ontwerp uit 1991 op te lossen en tegelijkertijd wat scherpe randjes weg te halen', vertelde David Goodger, een van de directeuren van de Foundation.

Om programmeurs te helpen met het omzetten van 2.5- of oudere code naar de nieuwe versie, verschijnt er een tooltje dat het leeuwendeel van het conversiewerk kan uitvoeren. Omdat Python een opensourcetaal is, zijn er diverse varianten van andere partijen op de markt, zoals IronPython en Jython. Of en wanneer deze talen worden aangepast is nog niet bekend. Lead developer Guido van Rossum zal Python 3.0 tijdens de PyCon-conferentie in maart officieel presenteren.

Moderatie-faq Wijzig weergave

Reacties (36)

Meer ontwikkelaars zouden het lef moeten hebben backwards compatibility overboord te gooien, dat zou een hoop problemen, vertragingen en performance verlies voorkomen.
Ja dat is vooral handig in een omgeving waar veel legacy draait. Leuk voor een taal als python, maar dit moet je niet bij een taal als java/c(#) ineens gaan doen.
Je hoeft niet mee te gaan naar een nieuwe versie van een programmeertaal (=compiler/interpreter). Je kan natuurlijk ook gewoon door blijven ontwikkelen in de versie die je al hebt.
Dan zou je er alsnog voor kunnen kiezen om nieuwe spullen met de nieuwe versie te maken.
Waarom wel voor python en niet voor java/c(#)? Heeft python minder legacy?
Ja dat is vooral handig in een omgeving waar veel legacy draait. Leuk voor een taal als python, [..]
Je onderschat hoeveel legacy Python er al draait. Bovendien blijft men meestal op de oude versie van de JVM of interpreter hangen, omdat een nieuwe wel backwards compatible zou moeten zijn, maar dat soms niet is. Of er is om bugs heengewerkt, die in een nieuwe versie opeens opgelost zijn. Zo is de code alsnog afhankeljk van een specifieke platformversie.

Java zou net zo goed (of slecht) als Python een stap zonder backwards compatability kunnen maken.
Van versie 1.4 naar 1.5 (Java 5) is toch wel een dusdanige groot verschil dat het moeilijk (niet mogelijk) is om java1.5 sources te compileren voor voor 1.4.
Daar hebben ze al een grote wijziging gemaakt.

Verder zijn de deprecated tags die aangeven dat het mogelijk in de toekomst niet meer geimplementeerd wordt. Ik weet niet hoeveel deprecated API's in 1.4 al niet meer in 1.5 voorkomen.
Compatibiliteit is er maar in één richting: oude code werkt nog op de nieuwe versie. Dus Java 1.4 code werkt zonder wijzigingen op Java 5 en 6. Maar omgekeerd is dat natuurlijk niet het geval. De Java 1.4 compiler kent al die nieuwe features van Java 5 natuurlijk niet.

Dat is niet alleen zo bij Java, maar ook bij C#, Python en alle andere talen.

Het artikel gaat erover dat oude Python software niet zomaar meer zal werken op de nieuwe versie.

In Java zijn er inmiddels een aantal dingen "deprecated" in de API maar die blijven erin zitten omdat oude software die er gebruik van maakt anders ineens niet meer zal werken.

Je moet compatibiliteit oud -> nieuw en nieuw -> oud niet met elkaar verwarren.
Zowel voor java als c# geldt dat nieuwere versies niet geheel backwards compatible zijn. Als oplossing geld voor beide dat je meerdere versies van het framework tegelijk kunt draaien, waardoor het nooit een probleem is. Ik neem aan dat dat ook voor Java geldt.
Is het niet ook zo dat Python niet gecompileerd wordt? Java en C# wel, en daarbij kan de compiler er dus voor zorgen dat nieuwe syntax mogelijk is. Al die nieuwe C# 3.0 constructies bijvoorbeeld, dat wordt allemaal gecompileerd naar dezelfde MSIL als C# 2.0 code, en draait gewoon op de 2.0 versie van de runtime.
> Is het niet ook zo dat Python niet gecompileerd wordt?

Nee hoor, wordt gecompileerd naar bytecode.

Als je wil zelfs naar Java bytecode (Jython) of .NET bytecode (IronPython).
Ho, dat is niet waar :)
C# 3.0 is zeker wel anders dan C#2.0.

Het kan zijn dat je in de war bent met .Net 2.0 en 3.0.
.Net 3.0 gebruikt dezelfde C# versie dan .Net 2.0 , namelijk C# 2.0.
.Net 3.5 daarintegen gebruikt C# 3.0, wat zeker wel een hele andere versie is dan 2.0.

Lekker duidelijke versienummering houden ze er bij MS op na.
.Net 3.5 met VB9 en C# 3.0 :P
Goeie ontwikkeling vind ik persoonlijk. In het grootste deel van de talen / implementaties zitten er wel ontwerpfoutjes / slordigheden of gebrek aan uniformiteit die nooit 'gerepareerd' worden om maar backwards compatible te blijven.

Denk maar aan Java's System.currentTimeMillis() vs System.nanoTime() - ze doen nagenoeg hetzelfde (in een andere eenheid), maar de naamgeving is heeel anders.

Ze (niet alleen Java maar ook de andere programmeerlibrarybouwers) zouden er mijns insziens goed aan doen om de oude / slordige stukken 'deprecated' te maken en een nieuwe versie aanwijzen in een volgende versie, om vervolgens in de versie daarop het geheel te verwijderen.
Dat gebeurt soms ook al, kijk bijvoorbeeld maar in de java api: http://java.sun.com/javase/6/docs/api/

Neem Component maar ns als voorbeeld.
Ja, maar de 'deprecated' dingen worden niet verwijderd, want dan zouden oude Java programma's niet meer werken op de nieuwe versie. En zo groeit het langzaam met steeds meer oude 'deprecated' zooi.

Sun zou alle 'deprecated' onderdelen moeten weglaten uit de documentatie, dan en ergens een apart hoekje moeten maken met de documentatie van de 'deprecated' onderdelen.
Is er al een lijst met features die te verwachten zijn?
Nog geen complete feature list. Je kunt al wel de lijst met voorstellen bekijken op http://www.python.org/dev/peps/. (PEP 3000-3999).
Daar ben ik het wel mee eens maar het lijkt me ook niks om 5 verschillende python versies op m'n computer te hebben staan omdat niet elk programma zich heeft aangepast voor een nieuwere python versie.
Dat zal wel gaan meevallen lijkt mij, maar je hebt inderdaad altijd dit soort ongemak bij het verlaten van backwards-compatibility. M.I. is dit echter de enige manier om de hele bups te verbeteren en voor veel voordelen te zorgen in de nabije toekomst. Zou met Windows ook moeten gebeuren, dan weet de consument in ieder geval duidelijk dat er niks meer zomaar gaat werken. :)
Dat gaat met windows niet gebeuren, want dan verliest windows z'n enige voordeel ten opzichte van andere OS'en: het kunnen draaien van de grote sloot beschikbare windows software.
In tegendeel: Dit is juist gebeurd met de introductie van Windows Vista: Veel oude soft- en hardware functioneert niet meer. Mijn inziens illustreert dit een belangrijk aspect waarin open source veel beter is dan closest en proprietary source: Met bv. Python heb je de <i>keuze</i> om de oude versie gewoon te blijven gebruiken, naast een nieuwe versie. Met bijvoorbeeld Windows heb je amper zo'n keuze: Het aanbod van nieuwe computers met Windows XP is erg beperkt. En Windows 2000 is bij mijn weten helemaal niet meer beschikbaar, terwijl ik regelmatig computers tegenkom die het met Windows 2000 prima zouden kunnen doen.

Een ander voorbeeld is Office 2007: Slikken of stikken, want oudere versies van Office zullen steeds minder beschikbaar zijn.

Ik denk dat de introductie van Vista en Office 2007 het beste is wat FOSS in lange tijd is overkomen.
Voor de mensen die zich afvragen wat er precies nieuw is in 3.0:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
Ik vind dit eerlijk gezegd een goede ontwikkeling, ik heb nl. altijd al een paar vreemde puntjes aan python gevonden, waaronder de in het artikel genoemde print-statement.

Jammer dat dit ten koste gaat van backwards-compatibility, maar door die compatibility te houden krijg je alleen maar steeds lelijkere ontwerpen en hacks in de taal zelf, en dat is niet wat we moeten hebben he :)
Beetje zoals PHP dus :P

Maarre, wel gewaagd hoor. Een update die niet backwards compatible is is toch een beetje vloeken in de kerk. Zal wel de nodige kritiek op komen denk ik.
Hoofdversies (1.x, 2.x en nu 3.x) van Python zijn altijd bedoeld geweest om in beperkte mate (waar dat nodig is om Python beter te kunnen maken) de achterwaartse compatibiliteit te kunnen breken.

Verder zal versie 2.6 waarschuwingen kunnen geven in de meeste gevallen waar bepaalde code niet zou werken in 3.0, en is er daarnaast ook een conversie-programma dat 2.x-code omzet naar 3.0-code.
Toch grappig om te zien dat Python weer iets populairder aan het worden is. Toch een stukje nederlands technologisch goed. Als je bedenkt dat YouTube voor een groot gedeelte op python draait, dan zal python voorlopig nog een belangrijke speler in de developers-wereld blijven. :)
Niet alleen YouTube maakt veel gebruik van Python, maar ook een van de grootste softwarebedrijven ter wereld: Google.
wat dacht je van django, erg fijn frameworkje
Wat is het verschil tussen YouTube en Google?
Dat YouTube van Google is en Google niet van YouTube :z
Ook een hoop pakketen in Linux maken ervan gebruik.
De Sugar interface van OLPC hebben we ook helemaal in Python ontwikkeld.
soms moet je met je tijd mee.

door vast te houden tot 17 jaar terug met compatibel willen zijn met toen hou je ook vast aan oude denk en werkwijze. je leert tenslotte ook niet meer schoonschrijven op school. voor de jonkies die dat niet weten, voeg burn of domme opmerking hierna in . of vraag het papa of mama.
Je ziet zulke talen toch echt wel subtiel leentjebuur spelen tot ze langzaamhand mergen in één.

Zo past het vervangen van de print-statement door een functie perfect bij de Ruby-ideologie: everything is a message.
Ik haat statements. Het zijn blackboxes, ingebouwde functionaliteit van de taal zelf maar vaak enorm onflexibel.
Idem dito voor primitieve datatypes.
'print' is geen blackbox in python, het is syntactic sugar voor 'sys.stdout.write()' of .write() op het het file-object dat gegeven wordt na '>>'.

Zie ook: http://docs.python.org/ref/print.html
Prima stap om backward compatibiliteit op te geven als de taal daar beter van wordt. Nu maar hopen dat iedereen naast de source-code, ook de compiler en build tools in zijn versiebeheersysteem gezet heeft. Iets wat ik bij de meeste bedrijven - helaas - niet zie gebeuren!

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True