homepage

According the docs for the tempfile module, SpooledTemporaryFile()
should operate "exactly as TemporaryFile() does". However, while
playing around trying to learn the module I found a couple of places
where this is not the case: 
import tempfile
hello = bytes('Hello World!', encoding='utf-8')
tf = tempfile.TemporaryFile()
stf = tempfile.SpooledTemporaryFile()
tf.write(hello)
stf.write(hello)
# (1) Read after write behaviour differs...
>>> print(tf.read()) 
b'Hello World'
>>> print(stf.read())
b''
# ...unless you seek first
>>> tf.seek(0)
>>> stf.seek(0)
>>> print(tf.read())
b'Hello World'
>>> print(stf.read())
b'Hello World'
# (2) Name attribute is fragile...
>>> print(tf.name)
3
print(stf.name)
AttributeError: '_io.BytesIO' object has no attribute 'name'
# ...until StringIO object replaced
stf.rollover()
print(stf.name) # 4
I'm not sure if this should be categorised as a documentation or code
issue. In either case please be gentle -- I'm still just learning Python
(evaluating it as a [now likely] replacement for PHP for web application
development in our company). I'm filing this bug because, as a
beginner, I was confused by the inconsistency between the docs and the
actual behaviour.
I'd be happy to try and write documentation and/or unit tests about
this, if somebody would be willing to review them for me... :-)

I've attached a patch to SpooledTemporaryFile (and its test class) to
remove the suprising exceptions.
SpooledTemporaryFile uses a io.StringIO for storage (in self._file)
until it reaches a certain size (or rollover() is called), at which
point it switches to a file object (or _TemporaryFileWrapper on
non-posix platforms). This implementation detail should be abstracted
away from the user.
The interface mismatch there which caused an AttributeError to be thrown
-- but only if the file size was new, or below a certain size.

Some properties seem to be broken no matter if the underlying storage
system is file or StringIO.
Properties: encoding, newlines, and softspace
And the method: xreadlines()
I'm not sure what the correct behaviour should be (although I'm pretty
sure xreadlines() should just be deleted -- but when?), so I haven't
tried to patch the code. The attached patch is a just (a beginners idea
of a) test to confirm the problem.

Thanks for the report, and sorry we didn't handle it when you reported it. This issue was re-reported and fixed in issue #10355.