[Python-3000] please keep open() as a builtin, and general concerns about Py3k complexity

Neal Norwitz nnorwitz at gmail.com
Wed May 23 07:13:46 CEST 2007


On 5/22/07, Steve Howell <showell30 at yahoo.com> wrote:
>
> In the system I've worked on for the last three years,
> we have at least 200 calls to the builtin open()
> method.

This number is meaningless by itself.  200 calls in how many lines of code?
How many files total and how many files use open?

I'm not sure if the numbers are useful, but if it's only used in 0.1%
of the modules, that's not a strong case for keeping it.

> FWIW one of my favorite accepted PEPs is PEP 3111,
> "Simple input built-in in Python 3000."  BTW  it's the
> only 3000 series PEP with the word "simple" in the
> title.

:-)  This PEP really just restores (raw_)input.  So it mostly keeps
the status quo.
The name raw_input goes away, there is only input which is the same as
raw_input() in 2.x.

>  I realize looking at PEPs and mailing list
> archives can skew an outsider's view of how well Py3K
> simplifies the language, since simple ideas often
> don't require PEPs, and complex ideas often lead to
> lengthier debates than simple ones, but I'm not
> feeling the simplicity.

Sure, that's understandable.  For the most part, the PEPs are about
adding new features, not about removing warts and cruft.  PEP 3100 is
the primary PEP which has info about removals.

I'll pull some stats from the Misc/NEWS file which (hopefully)
contains most of what's been done to date.

At least 7 builtins have been removed.  I expect at least 2-3 more
will be removed completely.  There will probably be ~5 others that are
not used frequently which will be moved elsewhere (e.g., intern was
already moved to sys).

1 package (compiler), 11 platform-independent modules, and probably
~20 platform-dependent modules have been removed.  I'd expect another
5-10 platform-independent modules will be removed.

Details from Misc/NEWS:

Core:
------

- Absolute import is the default behavior for 'import foo' etc.

- Removed support for syntax:
  backticks (ie, `x`), <>

- Removed these Python builtins:
  apply(), callable(), coerce(), file()

- Removed these Python methods:
  {}.has_key

- Removed these opcodes:
  BINARY_DIVIDE, INPLACE_DIVIDE, UNARY_CONVERT

- Remove C API support for restricted execution.

Library
-------

- Remove the imageop module.  Obsolete long with its unit tests becoming
  useless from the removal of rgbimg and imgfile.

- Removed these attributes from Python modules:
  * operator module: div, idiv, __div__, __idiv__, isCallable, sequenceIncludes

- Remove the compiler package.  Use of the _ast module and (an eventual)
  AST -> bytecode mechanism.

- Removed these modules:
  * Bastion, bsddb185, exceptions, md5, popen2, rexec,
    sets, sha, stringold, strop, xmllib

- Remove obsolete IRIX modules: al/AL, cd/CD, cddb, cdplayer, cl/CL, DEVICE,
  ERRNO, FILE, fl/FL, flp, fm, GET, gl/GL, GLWS, IN, imgfile, IOCTL, jpeg,
  panel, panelparser, readcd, sgi, sv/SV, torgb, WAIT.

- Remove obsolete functions:
  * commands.getstatus(), os.popen*,

- Remove functions in the string module that are also string methods.

- Remove support for long obsolete platforms: plat-aix3, plat-irix5.

- Remove xmlrpclib.SlowParser.  It was based on xmllib.


C API
-----

- Removed these Python slots:
  __coerce__, __div__, __idiv__, __rdiv__

- Removed these C APIs:
  PyNumber_Coerce(), PyNumber_CoerceEx()

- Removed these C slots/fields:
  nb_divide, nb_inplace_divide

- Removed these macros:
  staticforward, statichere, PyArg_GetInt, PyArg_NoArgs

- Removed these typedefs:
  intargfunc, intintargfunc, intobjargproc, intintobjargproc,
  getreadbufferproc, getwritebufferproc, getsegcountproc, getcharbufferproc

I'm pretty sure there is a lot missing from this list of removals.  I
also know there will be more coming. :-)

There will also be reorganizations that help reduce some conceptual
overhead.  So even though the standard library won't necessarily get
smaller, it will be easier for new people to ignore sections they
aren't interested in.  For example, database modules or web libraries.

n


More information about the Python-3000 mailing list