Larry Hastings added the comment:
BTW: If PEP 362 is accepted, and this patch makes it for 3.3 (both of which I
think will happen), I'll hand-code signatures for the functions that may throw
NotImplementedError so users can use "is_implemente
Larry Hastings added the comment:
> Previously existing redundant functions could be
> deprecated in documentation.
As in, don't start a "deprecation cycle" (warning in 3.3, deprecated in 3.4,
gone in 3.5), just document "consider using this other function instead
New submission from Larry Hastings :
As I keep saying on python-dev: I think that the argument list for a function
should be stable. If you have a function where some abilities are only
available on certain platforms, it's best to always accept default no-op
parameters for those param
Larry Hastings added the comment:
> os.sendfile(out, in, offset, nbytes, *, headers=None, trailers=None,
> diskio=True, wait=True, sync=False)
I probably prefer this. If the original implementers are okay with it then I'd
be happy to do it that way. But at the very least I want
Larry Hastings added the comment:
> There are some other functions with strange/variable prototype:
> http://docs.python.org/dev/library/fcntl.html?highlight=ioctl#fcntl.ioctl
> http://docs.python.org/dev/library/mmap.html?highlight=mmap.mmap#mmap.mmap
It does not follow that this be
Changes by Larry Hastings :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue14815>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Ping. Benjamin, should I find another reviewer?
--
___
Python tracker
<http://bugs.python.org/issue14769>
___
___
Python-bug
Larry Hastings added the comment:
Just a thought--how about a new constant in the re module:
SUPPRESSED=object()
and have the interface be
mo.groupdict(default=re.SUPPRESSED)
--
nosy: +larry
___
Python tracker
<http://bugs.python.
Larry Hastings added the comment:
@mrabarnett: That's right--except your tense is wrong. mo.groupdict() has
supported the "default" parameter since the function was first added, way back
in 1.5.2.
--
___
Python tracker
<http
Larry Hastings added the comment:
Changes incorporated from Benjamin's feedback. Thanks, Benjamin!
Is this ready to go?
--
Added file: http://bugs.python.org/file26060/larry.test_skipitem_parity.3.diff
___
Python tracker
<http://bugs.py
New submission from Larry Hastings :
The trend in the standard library is to get rid of awkward Python-1-style tuple
return values and switch to struct sequences. (And perhaps, in the fullness of
time, to deprecate the iterability of such objects. But that's for the future.)
os.stat
Larry Hastings added the comment:
New patch! What's new:
* The big change: I removed the "fd=" parameters. Now, functions that
accept either a path or a file descriptor simply take either as their
"path" argument. I ran it by Guido and he thought it sounded fin
Larry Hastings added the comment:
Incorporates Benjamin's self-admitted pedantic changes ;-)
Will it survive? Will it get checked in? Tune in... soon, I hope!
--
Added file: http://bugs.python.org/file26064/larry.test_skipitem_parity.4
Larry Hastings added the comment:
Patch implementing struct sequences for os.uname() and os.times(). Those two
are a slam dunk, so let's try and get 'em into 3.3.
Patch includes docs! Maybe it's ready! Who knows!
--
keywords: +patch
Added file:
http://bugs.pytho
Larry Hastings added the comment:
Fifth iteration of my patch. Everything is done, and I really think it's ready
to be checked in.
* The documentation is done, including Misc/NEWS.
* All the code is now < 80 columns.
* The docstrings have been double- and triple-checked.
* It pa
Changes by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Larry Hastings :
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue15008>
___
___
Python-bugs-list mai
Larry Hastings added the comment:
Closing this, as I have now removed os.utimensat and os.futimesat. As well as
os.futimens, os.futimes, and os.lutimes. And in fact retooled os.utime in a
pretty major way. (See #14626.)
--
resolution: -> fixed
stage: patch review -> com
Larry Hastings added the comment:
> OT, but since you brought it up: In my opinion, deprecating the
> iterability of any builtin class is a horrible idea. It is a
> Python feature, especially in 3.x, that all *are* iterable.
As you say, OT. But I don't see how it's a feat
Larry Hastings added the comment:
I think it's a good idea, and I didn't spot anything on my first pass at
reviewing the patch. But I'm on my way out the door and won't be back for a
few hours.
Tell you what: once I'm back, if I don't spot anything out of plac
Larry Hastings added the comment:
It is usually folly to disagree with MvL, and yet I am about to do just that.
As stated, I don't believe in the "thin wrappers" theory of os; where would a
Windows programmer find the man page to learn how os.access works on their
system?
I
Larry Hastings added the comment:
I made two documentation changes to the patch before committing it:
* I restored the text under os.remove about how it doesn't handle
directories.
* I added a Misc/NEWS entry.
But I didn't have to touch the code--that looked dead-on to me.
Changes by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Larry Hastings added the comment:
Okay, this patch is definitely ready. Changes from the last patch:
* The two return types are now exposed in the os module (os.uname_result
and os.times_result) and are permanently on even if os.uname() or
os.times() are not available.
* I updated the
New submission from Larry Hastings :
Serhiy Storchaka suggested (in private email, not on tracker or python-dev):
why not make follow_symlinks and effective_ids failover where possible?
Let's take the example of effective_ids first, that's simpler. Let's say the
user calls
Larry Hastings added the comment:
Attached is patch #3. Ned Deily advised me not to touch distutils, and
packaging is in the process of being removed. So I backed out of my changes to
those two packages. Apart from that the patch is the same as #2.
Georg: mind if this goes in before
Larry Hastings added the comment:
Whoops, here's the patch.
--
Added file:
http://bugs.python.org/file26123/larry.uname.and.times.structseq.3.diff
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Patch attached. Implementation now uses GetFileAttributes (A or W) to
determine whether or not src is a directory. Fixed docstring, docs, and
updated Misc/NEWS.
--
assignee: -> larry
keywords: +patch
nosy: +mhammond
stage: needs patch ->
Larry Hastings added the comment:
Note: I can't test this, as I only run Windows XP. But it compiles cleanly on
Windows, and on Linux it compiles and passes the test suite fine.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
I got bored so I made you a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file26125/larry.random_seed.ssize_t.1.diff
___
Python tracker
<http://bugs.python.org/issue14
Changes by Larry Hastings :
--
assignee: -> larry
stage: -> patch review
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue15118>
___
Larry Hastings added the comment:
Bikeshedding:
(os.unlink in os.supports_dir_fd and os.open in os.supports_dir_fd)
could be rewritten as
{ os.open, os.unlink } <= os.supports_dir_fd
As you were!
--
___
Python tracker
<http://bugs.pyth
Larry Hastings added the comment:
> I guess it’s too late to propose “os.open.supports_dir_fd and
> os.unlink.supports_dir_fd” (and I don’t know if that is feasible
> with C functions) :)
Where were you when "is_implemented" was being savagely t
Changes by Larry Hastings :
--
resolution: -> fixed
stage: -> commit review
status: open -> closed
type: -> enhancement
___
Python tracker
<http://bugs.python
Larry Hastings added the comment:
I think you're right. As Antoine pointed out in irc, for POSIX platforms,
modules in os are almost exclusively atomic. This is a useful (if
undocumented) feature from a security viewpoint, and we should not break it
lightly.
Closing as wontfix
Larry Hastings added the comment:
Yummy!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Larry Hastings added the comment:
Martin: does this sound good or bad?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue14917>
___
___
Python-bug
Larry Hastings added the comment:
Well then! Let's close this before the adults notice.
--
resolution: -> wont fix
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Larry Hastings added the comment:
Patch isn't ready, no doc changes. But code review can happen.
--
keywords: +patch
Added file: http://bugs.python.org/file26136/larry.platform.unamedtuple.1.diff
___
Python tracker
<http://bugs.py
Larry Hastings added the comment:
Docs fixed, new unit tests for namedtuple interface added.
--
Added file: http://bugs.python.org/file26137/larry.platform.unamedtuple.2.diff
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
Third diff, incorporating all of Georg's suggestions.
--
Added file: http://bugs.python.org/file26138/larry.platform.unamedtuple.3.diff
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Done! And just in time for... something!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> enhancement
___
Python tracker
<http://bugs.python
Larry Hastings added the comment:
> The fix for this issue broke support for bytes in shutil.rmtree:
What platform? Windows, or non-Windows? It'll probably be obvious regardless,
but that might help.
--
___
Python tracke
Larry Hastings added the comment:
Your deduction is correct. listdir can't tell what the original argument type
was based on the output--path_converter abstracts away those details. So it
separately tests the type of the first argument. Staring at it again it's
about as clear a
New submission from Larry Hastings :
When you pass in a file descriptor as the first argument to listdir, its output
is a list of strings, not a list of bytes. This should be mentioned in the
documentation. It's also worth making a pass over the other functions
accepting an fd.
New submission from Larry Hastings :
Consider: should os.fwalk() support dir_fd? I think so. In fact, in
retrospect it seems like a bug that os.fwalk *doesn't* already support this.
Georg: is this a feature or a bugfix?
(Wish I'd thought of this Saturday!)
I actually di
Larry Hastings added the comment:
Maybe the correct fix for this is to change the interface?
os.listdir(path, *, dir_fd=None)
Then we'll pick up the return type (str/bytes) from the path variable.
It would make #15177 even easier too, should we go down that
Larry Hastings added the comment:
Nick, how do you feel specifically about listdir(path, *, dir_fd)? I'm
mentally exhausted from the past couple of days and have temporarily lost the
ability to infer.
--
___
Python tracker
Larry Hastings added the comment:
Nevermind, I'm an idiot. fdopendir doesn't support dir_fd as a separate path,
so listdir can't support it either.
There's an unwritten property of the os module on a POSIX system: all the
functions are essentially-atomic. This is usef
Larry Hastings added the comment:
My first cut at a patch. Made the logic in posix_listdir easy to follow, fixed
up the docstring and docs.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26139/larry.listdir.clarification.1.d
Larry Hastings added the comment:
Whoops, wrong issue, ignore that. (Meant for #15176, going there now.)
--
___
Python tracker
<http://bugs.python.org/issue15
Changes by Larry Hastings :
--
stage: patch review -> needs patch
___
Python tracker
<http://bugs.python.org/issue15177>
___
___
Python-bugs-list mai
Larry Hastings added the comment:
My first cut at a patch. Made the logic in posix_listdir easy to follow, fixed
up the docstring and docs. Posted in the correct issue this time.
(And Nick: I thought of that independently :D )
--
keywords: +patch
Added file: http://bugs.python.org
Larry Hastings added the comment:
What I did:
* Added dir_fd=None as a keyword only parameter.
* Gave top a default of ".".
* Passed through dir_fd in two spots--that was all it took!
* Made fwalk contingent on os.stat and os.open both being
in support_dir_fd, and os.listdi
Larry Hastings added the comment:
Second revision of patch.
* Removed os.fwalk from os.supports_dir_fd. As Georg points out,
you can't test it. (Well, you can, but only if the test would
have succeeded.)
* Changed fstat(fd) calls to stat(fd) calls.
--
Added file:
Larry Hastings added the comment:
Here's a variant of the patch adding os.walk(dir_fd=) support. I'm not pushing
for this. I'm not sure it's a must-have; it seems like a nice-to-have, but
we're past the time for nice-to-haves.
--
Added file: http://
Larry Hastings added the comment:
Removed "do we have os.listdir" checks from the unit tests. Yes, Virginia, we
always have os.listdir in Python 3.3.
--
Added file: http://bugs.python.org/file26145/larry.listdir.clarification.2.diff
Larry Hastings added the comment:
Regenerated fwalk(dir_fd=) patch to make Rietveld happy.
--
Added file: http://bugs.python.org/file26147/larry.fwalk.dir_fd.3.diff
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
Regenerated walk(dir_fd=) patch to make Rietveld happy.
--
Added file: http://bugs.python.org/file26148/larry.fwalk.and.walk.dir_fd.2.diff
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
Regenerated patch to make Reitveld happy.
--
Added file: http://bugs.python.org/file26149/larry.listdir.clarification.3.diff
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
GRAHH HULK SMASH
Regenerating again, because I wasn't actually fresh enough last time.
--
Added file: http://bugs.python.org/file26150/larry.listdir.clarification.4.diff
___
Python tracker
<http://bugs.py
Larry Hastings added the comment:
Fourth time's the charm.
--
Added file: http://bugs.python.org/file26151/larry.fwalk.dir_fd.4.diff
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
What's better than regenerating a bunch of diffs on the off chance that it'll
make Rietveld happy? Nothing, that's what.
--
Added file: http://bugs.python.org/file26152/larry.fwalk.and.wal
Changes by Larry Hastings :
Removed file: http://bugs.python.org/file26143/larry.fwalk.dir_fd.2.diff
___
Python tracker
<http://bugs.python.org/issue15177>
___
___
Pytho
Changes by Larry Hastings :
Removed file:
http://bugs.python.org/file26144/larry.fwalk.and.walk.dir_fd.1.diff
___
Python tracker
<http://bugs.python.org/issue15
Changes by Larry Hastings :
Removed file: http://bugs.python.org/file26147/larry.fwalk.dir_fd.3.diff
___
Python tracker
<http://bugs.python.org/issue15177>
___
___
Pytho
Changes by Larry Hastings :
Removed file:
http://bugs.python.org/file26145/larry.listdir.clarification.2.diff
___
Python tracker
<http://bugs.python.org/issue15
Changes by Larry Hastings :
Removed file:
http://bugs.python.org/file26148/larry.fwalk.and.walk.dir_fd.2.diff
___
Python tracker
<http://bugs.python.org/issue15
Changes by Larry Hastings :
Removed file:
http://bugs.python.org/file26149/larry.listdir.clarification.3.diff
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
Sure, for 3.3 anyway.
I think walk(dir_fd=) should be okay for 3.4. There's a better implementation
anyway, where walk() just calls fwalk() and strips the last element off the
yielded stuff. But movi
Larry Hastings added the comment:
While I was at it, I changed the subject to accurately reflect the changeset's
final disposition.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
title: Support os.walk(dir_fd=) and os.fwalk(dir_f
Larry Hastings added the comment:
Good news, everyone!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Larry Hastings :
Adds dir_fd support to os.walk(). Just re-yields from os.fwalk(), removing the
last element.
Note: Python 3.4.
--
assignee: larry
files: larry.os.walk.dir_fd.1.diff
keywords: patch
messages: 164023
nosy: larry
priority: normal
severity: normal
Changes by Larry Hastings :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue15187>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Patch attached. On my machine it used to leave six directories, now it leaves
none.
--
keywords: +patch
Added file:
http://bugs.python.org/file26161/larry.fix.shutil.test.tmp.dirs.1.diff
___
Python tracker
<h
Larry Hastings added the comment:
Georg, you want this fixed for beta 1?
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/issue15187>
___
___
Larry Hastings added the comment:
Actually I think Raymond makes a good point.
Re: symmetry: tbh that's nonsense. The reason for symmetry among functions in
the os module is because they do similar things--but this is because "form
follows function". We didn't decide t
Larry Hastings added the comment:
p.s. Raymond: fwiw, I think "makes it easy / hard for beginners" is only of
secondary importance. Certainly I think it's reasonable to point out in a
discussion, and if the beginners are easy to accommodate then okay. But if
there was somet
Larry Hastings added the comment:
Whoops, you wrote "for most users" rather than talking about beginners. Sorry
if I was responding to a point you weren't making ;-) I guess I assumed you
were coming at this at least partially while wearing your "
Changes by Larry Hastings :
--
assignee: -> larry
priority: normal -> release blocker
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyt
Larry Hastings added the comment:
This was fixed in 1fa50bbcc21f1458c1dc00ea733b76e6405b8cbb . (I think the
tracker had an aneurysm when the notification showed up.)
--
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
(No wonder it had an aneurysm!)
--
___
Python tracker
<http://bugs.python.org/issue15187>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
If this happens, in keeping with the new os module aesthetic, I suggest the
prototype should be
os.isdir(path, *, follow_symlinks=True)
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue12
Larry Hastings added the comment:
I assert that "followlinks" and "symlinks" are both bad names. I dislike
"followlinks" because "links" is ambiguous; both hard links and soft links are
"links", but it's only modifying behavior regardi
Larry Hastings added the comment:
It's amusing that using fwalk and throwing away the last argument is faster
than a handwritten implementation. On the other hand, fwalk also uses a lot of
file descriptors. Users with processes which were already borderline on max
file descriptors
Larry Hastings added the comment:
I dislike this and always have. I think it would look ugly and be obnoxious to
use.
If you really think you can get this in for 3.3, you will have to bring it up
with Georg. I think your chances are about zero
Larry Hastings added the comment:
First: there's no chance this will go into 3.1, 3.2, or 3.3 at this point.
Second: I can assure you that switching to the l... version of a function and
not following the last symlink is exactly what "follow_symlinks" is for.
Ple
Larry Hastings added the comment:
> It doesn't have to.
> Right now, it uses O(depth of the directory tree) FDs.
> It can be changed to only require O(1) FDs
But closing and reopening those file descriptors seems like it might slow it
down; would it still be a performance win?
Larry Hastings added the comment:
> I don't see how this is contrary to PEP 8. PEP 8 says nothing about
> the names of function arguments.
Certainly it says *something*:
http://www.python.org/dev/peps/pep-0008/#function-and-method-arguments
But I grant you, it only specificall
Larry Hastings added the comment:
> > after all, they *are* instance variables.
> Technically, they are local variables.
Yeah, tbh I was thinking "instance of an invocation" here. But PEP 8 probably
means "instance of a class" here.
Still, there are three class
Larry Hastings added the comment:
I'm not a security guy, but: shouldn't the os.unlink call when it isn't a
directory specify follow_symlinks=False? And wouldn't it be safer if the
os.rmdir() call also used dir_fd=?
Additionally, I think you missed some stuff for shut
Larry Hastings added the comment:
I'm pretty busy right now, please open a ticket for listdir.
_rmtree_safe_fd could remove the directory just after the recursive step using
the parent's dirfd. Of course you'd also have to add a rmdir for the
very-tippy-top after the o
Larry Hastings added the comment:
I want to mark this as wontfix.
>>> os.listdir in os.supports_fd
True
The concept we're struggling with here: is the "fd" you pass in to os.listdir a
"dir_fd"? I claim that it isn't. I'm trying to enforce the
Larry Hastings added the comment:
Like I said: use os.supports_fd.
--
___
Python tracker
<http://bugs.python.org/issue15217>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
I'm closing this. os.listdir should not be listed in supports_dir_fd, because
it has no dir_fd parameter.
For reference, we discussed all this previously in issue #15176.
--
resolution: -> invalid
stage: needs patch -> committed/reje
Larry Hastings added the comment:
Storchaka: please take it up with Antoine, he's the defender of the realm for
POSIX-functions-are-atomic iirc. I'd be happy with dir_fd for os.listdir,
though it may be too late for 3.3 anyway.
--
nos
Larry Hastings added the comment:
WFM. That is, unless people want to bring up additional
only-tangentially-related topics to annoy Hynek ;-)
How about those ? They're really having a year of it,
aren't they!
--
___
Python trac
Larry Hastings added the comment:
storchaka: I can (finally!) spend some time reviewing patches today. Which
ones do I look at? I'm guessing just the last two,
"followlinks-to-follow_symlinks-2.patch" and
"symlinks-to-follow_symlinks-2.patch". But I wanted to c
Larry Hastings added the comment:
Bad news: Fearless Leader (Georg) just told me on #python-dev that he's had a
change of heart and doesn't want this in 3.3. I've marked the bug 3.4, and
there's no rush on doing this work--we can't check it in until the 3.4 branc
Larry Hastings added the comment:
Georg just clarified: we can just change the parameter names for new APIs.
It's the deprecation / new parameter stuff we can't do for 3.3. So cut a
(much) simpler patch and let's get it in right quick.
--
versions: +Python
701 - 800 of 2415 matches
Mail list logo
