[Python-3000] please keep open() as a builtin, and general concerns about Py3k complexity (original) (raw)
Neal Norwitz nnorwitz at gmail.com
Wed May 23 07:13:46 CEST 2007
- Previous message: [Python-3000] please keep open() as a builtin, and general concerns about Py3k complexity
- Next message: [Python-3000] please keep open() as a builtin, and general concerns about Py3k complexity
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-3000] please keep open() as a builtin, and general concerns about Py3k complexity
- Next message: [Python-3000] please keep open() as a builtin, and general concerns about Py3k complexity
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]