Python 3 - Revision history

Zundark: fix section link

2017-04-18T08:19:20Z

fix section link

← Previous revision		Revision as of 08:19, 18 April 2017
Line 1:		Line 1:
	#REDIRECT [[History of Python#Version 3.0]]		#REDIRECT [[History of Python#Version 3]]

Jarble: ←Redirected page to History of Python#Version 3.0

2014-01-10T02:21:01Z

←Redirected page to History of Python#Version 3.0

← Previous revision		Revision as of 02:21, 10 January 2014
Line 1:		Line 1:
	#REDIRECT [[Python ~~(programming language)~~]] ~~{{R from merge}}~~		#REDIRECT [[History of Python#Version 3.0]]

TJRC: rm anchor

2009-03-09T14:03:22Z

rm anchor

← Previous revision		Revision as of 14:03, 9 March 2009
Line 1:		Line 1:
	#REDIRECT [[Python (programming language)~~#Version 3.0~~]] {{R from merge}}		#REDIRECT [[Python (programming language)]] {{R from merge}}

TJRC: Undid revision 275981035 by 2Q (talk)

2009-03-09T14:03:00Z

Undid revision 275981035 by 2Q (talk)

← Previous revision		Revision as of 14:03, 9 March 2009
Line 1:		Line 1:
	#REDIRECT [[~~Python_~~(~~missile~~)]]		#REDIRECT [[Python (programming language)#Version 3.0]] {{R from merge}}

2Q: ←Redirected page to Python (missile)

2009-03-09T06:23:20Z

←Redirected page to Python (missile)

← Previous revision		Revision as of 06:23, 9 March 2009
Line 1:		Line 1:
	#REDIRECT [[~~Python~~ (~~programming language~~)~~#Version 3.0~~]] ~~{{R from merge}}~~		#REDIRECT [[Python_(missile)]]

Edward: ←Redirected page to Python (programming language)#Version 3.0

2008-12-10T08:31:40Z

←Redirected page to Python (programming language)#Version 3.0

← Previous revision		Revision as of 08:31, 10 December 2008
Line 1:		Line 1:
	#REDIRECT [[Python (programming language)#~~Future~~ ~~development~~]] {{R from merge}}		#REDIRECT [[Python (programming language)#Version 3.0]] {{R from merge}}

Vl'hurg: Merge to Python (programming language)#Future development

2007-11-15T12:05:59Z

Merge to Python (programming language)#Future development

← Previous revision		Revision as of 12:05, 15 November 2007
Line 1:		Line 1:
	~~{{Mergeto\|~~Python (programming language)~~\|Talk:Python 3~~#~~Merge\|date=July~~ ~~2007~~}}		#REDIRECT [[Python (programming language)#Future development]] {{R from merge}}
	{{Otheruses4\|the programming language\|the missile\|Python (missile)}}

	'''Python 3''', an [[Interpreter (computer software)\|interpreted]] [[programming language]], is currently being developed by [[Guido van Rossum]]. It will be fully [[dynamic typing\|dynamically typed]] and use [[memory management\|automatic memory management]], as the [[Python (programming language)\|current version]]. It is thus similar to [[Perl]], [[Ruby programming language\|Ruby]], [[Scheme (programming language)\|Scheme]], [[Smalltalk]], and [[Tcl]]. [[Python (programming language)\|Python]] is developed as an [[open source]] project, managed by the non-profit [[Python Software Foundation]].

	{{Infobox programming language
	\|name = Python 3
	\|logo = [[Image:Python logo.svg\|150px]]
	\|paradigm = Multi-paradigm
	\|year
	\|designer = [[Guido van Rossum]]
	\|developer = [[Python Software Foundation]]
	\|latest_release_version
	\|latest_release_date
	\|typing
	\|implementations
	\|dialects =
	\|influenced_by
	\|influenced
	\|operating_system = [[Cross-platform]]
	\|license = [[Python Software Foundation License]]
	\|website = [http://www.python.org/dev/peps/pep-3000/ www.python.org]
	}}

	==Philosophy==
	Python 3 is being developed with the same philosophy as in prior versions, so any reference to [[Python philosophy]] will apply to Python 3 as well. However, as Python has accumulated new and redundant ways to program the same task, Python 3 has an emphasis on removing duplicative constructs and modules, in keeping with "There should be one—and preferably only one—obvious way to do it".

	Nonetheless, Python 3 will remain a [[Multi-paradigm programming language\|multi-paradigm language]]. Coders will still have options among [[object orientation]], [[structured programming]], [[functional programming]], and [[aspect-oriented programming]] and other paradigms; but within such broad choices, the details are intended to be more obvious in Python 3 than they have become in Python 2.x.

	==History==
	:''See article: [[Python (programming language)#History\|Python programming language]]''

	==Python 3==
	===Naming===
	'''Python 3''' (or more formally, for the initial release, Python 3.0), Python 3000, and Py3K are all names for the upcoming version of the [[Python (programming language)\|Python programming language]]. The project is called Python 3000, or abbreviated as Py3k. Once released, it will be officially referred to as Python 3.0, which is what "python3.0 -V" will print; the actual file names will use the same naming convention used for Python 2.x. There won't be a new name for the executable, and the suffix for Python source files will remain the same.

	===Timeline===
	Python 3.0a1, the first alpha release of Python 3.0, was released on [[August 31]], [[2007]].<ref>[http://python.org/download/releases/3.0/ Python 3.0a1 Release]</ref> The following updates are anticipated:
	# December 2007: release 2.6a1.
	# April 2008: full feature freeze.
	# June 2008: release 2.6 (final).
	# August 2008: release 3.0 (final).

	Parallel Python 2.x and 3.x releases are expected to exist for some time; the Python 2.x releases continuing for a longer time than the traditional 2.x.y bugfix releases. Typically, there are no further bugfix releases for version 2.x once version 2.(x+1) is released, but there are expected to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extent depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteer stamina. It's quite possible that Python 3.1 and 3.2 will be released much sooner after 3.0 than has been customary for the 2.x series. The 3.x release pattern will stabilize once the community is happy with 3.x.<ref>[http://www.python.org/dev/peps/pep-3000/ PEP 3000]</ref>

	===Compatibility and transition===
	Like [[Perl 6]], Python 3 will break [[backward compatibility]]. There is no requirement that Python 2.x code will run unmodified on Python 3.0. There are basic changes such as changing the print statement into a print function (so any use of the print statement will cause the program to fail), and switching to Unicode for all text strings. Python's [[dynamic typing]] combined with the plans to change the semantics of certain methods of dictionaries, for example, makes perfect [[source-to-source compiler\|mechanical translation]] from Python 2.x to Python 3.0 very difficult. However, a tool called "2to3" does most of the job of translation, pointing out areas where it wasn't sure using comments or warnings. Even in an alpha stage 2to3 appears to be fairly successful at performing the translation.<ref>Sam Ruby, [http://intertwingly.net/blog/2007/09/01/2to3 2to3], September 1, 2007</ref>

	Python 2.6 will include forward compatibility features, as well as a "warnings" mode that will warn of potential transition problems. Warnings will be reported for builtins which will no longer exist in 3.0
	(apply, callable, coerce, dict.has_key, execfile, reduce, and reload), as well as various old Python 2.x features that Python 3.0 will remove (see [http://www.python.org/dev/peps/pep-0361/ PEP 361] for more information).

	[http://www.python.org/dev/peps/pep-3000/ PEP 3000] recommends the following transition approach, once Python 2.6 is available:
	# Have excellent unit tests with close to full coverage.
	# Port your project to Python 2.6.
	# Turn on the Py3k warnings mode.
	# Test and edit until no warnings remain.
	# Use the 2to3 tool to convert this source code to 3.0 syntax. Do not manually edit the output!
	# Test the converted source code under 3.0.
	# If problems are found, make corrections to the 2.6 version of the source code and go back to step 3.
	# When it's time to release, release separate 2.6 and 3.0 tarballs (or whatever archive form you use for releases).

	===What's new===
	Plans for Python 3 include:
	* Changing "print" so that it is a built-in function, not a statement. This makes it easier to change a module to use a different print function, as well as making the syntax more regular. In Python 2.6 this can be enabled by entering "from __future__ import print_function". See [http://www.python.org/dev/peps/pep-3105/ PEP 3105] for more information.
	* Renaming the old "raw_input" function (which reads in a line) into "input"; the old rarely-used "input" function (which reads and executes a line) has been removed as a built-in function. The old "input" could produce security problems, since developers new to the language might use "input" when they meant to use "raw_input".
	* Moving ''reduce'' (but not ''map'' or ''filter'') out of the built-in namespace and into functools (the rationale being that ''reduce'' is expressed more clearly as an accumulation loop)[http://www.artima.com/weblogs/viewpost.jsp?thread=211200];
	* Adding support for optional function annotations that can be used for informal type declarations or other purposes[http://www.python.org/dev/peps/pep-3107/];
	* Unifying the <code>str</code>/<code>unicode</code> types, and introducing a separate immutable <code>bytes</code> type; and a mostly corresponding mutable <code>buffer</code> type <ref>[http://www.python.org/dev/peps/pep-3137/ PEP 3137]: Immutable Bytes and Mutable Buffer</ref>
	* Converting built-ins to returning [[iterators]] (instead of lists), where appropriate;
	* Removing backward-compatibility features like old-style classes, classic (integer truncating) division, string exceptions, and implicit relative imports.

	===Python Enhancement Proposal numbering===
	Python 3000 PEPs are numbered starting at PEP 3000. PEPs 3000-3099 are meta-PEPs—these can be either process or informational PEPs. PEPs 3100-3999 are feature PEPs. PEP 3000 itself is special; it is the meta-PEP for Python 3000 meta-PEPs (it describes the process to define processes). PEP 3100 is also special; it's a laundry list of features that were selected for (hopeful) inclusion in Python 3000 before formal Python 3000 development began. PEP 3099 is a list of features that will not change (but which several people asked about).

	==References==
	<references/>

	== See also ==
	{{portal\|Free software\|Free Software Portal Logo.svg}}

	* [[Comparison of programming languages]]
	* [[Scripting language#General-purpose dynamic languages\|General-purpose dynamic languages]]

	==External links==
	* [http://www.python.org/dev/peps/pep-3000/ Python 3000 PEP index]
	* [http://wiki.python.org/moin/ Python Wiki]
	* [http://www.artima.com/weblogs/viewpost.jsp?thread=98196 The fate of reduce() in Python 3000]
	* [http://www.artima.com/weblogs/viewpost.jsp?thread=208549 Guido van Rossum blog: Python 3000 Status Update (19 June 2007)]
	* [http://video.google.com/videoplay?docid=-6459339159268485356 Guido van Rossum video, talking about Python 3000's features and philosophy.]
	* [http://www-03.ibm.com/developerworks/blogs/page/davidmertz?entry=second_day_python_3000 Report on Guido van Rossum's presentation on Python 3.0] at [[OSCON\|OSCon 2006]].

	[[Category:Class-based programming languages]]
	[[Category:Dynamically-typed programming languages]]
	[[Category:Free compilers and interpreters\|Python 3]]
	[[Category:Object-oriented programming languages]]
	[[Category:Python programming language]]
	[[Category:Scripting languages]]
	[[Category:Unix software]]
	[[Category:Upcoming software]]

Lulu of the Lotus-Eaters: copying relevant public domain material is not improper

2007-11-14T00:23:34Z

copying relevant public domain material is not improper

← Previous revision		Revision as of 00:23, 14 November 2007
Line 70:		Line 70:
	* Removing backward-compatibility features like old-style classes, classic (integer truncating) division, string exceptions, and implicit relative imports.		* Removing backward-compatibility features like old-style classes, classic (integer truncating) division, string exceptions, and implicit relative imports.

			===Python Enhancement Proposal numbering===

			Python 3000 PEPs are numbered starting at PEP 3000. PEPs 3000-3099 are meta-PEPs—these can be either process or informational PEPs. PEPs 3100-3999 are feature PEPs. PEP 3000 itself is special; it is the meta-PEP for Python 3000 meta-PEPs (it describes the process to define processes). PEP 3100 is also special; it's a laundry list of features that were selected for (hopeful) inclusion in Python 3000 before formal Python 3000 development began. PEP 3099 is a list of features that will not change (but which several people asked about).

	==References==		==References==

E946: /* Python Enhancement Proposal numbering */ Copy/pasted directly from the official python3k page. There are several places elsewhere where bits and pieces were obviously copied as well.

2007-11-13T19:48:50Z

Python Enhancement Proposal numbering: Copy/pasted directly from the official python3k page. There are several places elsewhere where bits and pieces were obviously copied as well.

← Previous revision		Revision as of 19:48, 13 November 2007
Line 70:		Line 70:
	* Removing backward-compatibility features like old-style classes, classic (integer truncating) division, string exceptions, and implicit relative imports.		* Removing backward-compatibility features like old-style classes, classic (integer truncating) division, string exceptions, and implicit relative imports.


	===Python Enhancement Proposal numbering===
	Python 3000 PEPs are numbered starting at PEP 3000. PEPs 3000-3099 are meta-PEPs—these can be either process or informational PEPs. PEPs 3100-3999 are feature PEPs. PEP 3000 itself is special; it is the meta-PEP for Python 3000 meta-PEPs (it describes the process to define processes). PEP 3100 is also special; it's a laundry list of features that were selected for (hopeful) inclusion in Python 3000 before formal Python 3000 development began. PEP 3099 is a list of features that will not change (but which several people asked about).

	==References==		==References==

Mykhal: /* Compatibility and transition */ visual basic -> perl

2007-11-09T16:29:03Z

Compatibility and transition: visual basic -> perl

← Previous revision		Revision as of 16:29, 9 November 2007
Line 45:		Line 45:

	===Compatibility and transition===		===Compatibility and transition===
	Like [[~~Visual~~ ~~Basic .NET#Relation to Visual Basic\|Visual Basic .NET~~]], Python 3 will break [[backward compatibility]]. There is no requirement that Python 2.x code will run unmodified on Python 3.0. There are basic changes such as changing the print statement into a print function (so any use of the print statement will cause the program to fail), and switching to Unicode for all text strings. Python's [[dynamic typing]] combined with the plans to change the semantics of certain methods of dictionaries, for example, makes perfect [[source-to-source compiler\|mechanical translation]] from Python 2.x to Python 3.0 very difficult. However, a tool called "2to3" does most of the job of translation, pointing out areas where it wasn't sure using comments or warnings. Even in an alpha stage 2to3 appears to be fairly successful at performing the translation.<ref>Sam Ruby, [http://intertwingly.net/blog/2007/09/01/2to3 2to3], September 1, 2007</ref>		Like [[Perl 6]], Python 3 will break [[backward compatibility]]. There is no requirement that Python 2.x code will run unmodified on Python 3.0. There are basic changes such as changing the print statement into a print function (so any use of the print statement will cause the program to fail), and switching to Unicode for all text strings. Python's [[dynamic typing]] combined with the plans to change the semantics of certain methods of dictionaries, for example, makes perfect [[source-to-source compiler\|mechanical translation]] from Python 2.x to Python 3.0 very difficult. However, a tool called "2to3" does most of the job of translation, pointing out areas where it wasn't sure using comments or warnings. Even in an alpha stage 2to3 appears to be fairly successful at performing the translation.<ref>Sam Ruby, [http://intertwingly.net/blog/2007/09/01/2to3 2to3], September 1, 2007</ref>

	Python 2.6 will include forward compatibility features, as well as a "warnings" mode that will warn of potential transition problems. Warnings will be reported for builtins which will no longer exist in 3.0		Python 2.6 will include forward compatibility features, as well as a "warnings" mode that will warn of potential transition problems. Warnings will be reported for builtins which will no longer exist in 3.0