Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset ef406c4c6463 by Charles-François Natali in branch 'default':
Issue #12760: Add some mising documentation about the new `x` exclusive
http://hg.python.org/cpython/rev/ef406c4c6463
--
Petri Lehtinen pe...@digip.org added the comment:
Shouldn't the documentation of builtin open() (in Doc/library/functions.rst) be
updated too?
--
nosy: +petri.lehtinen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 8bcbe2dc3835 by Charles-François Natali in branch 'default':
Issue #12760: Refer to the new 'x' open mode as exclusive creation mode.
http://hg.python.org/cpython/rev/8bcbe2dc3835
--
Charles-François Natali neolo...@free.fr added the comment:
Thanks, I've committed your version.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
David Townshend aquavita...@gmail.com added the comment:
I've done a bit or rewording in the io docs, but I honestly don't know if this
is any better that what you already had!
--
Added file: http://bugs.python.org/file24210/x_diff2.patch
___
Python
Charles-François Natali neolo...@free.fr added the comment:
Nick suggested to call the new flag exclusive create in the doc (and explain
in whatsnew that it's based C11 new 'x' flag).
Could someone please check the attached patch?
My wording sounds really clumsy, so I'd prefer if a native
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset bf609baff4d3 by Charles-François Natali in branch 'default':
Issue #12760: Add a create mode to open(). Patch by David Townshend.
http://hg.python.org/cpython/rev/bf609baff4d3
--
nosy: +python-dev
Charles-François Natali neolo...@free.fr added the comment:
Committed.
David, thanks for the patch!
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Charles-François Natali neolo...@free.fr added the comment:
I intend to commit this patch within a couple days (unless anyone objects of
course).
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
Antoine Pitrou pit...@free.fr added the comment:
I don't think the created() method has to be exposed. People can inspect the
mode attribute if they want to have that information.
(besides, the semantics are misleading since a new file opened with w has
also be created, but created() would
Charles-François Natali neolo...@free.fr added the comment:
Here's a new version of the patch that should address all the comments.
--
Added file: http://bugs.python.org/file24179/open_create_x-3.patch
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
Here's a new version of the patch that should address all the comments.
Just a small note: FileExistsError is raised, not exactly OSError, when
the file exists.
--
___
Python tracker
Charles-François Natali neolo...@free.fr added the comment:
Just a small note: FileExistsError is raised, not exactly OSError,
when the file exists.
I've updated the doc accordingly.
--
stage: patch review - commit review
___
Python tracker
Charles-François Natali neolo...@free.fr added the comment:
I've done a small review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
Éric Araujo mer...@netwok.org added the comment:
This is not a duplicate issue. The openat solution is no easier than the
os.open
solution.
Amaury did not suggest to use openat, but the new opener argument to open,
which was especially added for use cases such as the one discussed here:
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
Amaury did not suggest to use openat, but the new opener argument to open,
which was especially added for use cases such as the one discussed here:
Sorry, yes. Wrong words, same thought. We can implement this using opener, but
we
Éric Araujo mer...@netwok.org added the comment:
[...] There is slightly more versatility with the opener method, but no more
obviousness
and no less typing.
I agree with your opinion. I re-read this report:
- Antoine thinks this fills an important use case, namely avoiding race
Antoine Pitrou pit...@free.fr added the comment:
C11 uses 'x' for this, for what it's worth.
This is not a duplicate issue. The openat solution is no easier than
the os.open solution.
Ok, let's re-open then. I'm not sold on the feature, but the fact C11 adds a
dedicated letter mode for
Changes by Chris Rebert pyb...@rebertia.com:
--
nosy: +cvrebert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
___
Python-bugs-list
Devin Jeanpierre jeanpierr...@gmail.com added the comment:
C11 uses 'x' for this, for what it's worth.
This is not a duplicate issue. The openat solution is no easier than the
os.open solution.
--
nosy: +Devin Jeanpierre
___
Python tracker
Éric Araujo mer...@netwok.org added the comment:
See #13424 for a doc request about this.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
David Townshend aquavita...@gmail.com added the comment:
It is already possible to write a wrapper function that does it:
def create(file):
fd = os.open(file, os.O_EXCL | os.O_CREAT | os.O_WRONLY)
return os.fdopen(fd)
The point it not that it can't be done, but that it is not straight
David Townshend aquavita...@gmail.com added the comment:
I see this has been marked as a duplicate of http://bugs.python.org/issue12797.
Please explain how this is, since that proposal does not appear to provide the
functionality discussed here.
--
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
issue12797 would allow things like:
def create_exclusive_file(filename):
return open(filename, w,
opener=lambda path, mode: os.open(path,
mode|os.O_CREAT|os.O_EXCL))
--
___
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - duplicate
status: open - closed
superseder: - io.FileIO and io.open should support openat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
Charles-François Natali neolo...@free.fr added the comment:
So, what was the conclusion of the discussion brought up on python-dev?
I had a feeling some core devs were opposed to this (I'm personally -0).
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou pit...@free.fr added the comment:
I haven't seen any discussion on python-dev. Have I missed something?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
Charles-François Natali neolo...@free.fr added the comment:
I haven't seen any discussion on python-dev. Have I missed something?
It was on Python-ideas actually:
http://mail.python.org/pipermail/python-ideas/2011-August/011183.html
--
___
Python
Antoine Pitrou pit...@free.fr added the comment:
Ah, right. Well I think all arguments against it were quite weak (or even
wrong). Let's see:
- it's not cross-platform: actually it is (OS_EXCL has been POSIX since at
least 1997 (*), and Windows also has it)
- os.open followed by os.fdopen is
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
- os.open followed by os.fdopen is easy: it isn't that easy to get
the incantation right (the pure Python open() in _pyio is 70 lines
of code), especially if you want the file object to have the right
name attribute
What if we can
Antoine Pitrou pit...@free.fr added the comment:
What if we can override the inner call to os.open()?
For example, io.open() could grow an additional argument fd_opener
which defaults to the equivalent of os.open.
I agree it would be a much better situation than what we have now.
--
STINNER Victor victor.stin...@haypocalc.com added the comment:
open(filename, 'w',
fd_opener=lambda path, mode: os.open(path, mode|os.O_CREAT)
I prefer open(name, c).
it doesn't fill a use case: actually, avoiding race conditions
is an important use case, ...
It may help the
Antoine Pitrou pit...@free.fr added the comment:
The #ifdef O_EXCL in the source code is probably very old. Copying a message
I posted on python-ideas:
O_EXCL is a POSIX standard. It is also supported
under Windows by the _open/_wopen compatibility functions (which we use
for file I/O).
David Townshend aquavita...@gmail.com added the comment:
My aim isn't to add all the commonly used flags, that would be pointless since
its already possible using os.open. The aim is to add a missing feature to the
builtin open(), i.e. file creation. At the moment open() implements read,
Charles-François Natali neolo...@free.fr added the comment:
The #ifdef O_EXCL in the source code is probably very old. Copying a
message I posted on python-ideas:
O_EXCL is a POSIX standard. It is also supported
under Windows by the _open/_wopen compatibility functions (which we use
for
David Townshend aquavita...@gmail.com added the comment:
Changing form 'c' to 'x' is easy enough, and if there is already a convention
it makes sense to stick to it.
I thought I had done a mercurial diff! I'll try again and resubmit.
--
___
Python
Julian Berman julian+python@grayvines.com added the comment:
A minor documentation error in io.rst line 475 which was changed to:
+ The *mode* can be ``'c'``, ``'r'``, ``'w'`` or ``'a'`` for reading
+ (default), writing, or appending.
and should have creating at the front I assume,
Antoine Pitrou pit...@free.fr added the comment:
Well, I'd rather have this flag called 'x', to be consistent with
glibc's fopen():
c (since glibc 2.3.3)
Do not make the open operation, or subsequent read and write
operations, thread cancellation
Charles-François Natali neolo...@free.fr added the comment:
Yeah, but I think exclusively is quite misleading since it does not
perform any locking of any kind.
It might be misleading, but I find it clear enough, and this name has been
endorsed by POSIX.
Furthermore, there's an added bonus:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I don't know if it's documented behavior
See #12103: it is not documented.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
David Townshend aquavita...@gmail.com added the comment:
I hope this patch suits you better :-)
I've updated the documentation typo (thanks for pointing that out). I've also
changed 'c' to 'x', since I think that if there is a convention we should stick
to it. I don't think that it matters
New submission from David Townshend aquavita...@gmail.com:
Currently, opening a file with open(file, 'w') overwrites existing files. It
would be useful for open() to raise an error when the file exists. This
proposal is to add a 'c' mode to open, which has the effect to creating a file
and
STINNER Victor victor.stin...@haypocalc.com added the comment:
I'm not sure that O_EXCL is portable (exist on all platforms) because Python
source code uses #ifdef O_EXCL.
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
Benjamin Peterson benja...@python.org added the comment:
I think this should be brought up on python-ideas or python-dev.
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
Charles-François Natali neolo...@free.fr added the comment:
See also issue 12105.
A couple downsides:
- O_EXCL is not necessarily portable (doesn't work well with NFS, maybe not on
Windows?)
- O_EXCL is useful, as is O_CLOEXEC: to be consistent, we should also end up
adding all other
David Townshend aquavita...@gmail.com added the comment:
It was discussed on python-ideas, but the subject of the thread was actually on
shutils.move so it was not really discussed much. I will repost this idea
separately.
--
___
Python tracker
47 matches
Mail list logo
