A "mythical" version of the PythonLanguage that would break Python's backward compatibility. Some claim it happened with PythonV3, but in truth, the Zen of Python3000 has not been achieved. 

This page is for collecting and discussing the reasons why.  

To be included for Python3000:

* All methods which are guaranteed to return ''unique'' items should return a '''set''' (not a list) to communicate that. ''(GuidoVanRossum has acknowledged this one.)''
** the '''dir()''' built-in.
** locals(), globals()
* Use '''is''' for type checking rather than isinstance().  "if n is int and n>2: [...]"
**Add to PEP8: the python style guide. 
* Fix the relationship between '''bytes''', '''str''', and unicode.  (See thread in python-ideas re: bytestring type).  It's all forked up in Python3.
* Use '''&''' to indicate '''self'''-reference in class methods.  Dissipates the old argument for needing to type it.  See NameConceptualUnits.
* Use operator '''^''' rather than a function for super calls.
* Rename the built-in '''len()''' to '''size()''' to generalize to containers that aren't necessarily linear (as the name would imply).  A Tree for example.
* Bring back compares of unsimilar objects.  Double-quoted strings should be highest priority, and sets the lowest.  This is based on how the TuringMachine must relate to the underlying hardware.
* Make the File object more abstract.
** Create a '''File.pos''' attribute so you can rid of the confusing seek, tell and such.  Such an attribute allows easy ''relative'' indexing as well as ''absolute'' indexing.
** This removes the need for two separate and less obvious method names to 1) read the current file position and 2) move to a new file position.
** Providing a much more straightforward and obvious syntax for relative file movements:  file.position += 5
** Less dependency on low-level, C history.
** '''File.open()''', '''File.close'''(), '''File.closed''' could all be combined into a single File.open boolean property that can be read from to query the state of the file and written to (re-)open or close a file.  (There is actually no File.open() operation:  Python seems to require that you re-create the file object to re-open a file.)
** use '''del myfile''' to delete file object which will call '''__del__()''' method automatically. to do any cleanup.  Get's rid of '''finally''' because objects are already cleared after last reference is removed. 
* Specify an [unenforced] naming convention which asks for '''property''' and attribute names to be ''nouns'' so as to communicate that no visible changes are being made to the object. 
* Establish a convention to use attribute/properties instead of functions when there is 1) no need to pass any parameters and 2) the object will not be significantly transformed in some non-obvious way if/when the property is written to.  All such attributes/properties should have an adjective or noun name.
* Add to PEP 8: 
** Use ''verbs'' for functions, ''nouns'' for attr's.
** Specifying a naming convention for iterators, so there's no confusion vs. an actual Object. 
* With the new enumerate() builtin, could get rid of Dict.[iter]items().  
** "items" was always an ambiguous name for dict (key, value) pairs anyway.  enumerate() generalizes the concept to all collections (although since dict already had iteritems(), I don't think enumerate() handles the dict case).  
* '''Dict'''s should inherit from '''Set'''s. A dict is a ''set'' of '''name:object''' associations.
** dicts get a lot of additional and powerful functionality for little to no maintenance or performance or memory costs.
** no longer need separate method dict.update().
** coupled with the dir() builtin, now you can do quick class inspections when using other's code through set operators for a more populated DataEcosystem.
* An empty Set literal should be '''{}''' as any SetTheory''''''st can tell you. The empty Dict literal then is '''{:}'''. This becomes an even more obvious wart with dict inheriting from sets.
* D''''''efaultDict should take an optional '''collision function''' to be called when keys are the same.
** Many home-spun data types can be reduced to a single, flexible type. An edge-weighted graph becomes trivial.
** As Python evolves a UnifiedDataModel, this will replace the current Dict.
** This resolves a long-standing debate about what to do with key collisions on dict.update() -- let the user decide.
* Use the C construct of switch...case, rather than series of if/then/elseifs.
* Remove the range() built-in and use the ellipsis ("...") to give a less ambiguous, more conventional looping and ranging construct.
* '''DocTest''' should be integrated into the interpreter environment and a '''test()''' built-in added to complement help(), encouraging TestDrivenDevelopment.
** As people get used to TDD and AgileDevelopment, it will become a no-brainer to check random python files in a directory: just "python someoldwork.py" and see if it's in working order.
** Python will read the starting directory's __new__.py (name?) file to set the execution context for all code run in the interpreter. Since TestingIsDocumentation, this file could be called README.
** Doctests improved to support lexical scoping context, so that setup code can be placed in Class doctests and used within inner methods, for example. (Variables at module-scope can be used in class doctests.)  This would remove a lot of pollution out of help(), removing one gripe of resistance to using DocTest:  pollutions of DocStrings.
** No need for a Python startup file anymore, just put your python code in a textfile, put the file in your home directory and that's your __builtin__ module's docstring.
* All the built-ins should be organized in their own NameSpace and placed in a tree. Devs can create their own NameSpace''''''s and export them to the interpreter environment.
**Exceptions shouldn't be intermingled with functions for example and math functions can be logically separated from non-math functions.
** Need to think through how to do this right and interact with the abstraction model in coordination with the FileSystem and Python's environment properly.
* Consider integrating VPython in the standard library (import __future__).
** VPython has Wx windowing system integrated with it, a cross-platform, flexible GUI library.
** Many young programmers are drawn into a language by graphics -- you can't beat 3d.
** The scientific community comes for free. ;-)
* Return the type/class distinction so that the ObjectModel isn't so abstract.
** The GodObject "Object" was the wrong direction. We're not close enough to God to make everything derive from Object properly.  See ClosuresConsideredHarmful.
** Let's get back to the roots and build up objects from the bottom, not the top.
** Automatic conversion from int to longs seemed good enough. See ObjectOrientedRefactored.
* The Super() business needs re-vamped for this more concrete ObjectArchitecture.
** Use a caret "^" operator, which is clear syntax for super calls.
** Composed classes should have mandatory super calls, for example.
** One now follows the logical order of combining smaller types + methods to make bigger objects. Notice how this former OOP trajectory of EverythingIsAnObject has confused us?
** Discuss at UnifiedObjectModel
* '''dir()''' could probably be integrated with '''help()''' so as to reduce pollution of namespace.  (Perhaps help(Object, verbose=True))
* '''Implement the guidelines under ObjectOrientedRefactored'''. Specifically:
** A universal query-state operator: '''?myObject''' (which also functions as a '''print''' function).
** A universal MessagePassing syntax: '''data >> myObject'''
*** "data" can be an atomic element or a stream of such, represented by a tuple.
*** "data" in a tuple is processed (strictly) ''serially''.
*** Data that cannot be processed by the Object will be spit out with a DataError Exception (akin to a parameter type error). The state of that object could be suspended at that point (waiting for the operator), or valid data elements can continue, in order.
*** Makes a consistent interface for collection objects:  Node >> myGraph, element >> myList, myStack >> (outputs next element of stack)
** This will make a language-supported specification for interfacing with '''all''' objects.  No more learning object interfaces.  The name should be self-documenting and the methodology will encourage good DocString''''''s.
** ObjectModelExample
* Implement the new keywords of the Vigil programming language for code contracts. (see http://GitHub.com/munificent)
** Don't delete bad code, though, put it in a Purgatory object (the only good use of global). 
** Get rid of '''finally''' keyword to make space for two new keywords:  '''implore''' and '''swear''' for DesignByContract.
* Solve the conceptual separation between str() and repr(), '''one of them is redundant''' or '''too ambiguous'''.
** Str should perhaps be dropped to be replaced by the state-query operator.
*** The state of immutable objects {string, tuple} is its contents ''sans'' its container characters (?"This string" --> This string)
*** The state of mutable collections {set, dict, list, ...} retain their grouping characters since their ownership can't be verified.
** Repr should give an output that can be used to rebuild the object; i.e. full type information. -- In fact, the object shouldn't mess with this, so get rid of it as a special method.
* ?Consider reinstating __cmp__ as a general comparison method. Remove the excess syntax of __le__, __gt__, __eq__, (but check if there's an optimization for __eq__ that make this desirable)
* Rewrite the standard library using the new MessagePassing syntax from ObjectOrientedRefactored.
* Data members in a Class definition could be declared, just like methods and allow an optional DocString that describes what it's for. SelfDocumentingCode rocks.
** No more undocumented data members in help() class inspections!
* Consider capitalization of keywords, to distinguish them visually from variable names 
** Would allow reuse of keywords for variable names:  ex. SORT as a keyword vs. sort as a variable name)


Full disclaimer, this is all towards LanguageIsAnOs and UnifiedDataModel, possibly to take over the world. -- MarkJanssen

----
See also InternetTwo, PythonThreeIsNotPythonThreeThousand
----
CategoryPython