Differences between revisions 21 and 22
Revision 21 as of 2005-07-05 11:30:43
Size: 8153
Editor: ti300710a080-1032
Comment: Example on why not to remove callable()
Revision 22 as of 2005-07-05 12:54:40
Size: 8637
Editor: ti300710a080-1032
Comment: Argument aginst disallowing class method calls
Deletions are marked like this. Additions are marked like this.
Line 80: Line 80:
I disagree to this. Although calling class methods on the instance from the outside will usually be rubbish, it will very often be useful and intended behavour inside instances. For example:
{{{
class mydict(dict):
  def key_copy(self):
    return self.fromkeys(self)
}}}

This will assert that whatever subclass of mydict is created and not some other class. One could argue though that this could be achieved by the more cluttersome {{{self.__class__.fromkeys()}}}.

Other syntax ideas and feature ideas for ["Python3.0"] .

TableOfContents()

Optional Static Typing / Adaptation

Lambda / Anonymous Methods / Closures

".." Sequences, Custom Infix Operators

Improved default value logic for Dictionaries

  • The setdefault() method is badly named and poorly designed. In a typical call, d.setdefault.(k, []).append(v), the list may be unnecessarily instantiated and discarded on every call. At a minimum, default value should be a new empty list instead of None:  d.setdefault(k).append(v) .

  • A more versatile idea is to realize that defaults generalize to the whole dictionary instead of an individual lookup. A call to setdefault would then change the whole dictionary's behavior when a key is not found:

    counts = {}
    counts.setdefault(value=0)
    for elem in data:
        counts[elem] += 1

    index = {}
    index.setdefault(function=list)
    for pageno, page in enumerate(pages):
        for line in page:
            for word in line.split():
                 index[word].append(line)
  • I definitely agree that this is the right way to go with setdefault. Probably when the 'function' keyword argument is supplied, setdefault should take *args and **kwds parameters so that the following would also be valid:

       1 d.setdefault(function=list, [0]) 
    

       1 d.setdefault(function=dict, a=0, b=1)
    

    The problem with this though is that then the function passed to setdefault can't take keyword parameters named either 'function' or 'value'. I wonder if it wouldn't be better to replace setdefault with two functions, setdefaultvalue and setdefaultfunction... -- StevenBethard

Better boolean logic

The and/or operators should only return boolean values. This makes their use less error-prone, less prone to abuse, and more closely match other languages. Also, it will simplify the underlying bytecode which currently inserts many POP_TOP instructions to complete conditionals. The need to insert these instructions also results in extra code paths and jump instructions. Overall, the language will become more intuitive, more reliable, simpler, and faster.

  • While I agree with your points. I would find "Better boolean logic" counter-productive in many instances. I personally prefer the former of these examples as the latter slows me down and, in my case, invites errors. {{{return a() or 'b'

#---

temp = a() if temp:

  • return temp

else:

  • return 'b'

}}}The latter structure always makes me shudder. I've never encountered a good use for non-boolean output from "and" (in Python. Other languages are a different story.) but using "or" in the first example is both quicker and more intuitive for many people not to mention reducing code complexity.-- StephanSokolow

Agreed, only comparison operators (==, >, <) should return True/False, leave and/or as is

Disallow calling class methods from instances

Calling with a instance is almost never what you want. When it is done, the results are not especially readable, and the code suggests that it is doing something that it isn't:

{'a'=1}.fromkeys('poof') # what happened to 'a'? 

I disagree to this. Although calling class methods on the instance from the outside will usually be rubbish, it will very often be useful and intended behavour inside instances. For example:

class mydict(dict):
  def key_copy(self):
    return self.fromkeys(self)    

This will assert that whatever subclass of mydict is created and not some other class. One could argue though that this could be achieved by the more cluttersome self.__class__.fromkeys().

Simplify the syntax for raising exceptions

  • Eliminate string exceptions entirely.
  • Alway require instantation. IOW, prefer raise ValueError(dat) to raise ValueError, dat.

  • Require that all exceptions subclass from Exception.

  • Have Exception be a new-style class

Fix implementation of in-place operators

The current implementation will call __iadd__(), allowing it to do the in-place change, but then require that the method return the new value and then store it again. Ideally, all the responsibility for the update should lie with the __iadd__() method and it should return None. This simplifies the bytecode and eliminates some annoying behavior (such as a[0]+=1 succeeding and raising an error when a=([0],).

Remove the distinction between data and non-data decriptors

Having the distinction provides a tiny benefit but incurs a large cost in terms of implementation complexity and increasing the learning curve for descriptors. Using the presence or absence of a setter to distinquish the two is somewhat hackish and confuses the heck out of anyone first trying to master descriptors. Even after using descriptors for a while, that nuance remains an annoying distraction.

Note that descriptors are a somewhat advanced feature, not really expected to be used by beginners or on a day to day basis, so the extra flexibilty given by by the data/non-data descriptors distinction may still be worth the small extra complexity it adds to the protocol .

Reconsider the inclusion of __slots__ or re-evaluate its implementation

Guido has expressed that this is a highly popular, but badly misunderstood tool that is often used incorrectly.

  • If __slots__ is misspelled, there is no visible indication of failure.

  • The purpose of the tool is not to make it more difficult to assign attributes.

  • __slots__ do not inherit.

  • __slots__ complicates and slows the implementation of new-style classes.

Extra operators for strings and lists

Operators as - & | ^ should be used for strings and lists directly in place of making firs a set data type (see [http://www.python.org/peps/pep-0218.html PEP 218 - Adding a Built-In Set Object Type]).

The operators /, * and % could also be used to split and stitch strings and lists:

   1 # split:
   2 'spameggsham' / 'a' == 'spameggsham'.split('a') == ['sp', 'meggsh', 'm']
   3 # reminder:
   4 'spameggsham' % 'a' == 'aa'
   5 # stitch:
   6 ['sp', 'meggsh', 'm'] * 'a' == 'spameggsham'
   7 
   8 # split list:
   9 [1, 2, 3, 4, 5] / [2, 3] == [[1], [4, 5]]
  • 'spameggsham' % 'a' == 'aa' is sort of unclear, and .count('a') works just as well. The others sound fine.-- ChrisRebert

Move rarely-used builtins to the library

pow() to the math module!

Don't remove callable()

Please don't. There are times where you want to know if an object is callable without calling it. For instance if you create a metaclass and need to wrap defined methods passed to __new__, and don't want to wrap class variables. In addition, using exceptions for normal control flow is not good code style.

Make API of set, list, dict more consistent

No need for copy function. A clear function for all of them.

Python3.0Suggestions (last edited 2010-05-16 23:17:52 by modemcable054)

Unable to edit the page? See the FrontPage for instructions.