Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Least used builtins?

Reply
Thread Tools

Re: Least used builtins?

 
 
Sean 'Shaleh' Perry
Guest
Posts: n/a
 
      07-04-2003
On Friday 04 July 2003 10:27, Dan Bishop wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) (Sandy Norton) wrote in message
> news:<(E-Mail Removed) om>... [snip]
>
> > I know there some plans to reduce the number of builtins in some
> > future version of python (Python 3.0?): So which builtins do you least
> > use?
> >
> > Pesonally, I don't think I've ever used the following: intern, buffer,
> > coerce

>
> I haven't used: apply, buffer, coerce, globals, intern, iter, locals,
> oct, slice, super, unichr, unicode.


apply isn't as useful as it used to be.

locals and globals is useful in some interesting ways.

iter is really new so no surprise you haven't used it yet.

most people don't play with octal so I doubt oct() gets a lot of mileage.

The unicode stuff is new and most English only coders don't use it. But the
rest of the world does.


 
Reply With Quote
 
 
 
 
Lulu of the Lotus-Eaters
Guest
Posts: n/a
 
      07-04-2003
|> I haven't used: apply, buffer, coerce, globals, intern, iter, locals,
|> oct, slice, super, unichr, unicode.

Sean 'Shaleh' Perry <(E-Mail Removed)> wrote previously:
|apply isn't as useful as it used to be.
|locals and globals is useful in some interesting ways.
|iter is really new so no surprise you haven't used it yet.
|most people don't play with octal so I doubt oct() gets a lot of mileage.
|The unicode stuff is new and most English only coders don't use it.

I wouldn't mind moving quite a bit of __builtins__ into standard
modules. Doing that only creates a one-line incompatibility, i.e. you
might need to add:

from itertools import enumerate

To the top of a module/script. Some quick thoughts:

Current builtin Possible Home
--------------- ---------------
abs math
apply functional
basestring internal
bool
buffer
callable sys
chr
classmethod new
cmp
coerce
compile code
complex math
delattr
dict
dir
divmod math
enumerate itertools
eval code
execfile code
file
filter functional
float
getattr
globals
hasattr
hash internal
hex math
id internal
input
int
intern internal
isinstance sys
issubclass sys
iter
len
list
locals
long
map functional
max math
min math
object internal
oct math
open
ord
pow math
property new
range
raw_input
reduce functinal
reload
repr
round math
setattr
slice
staticmethod new
str
super internal
tuple
type
unichr
unicode
vars
xrange itertools
zip itertools

This sort of thing would cleanup the minimal Python interpreter, while
not deeply hiding/removing anything.

Yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------


 
Reply With Quote
 
 
 
 
Lulu of the Lotus-Eaters
Guest
Posts: n/a
 
      07-05-2003
I don't think any of these are a big deal. But I see several
motivations for moving a number of the builtins that Bicking disagrees
on. The breakage could be made small to non-existent by including a
bunch of such things in a file like startup.py that gets loaded
automatically, but that can be changed in principle.

One general point is that getting rid of builtins can make a minimal
Python footprint smaller (and load times slightly faster probably). For
embedded systems, handhelds, etc. reducing the required memory usage is
a good thing.

A second issue is the PyPy project. I think it dovetails with that
project to move everything that is a likely candidate for
reimplementation *in* Python into non-core modules. Doing this is not
strictly a requirement for PyPy, but it fits the style of thinking.

A third matter is my support for the function decorator/mutator idea.
classmethod, staticmethod, and property are nice method mutators, but as
a number of people pointed out in that thread, they are not the only
such modifiers one can imagine. Moreover, you can implement these in
Python (I incorrectly once doubted this), so spinning them out of core
makes sense from a #2 perspective.

Yet a fourth matter is that I think it would be slightly easier to teach
Python to beginners if __builtins__ did not include a number of
functions that were extremely difficult to explain to novices... and
that are really only of use to fairly expert Pythoneers. I find that
callable, classmethod, id, intern, and a number of others fall in this
category. My thinking is that anything meant for experts should need to
get imported by specific request.

All that said, I have neither any control of what happens, nor any
strong attachment to any of my suggested homes for (former) builtins.

|> enumerate itertools
|Again, this is idiomatic, and it belongs in builtins.

This one I strongly disagree with. The fact enumerate is builtin is a
little bit of a wart. It's really -just like- the family of functions
in itertools; only historical accident introduced it before itertools
came into existence.

|> filter functional
|Only because it's become redundant.

I don't at all think filter() is redundant... but I do think that a
'functional' module could grow a lot of extra useful capabilities
(currying, composition, etc). The usual filter/map/reduce would make a
good start for such a module (and clean up the base interpreter for
those FP-haters out there ).

|Definitely not -- these are very important, importing them would be
|obnoxious. Especially since "isinstance(value, str)" is the preferred
|technique over "type(value) is str".

Actually, I considered listing type() for desired removal to a module.
I suppose for consistency with my purport on isinstance() I ought to
advocate that.

|[super] Again, highly idiomatic, programmers should be discouraged from
|using this name for anything else

Indeed. But non-advanced programmer won't be using it for its builtin
meaning either. Just look at all the threads by quite sophisticated
Pythonistas trying to clarify exactly what super() really does. You
cannot even understand this function without first getting C3
linearization (and even then, figuring out what the different calling
forms all do is still tricky).

|zip, like enumerate, is idiomatic -- importing it does not imply
|anything about your code, that it comes from itertools lends little
|insight into what zip does.

Actually, I don't think a separate zip/izip does any good, nor
range/xrange. But those are more historical accidents. I wouldn't mind
seeing itertools have the same kind of status that sys does now. What's
the last script you wrote that didn't import sys? You don't technically
need it... until you want to do something with input, output or
arguments .

Yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Need regular expression for at least 7 characters and at least 1 special chatacter AAaron123 ASP .Net 0 10-03-2008 01:25 PM
NTFS uses least used clusters ? (Cluster durability/lifetime ?) Skybuck Flying Windows 64bit 5 03-15-2008 02:22 PM
The least used keywords in C++, which do you use? Alf P. Steinbach C++ 54 09-28-2007 03:38 PM
Least recently used (LRU) memory question kkk C Programming 3 03-05-2007 08:19 AM
Least recently used (LRU) memory question kkk C Programming 0 03-04-2007 04:30 PM



Advertisments