2008/4/29 "Martin v. Löwis" <[EMAIL PROTECTED]>:
> > Same here. In fact, is there a good reason to have mkstemp() return the
> > fd (except backward compatibility)?
>
> Except for backwards compatibility: is there a good reason to keep
> os.mkstemp at all?
Greg Ewing's use-case is one I've also
Greg> I'd like to see a variation of mkstemp() that returns a file
Greg> object instead of a file descriptor...
http://bugs.python.org/issue2717
Comments welcome.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Greg Ewing wrote:
Guido van Rossum wrote:
IMO mkstemp() is a major pain because you have to use raw file
descriptors on the return value. I'd much rather recommend
[Named]TemporaryFile which return streams.
The problem with NamedTemporaryFile is that it deletes
the file as soon as you close it
David Harrison wrote:
2008/4/29 "Martin v. Löwis" <[EMAIL PROTECTED]>:
Same here. In fact, is there a good reason to have mkstemp() return the
> fd (except backward compatibility)?
Except for backwards compatibility: is there a good reason to keep
os.mkstemp at all?
Greg Ewing's use-case
On 4/29/2008 2:18 PM, Nick Coghlan wrote:
Same here. In fact, is there a good reason to have mkstemp() return the
> fd (except backward compatibility)?
Except for backwards compatibility: is there a good reason to keep
os.mkstemp at all?
Greg Ewing's use-case is one I've also had at times
Since the recent changes to networking-oriented tests (issue 2550, r62234 and
r62237), I think it's safe to say stability of the test suite on all the
non-Windows platforms has improved significantly in this area (I don't recall
seeing any socket errors in *nix buildbot logs since those commits
On Tue, 2008-04-29 at 15:34 +0200, Giovanni Bajo wrote:
> > As of 2.6, Greg's use case is addressed by the new 'delete' parameter on
> > tempfile.NamedTemporaryFile.
>
> Then I personally don't have any objection to the removal of os.mkstemp.
os.mkstemp is still useful when you *don't* need the
Maybe it would be better considering Windows CE systems too:
- if os.name == 'nt'
+ if os.name in ('nt', 'ce')
Moreover if the method is called "try_reuse_address" I'd expect that
"self._sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)" would be placed
inside a try/except block.
On 29 Apr, 15:58, Tr
Giampaolo Rodola' wrote:
Maybe it would be better considering Windows CE systems too:
- if os.name == 'nt'
+ if os.name in ('nt', 'ce')
Cygwin? I don't know how Unix-like it is.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.hold
> Giampaolo Rodola' wrote:
> > Maybe it would be better considering Windows CE systems too:
> >
> > - if os.name == 'nt'
> > + if os.name in ('nt', 'ce')
> >
> Cygwin? I don't know how Unix-like it is.
Yeah, that's a fair point, it's the behaviour of the underlying Winsock API
we're targeting, s
On Mon, Apr 28, 2008 at 10:49 PM, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> The problem with NamedTemporaryFile is that it deletes
> the file as soon as you close it, which makes the
> named-ness of it rather useless, as far as I can see.
Why? You can flush it and then all the data is on the disk
Hi all,
I would like to propose a new module for the stdlib for Python 2.6
and higher: "ast". The motivation for this module is the pending
deprecation for compiler.ast which is widely used (debugging,
template engines, code coverage etc.). _ast is a very solid module
and is without a doubt eas
>>> Same here. In fact, is there a good reason to have mkstemp() return the
>> > fd (except backward compatibility)?
>>
>> Except for backwards compatibility: is there a good reason to keep
>> os.mkstemp at all?
>
> Greg Ewing's use-case is one I've also had at times - ie. as a
> convenience fu
> An example module for the NodeVisitor is in the repository which
> converts a Python AST back into Python source code:
>
> http://dev.pocoo.org/hg/sandbox/file/tip/ast/codegen.py
And another example for the same functionality is in Demo/parser/unparse.py.
Regards,
Martin
Just a thought, but it would be great if this could be implemented over
the top of a C layer that operates on real AST nodes (rather than the
PyObject representation of those nodes). I'm working on stuff to perform
code optimization at the AST level (see the tlee-ast-optimize branch),
and the f
Guido van Rossum wrote:
Why? You can flush it and then all the data is on the disk.
That might be all right on Unix, but I would be
worried that having the file open could prevent
some other things being done with it on some
platforms, such as renaming. You might also want
to pass the file nam
16 matches
Mail list logo
