Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Jeroen Ruigrok van der Werven wrote: -On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: Groan. Then everyone else realizes what a "great idea" this is, and we see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a directory with a comment market in its name), ~/Lisp/ and the rest? I don't think people would thank us for that in the long term. I'm +1 on just using $HOME/.local, but otherwise $HOME/.python makes sense too. $HOME/.python.d doesn't do it for me, too clunky (and hardly used if I look at my .files in $HOME). I'd vote for $HOME/.local if asked. I agree with most, if not all, of the arguments posted in favour of this, but would also like to point out the XDG-basedir specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html This specification concerns where to put data files rather than libraries, but the relevance here is that the default location to put user-specific files according to it is in $HOME/.local/share Whilst by no means universally followed, uptake amongst Gnome and GTK applications seems to be rising - I certainly have a load of stuff in .local/share/ without ever having configured anything away from the Ubuntu install defaults. So, on Ubuntu computers at least, it seems likely that a $HOME/.local/ directory will already exist, with the beginnings of a unix style layout inside it. -- Richard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] small PATCH to fix os.fsync on OS X
James Y Knight wrote: On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote: While some people might suggest that fullfsync should be exposed as a method on the 'os' module for platforms that support it, I believe this is not the best approach. Because the docstring for os.fsync says that it forces the file to be written to disk, I think it's up to python to ensure that functionality is really there on all platforms. Currently on OS X, fullfsync is needed to provide this functionality, so I think python's os.fsync should use fullfsync on OS X. Please don't make that change. fsync on OSX does the same thing as fsync traditionally does on other OSes. That is: it flushes the data to "disk", but doesn't make any effort to ensure that the disk drive actually flushes the data from its own write cache to the platter. Other OSes just don't expose that functionality *at all*. See e.g. this thread: http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html You should instead propose a patch to add F_FULLSYNC to the fcntl module when present. I can't think of a situation where it would be useful to do an fsync() in which you don't want the data to be flushed as far as possible. If you're bothering to call fsync(), it's presumably because you need to guarantee that the data will be in a consistent state in the event of a failure (like a power cut). So I think it would be helpful for an fsync call in a high-level language to handle the details of this. However, my perspective is largely tied to databases, so there may be other situations that I can't think of where it does make sense to want to push changes as far as the on-disk buffers, but no further. If the change suggested isn't to be made to os.fsync(), I think it would at least be helpful to add a note to the os.fsync docstring mentioning this limitation, and pointing to the F_FULLSYNC in the fcntl module when this is implemented. And perhaps add an implementation of fsync which _does_ also do F_FULLSYNC elsewhere (shutil.fsync()?), to save all those users of fsync() who also want F_FULLSYNC from having to implement code which calls F_FULLSYNC when available and os.fsync() otherwise. -- Richard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
