I came across a complaint that PEP 0042 had become a graveyard of
neglected ideas, and decided to have a look through and implement
something. Creating a smarter temporary file object seemed simple
Oddly, even after GvR re-opened it, I can't post an attachment to that
tracker item (it's under "Feature Requests" -- does it need to get moved
to "Patches" first?), but the implementation is short, so it's included
below. This is intended to be appended to Lib/tempfile.py (and thus
assumes that module's globals are present).
I would appreciate it if the gurus of python-dev could take a peek and
let me know if this is unsuitable or incorrect for any reason. It's not
the most straightforward implementatio -- I used the optimization
techniques I found in TemporaryFile.
If this looks good, I'll prepare a patch against trunk, including an
additional chunk of documentation and a unit test.
from cStringIO import StringIO
from StringIO import StringIO
"""Temporary file wrapper, specialized to switch from
StringIO to a real file when it exceeds a certain size or
when a fileno is needed.
_rolled = False
def __init__(self, max_size=0, mode='w+b', bufsize=-1,
suffix="", prefix=template, dir=None):
self._file = StringIO()
self._max_size = max_size
self._TemporaryFileArgs = (mode, bufsize, suffix, prefix, dir)
def _check(self, file):
if self._rolled: return
if file.tell() > self.__dict__['_max_size']:
def _rollover(self, file):
args = self.__dict__['_TemporaryFileArgs']
self.__dict__.clear() # clear attributes cached by __getattr__
newfile = self._file = TemporaryFile(*args)
self._rolled = True
# replace patched functions with the new file's methods
self.write = newfile.write
self.writelines = newfile.writelines
self.fileno = newfile.fileno
def write(self, s):
file = self.__dict__['_file']
rv = file.write(s)
def writelines(self, iterable):
file = self.__dict__['_file']
rv = file.writelines(iterable)
def __getattr__(self, name):
file = self.__dict__['_file']
a = getattr(file, name)
if type(a) != type(0):
setattr(self, name, a)
i don't like the current super() at all. having to type super(Foo,
self).__init__(...) is messy, hard to remember, and error-prone. it
also introduces an unfortunate dependency in that the name of the class
(Foo) has to be hard-coded in the call, and if you change the class name
you also have to go and change all super() calls -- more chances for
errors. as a result, i imagine there's a strong urge to just hardcode
the name of the parent -- a bad idea, and the reason why super() was
introduced in the first place.
instead, `super' should work like in other languages. a couple of ideas:
-- super.meth(args) calls the superclass method `meth', in the same way
that super(Foo, self).meth(args) currently works. (this is the same
syntax as in java. this probably requires making `super' be a keyword,
although it might be possible to hack this by examining the current call
-- as an alternative or in addition, super(args) would work like
super.meth(args) if we're currently inside of `meth' in a subclass. i
suspect that 90% of the time or more, `super' is used to chain to the
superclass version of an overridden method, and this optimizes for the
common case. it makes for one less possibility of misspelling
`__init__' and one less thing that requires renaming if a method is
renamed or code copied to another method (granted, this isn't such a big
deal as in the case of class renaming). if the form `super.meth(args)'
isn't also supported, then a call of this sort would have to be made
through the introspection API. (i think it would be a good idea to have
this functionality available through the introspection API, in any
case. currently i don't see any obvious way in module `inspect' to find
out which class a call to `super(...).meth(...)' is invoked on, although
maybe a loop with inspect.getmro() and hasattr() would work. it would
be nice to have a function like inspect.getsuper(class, 'meth'), i think.)
It would be nice if this simple fix could be included (main branch and 2.5.1):
[ 1598181 ] subprocess.py: O(N**2) bottleneck
I submitted the trivial fix almost two months ago, but apparently nobody feels responsible...
----- Original Message ----
From: Neal Norwitz <nnorwitz(a)gmail.com>
To: Python Dev <python-dev(a)python.org>
Sent: Wednesday, January 3, 2007 10:59:15 PM
Subject: Re: [Python-Dev] 2.5.1 plans
The current schedule looks like it's shaping up to be:
Wed, Jan 24 for 2.5.1c1
Wed Jan 31 for 2.5.1
It would be great if you could comment on some of the bug reports
below. I think several already have patches/suggested fixes.
These looks like they would be nice to fix::
http://python.org/sf/1579370 Segfault provoked by generators and exceptions
http://python.org/sf/1377858 segfaults when using __del__ and weakrefs
There is one outstanding issue I was notified of in private mail::
http://python.org/sf/1568240 Tix is not included in 2.5 for Windows
It's not clear to me if this should be fixed, but it's got a high priority::
http://python.org/sf/1467929 %-formatting and dicts
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
Whoever is subscribed to python-dev with a broken corporate
autoresponder that sends everyone who posts to the list this useless
response multiple times please unsubscribe yourself. Its highly
annoying and entirely useless since its not even identifying the list
subscriber(s) deserving the blame.
On Fri, Jan 05, 2007 at 06:28:35AM +0000, noreply(a)cbsoutdoor.co.uk wrote:
> Dear Recipient,
> We have now changed our company name to CBS Outdoor Limited. My new email address is therefore firstname.surname(a)cbsoutdoor.co.uk Your email has been redirected but please amend your address book accordingly.
> Thank you.
> CBS Outdoor Limited
> The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it was addressed, and may also be privileged. If you are not the addressee of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this e-mail in error, please e-mail the sender by replying to this message. CBS Outdoor Ltd reserves the right to monitor e-mail communications from external/internal sources for the purposes of ensuring correct and appropriate use of CBS Outdoor facilities.
I fixed the crash that was due to raising a warning on shutdown. I
have heard about crashes at shutdown and wonder if this was the cause.
There might be similar bugs lurking that assume PyModule_GetDict()
always returns a valid pointer. It doesn't, it can return NULL.
I'm not sure if the original problem existed or not, but after this
fix on shutdown, I see:
warning: DBTxn aborted in destructor. No prior commit() or abort().
I don't know if this is a real problem, a test problem, or what.
On 2007-01-02 01:02, brett.cannon wrote:
> Author: brett.cannon
> Date: Tue Jan 2 01:02:41 2007
> New Revision: 53204
> peps/trunk/pep-3108.txt (contents, props changed)
> Add PEP 3108: Standard Library Reorganization.
> +Open Issues
> +Consolidate dependent modules together into a single module or package?
> +Consolidate certain modules with similar themes together in a package?
If you do follow this route, please take the chance to place
the whole Python stdlib under a single package. That way we'll
avoid name clashes with existing packages and modules now and
in the future.
Together with absolute imports this also improves the readability
of modules since it becomes immediately clear where the imported code
is coming from.
Note that as side-effect of this it becomes a lot harder to manipulate
PYTHONPATH to trick Python into loading a standard module from a
non-standard location, improving security and robustness of the
> +Packages are often used to group together modules that have a similar
> +theme but do not have any direct relationship or dependency upon each
> +other. For Python 3.0 obvious groupings could be done since renaming
> +of various modules is already occurring.
> +* collections
> + + heapq
> + + Queue
> + + sets
> + + UserDist
> + + UserList
> + + What to do with UserString?
> + - Have a package for Python implementations of built-in types
> + instead of putting the User* modules into 'collections'?
> +* mac
> + + Various Mac-specific modules.
> + + Same can be done for other platform-specific code.
> +* Profiling
> + + cProfile
> + + profile
> + + hotshot
> + + pstats
> +* email
> + + mailbox
> + + mhlib
> +* Databases
> + + anydbm
> + + dbhash
> + + dbm
> + + bsddb
> + + dumbdbm
> + + gdbm
> + + whichdb
> +* Audio
> + + aifc
> + + audioop
> + + chunk
> + + ossaudiodev
> + + sunau
> + + wave
> + + winsound
> +* Servers
> + + BaseHTTPServer
> + + CGIHTTPServer
> + + DocXMLRPCServer
> + + SimpleHTTPServer
> + + SimpleXMLRPCServer
> + + SocketServer
The package names should probably be converted to lower-case to
follow PEP 8.
Thanks and Happy New Year,
Professional Python Services directly from the Source (#1, Jan 02 2007)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
I don't have a schedule in mind for 2.5.1 yet, however we should start
preparing for it. The release will probably happen sometime in
January if everyone is available. The branch has been pretty quiet,
so I'm not expecting too many problems.
Once we figure out a date for release I'll follow up here.
If you have any bugs or patches that should be addressed prior to
release, please assign them to me and bump the priority to 9. I'm not
sure that there are any bugs which absolutely must be fixed before
release, though there are a few that would be nice.
Any other discussion for 2.5.1 necessary?