Larry Hastings added the comment:
And this will hold up Python 3.4a1, as I can't close #13463 until this is
closed first. So I'm closing this as wontfix.
--
nosy: +larry
resolution: -> wont fix
status: open -> closed
___
Pytho
Larry Hastings added the comment:
This was held up by #5302, so I just closed that one too as the same rule
applies.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Larry Hastings added the comment:
Can I downgrade this to "deferred blocker"? That means we still need to deal
with it before the release, but we don't have to hold up Python 3.4a1 for it.
--
___
Python tracker
<http://bugs.pyt
Larry Hastings added the comment:
You're talking about a new bug. Please open a new issue.
I'm closing this issue right now because I want to cut a Python 3.4 alpha
release tomorrow, and this bug is marked Python 3.4 and "release blocker".
--
resolution: -
Larry Hastings added the comment:
I'm downgrading this to "deferred blocker". I'm sure we'll get it fixed for
Python 3.4 final, but in the meantime there's no sense in holding up Python
3.4a1 for it.
--
priority: relea
Larry Hastings added the comment:
Thanks, Matthias! Now I can cut 3.4a1 on time. :)
--
___
Python tracker
<http://bugs.python.org/issue18257>
___
___
Python-bug
Larry Hastings added the comment:
Marking as closed/fixed.
--
assignee: -> larry
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Larry Hastings added the comment:
This broke the test suite on all the 32-bit Linux buildbots. Sample output is
here:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/8349/steps/test/logs/stdio
There's no obvious fix, and I want to cut 3.4a1 right about now, s
Larry Hastings added the comment:
Yup, that's a bug. My fault too. I think it should go in to the next 3.3 as
well.
I worry that this may be a similar situation to fchmodat--see the comment in
Lib/os.py--but for now let's be brave and add HAVE_FCHOWNAT to have_functions
a
Larry Hastings added the comment:
Benjamin, do you want my elaborate fix in for 2.7? It means adding two new
converters, one for pid and one for gid, and switching everything that takes
pid/gid arguments to use those.
--
nosy: +benjamin.peterson
Larry Hastings added the comment:
Now fixed in trunk. I am waiting to hear from Georg and the
only-recently-pinged Benjamin to see if they want these fixes in 3.3 or 2.7.
--
___
Python tracker
<http://bugs.python.org/issue15
Larry Hastings added the comment:
Okay then, closing.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Larry Hastings:
The getxattr() system call retrieves an "extended attribute" on a file. When
you call it you pass in a buffer and a size. The expected behavior is, if you
pass in a buffer that's too small, the function returns -1 and sets errno to
ER
Larry Hastings added the comment:
Here's a patch for trunk. It's essentially what salinger wrote, but as a patch
file so it works for "review".
I poked around a little to make sure we weren't going to have another baffling
situation like fchmodat. AFAICT, nope, it&
Larry Hastings added the comment:
And here's a patch for 3.3. I should have mentioned--both these patches pass
the same tests as an unmodified trunk. So I think it's just ready to go in.
--
Added file: http://bugs.python.org/file31216/larry.have_fchownat.3.3.p
Larry Hastings added the comment:
Georg, I'm gonna commit this for 3.4. You want it in 3.3 as well? I claim
it's 100% a bugfix.
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
Fixed in 3.3 and trunk. Thanks for the report!
--
assignee: -> larry
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http
Larry Hastings added the comment:
Attached is an updated patch, this time for 3.3. (So I'm guessing we won't get
a "review" link.) It incorporates Benjamin's two comments.
--
Added file: http://bugs.python.org/file31249/larry.set
Larry Hastings added the comment:
Kill what thing? The review link? I love that thing?
Anyway, we did get a review link, hoopla!
--
___
Python tracker
<http://bugs.python.org/issue18
Larry Hastings added the comment:
+1
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue18716>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Closed as this is a subset of #18722.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Larry Hastings :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue13248>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Sorry about the delay; laptop died, finally dealt with reviving the data off
it. Also: fixed spelling error in title.
--
title: add st_*time_ns fileds to os.stat(), add ns keyword to os.*utime*(),
os.*utimens*() expects a number of nanoseconds
New submission from Larry Hastings :
There are some functions in the os module that do much the same thing but
differ only in minor ways, like
* whether or not they follow symbolic links (stat vs lstat)
* taking an extra "dir_fd" parameter (chmod vs fchmodat(3.3))
It would be be
Changes by Larry Hastings :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue14626>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
storchaka: sorry for the long delay, somehow I missed your reply in
python-ideas.)
You said you envision this as a big patch. Could I convince you to try and
make a series of smaller patches? It should be easy to break up into small
pieces--do one patch
Larry Hastings added the comment:
r.david.murray said:
> No, Guido's boolean keyword dislike is not about things
> being unclear at the call site.
I wasn't referring to Guido specifically, just general code smell complaints
about boolean parameters.
> That is (I believ
Larry Hastings added the comment:
It's true that, for example, dir_fd parameters won't work on Windows. The
solution is to always accept the parameters and throw NotImplementedError on
platforms where the functionality isn't available.
Here are my thoughts on the int
Larry Hastings added the comment:
Attached is round 1 of my patch adding the ns= parameter to utime, futimes, and
lutimes.
Some notes:
* I admit the "see utime for use of times and ns" documentation dodge
(for both Doc and docstring) is lazy. Yet I'm still hoping to get
Larry Hastings added the comment:
> futimens() has nice feature: it is possible to only update atime
> only update mtime, or use "now" as the new atime and/or mtime.
YAGNI. Worst case, you can use call futimes twice, once with no args, then
fstat() it to get the current-ish
Larry Hastings added the comment:
Second round of my patch, incorporating nearly all of Victor's suggestions.
Thanks, Victor!
--
Added file: http://bugs.python.org/file25356/larry.utime.ns.2.patch
___
Python tracker
<http://bugs.py
Larry Hastings added the comment:
Anybody else? I guess I'm gonna jst miss Alpha 3, but if nobody has any
other objections I'll check this in today (Thursday).
If you want me to hold off just let me know.
--
___
Python trac
Larry Hastings added the comment:
FYI, Martin was replying to Guido's comment from more than a month ago, when I
posted revision #2 of my first patch series. By sheer coincidence I posted
revision #2 of a new patch series yesterday. But Reitveld worked fine for that!
Anyway--no com
Larry Hastings added the comment:
Here my first stab at a comprehensive proposal. Each section represents a
specific new function argument, and a list of functions that the argument be
added to.
All new arguments are keyword-only and optional.
All functions mentioned are in the os module
Larry Hastings added the comment:
> I personally think that offering mere wrappers around syscalls doesn't
> make much sense: Python is a very-high level language, and so should
> its library be.
I very much agree. I suggest anyone who thinks the os module is a thin
veneer over
New submission from Larry Hastings :
Currently functions that parse their arguments with the PyArg_ParseTuple family
which want to take a boolean-ish parameter face two choices:
* take an "int", then test whether or not the int is 0, or
* take an "object", then
Larry Hastings added the comment:
> For this purpose it is appropriate to use a special converter
> (with 'O&').
The converter works--but, then, a similar converter would also work
for double, and float, and long long and many others. If long long
is special enough to me
Larry Hastings added the comment:
@haypo: Thanks for pointing that out buildbot failure! The OpenIndiana
buildbot was bit by a rounding error. I fixed it by adding in a fudge factor
it--I snuck in one last change just now. I weakened the unit test as follows:
-self.assertEqual
Larry Hastings added the comment:
My first patch. Adds 'p' and 'P', along with documentation and unit tests.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file25441/larry.parse.tuple.p.and.P.1.diff
___
Larry Hastings added the comment:
We don't!
The test that failed compares the ns_[amc]time and ns_[amc]time_ns fields to
ensure they're roughly equivalent. Note that the former fields are floats,
which by now ought not to be n
Larry Hastings added the comment:
> bba131e48852 causes crashes on Windows.
>
> The attached patch fixes the crash and makes test_os pass for me.
>
> However, using "PyErr_ExceptionMatches(PyExc_RuntimeError)" to check
> whether to try again using na
Larry Hastings added the comment:
Let me recap, just to make sure I have it straight. There are two errors on
Windows:
* The ! on (what is currently) line 3770 is wrong:
if (!utime_read_time_arguments(&ua)) {
* If you pass in a Unicode string but also pass in both times and ns,
Larry Hastings added the comment:
Looks good to me. You're a core contributor, yes? If not let me know and I'll
commit it.
Though I must admit I'm baffled how I haven't seen that crash. I've run the
unit tests a zi
Larry Hastings added the comment:
By "the unit tests" I meant I ran the whole suite: Lib/test/regrtest.py. I
know that runs test_os, and I assume it runs test_posix too.
I just ran test_posix by hand and it passed.
I'm developing on Linux (64-bit) in
Larry Hastings added the comment:
I looked through the Python sources and couldn't find any instances of a
function or method with an argument that only allowed you to pass in either
True or False.
Serily already said he would use 'P' over 'p', although I too am u
Larry Hastings added the comment:
> I think there should be a test case also where PyObject_IsTrue gives an
> exception (which I think can happen if __bool__ raises an exception).
I'd be happy to add such a test, but I don't know of any types like that. Can
an
Larry Hastings added the comment:
Added test forcing a failure for 'p' (and 'P'). This made me have to handle
errors a little differently, so it was definitely good to test it. Thanks for
the suggestion, Martin!
Also changed wording in documentation ever-so-slightly.
-
Larry Hastings added the comment:
Attached is rev 3 of my patch, incorporating mainly backing out of dumb ideas.
Thanks for the feedback, Serhiy and Mark!
> My name is Serhiy. :)
My genuine apologies! In my defense it was rather late.
> 'P' has the advantage that you can
Larry Hastings added the comment:
Serhiy, I'm having a little trouble with your English. (But I'm sure your
English is far better than my... uh, anything besides English.) So let me ask
a question with a clear yes/no answer:
Do you still think 'P
Larry Hastings added the comment:
> I hope I haven't made a lot of mistakes in the previous sentence.
It depends, do you consider three "a lot"? ;-)
Attached is a new patch removing 'P'. (The regrtest is still running but I
don't expect any failures.) I&#
Larry Hastings added the comment:
Eh, it was ready, why wait? Thanks everybody for your feedback!
--
___
Python tracker
<http://bugs.python.org/issue14
Larry Hastings added the comment:
> I would have expected a bool parse code to insist on a boolean,
I originally had a second form ('P') that insisted on a boolean as you suggest.
But nobody could come up with a use case. So I removed it in the final patch.
Please see this
Changes by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue14705>
___
___
Changes by Larry Hastings :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14705>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Larry Hastings :
If you write a PyArg_Parse "converter", and your conversion hits an error, you
must raise an exception and error out. But, since your converter has no
context about the parameter, it can't provide any helpful information in the
erro
Changes by Larry Hastings :
--
assignee: -> larry
___
Python tracker
<http://bugs.python.org/issue14739>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Larry Hastings :
--
components: +Interpreter Core
stage: -> needs patch
type: -> enhancement
___
Python tracker
<http://bugs.python.org/i
New submission from Larry Hastings :
There's code like this in skipitem() in Python/getargs.c:
case 'b': /* byte -- very short int */
/* ... a zillion more case statements here ... */
case 'C': /* unicode char */
case 'p': /* boolean predi
New submission from Larry Hastings :
skipitem() (in Python/getargs.c) has to be taught about all the "format units"
understood by PyArg_Parse. There's a note at the top of the
format-unit-understanding code saying
When you add new format codes,
please don't forget p
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:
> I'm not sure what you're proposing to fix. It seems to save at
> most a couple of lines of (obvious) code?
Well, I *did* specify low priority.
Attached is the patch for what I had in mind.
> At least Py_ssize_t *could* have a d
Larry Hastings added the comment:
Thanks for the double-check. I should have more confidence!
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Larry Hastings :
I recently fixed an old bug: some time ago someone added support for a new
"format unit", 'Z', to PyArg_Parse(), but neglected to add matching support for
it to skipitem(). Benjamin asked for a regression test. Initially I said,
oka
New submission from Larry Hastings :
If you pass a valid PyUnicodeObject into PyUnicode_AsObject(), it incref's the
original object and returns it.
If you pass a valid PyBytesObject into PyBytes_AsObject()... it fails.
I assert that in the PyBytes_AsObject() should behave
Larry Hastings added the comment:
The appropriate four line patch. (Six with whitespace.)
--
keywords: +patch
stage: needs patch -> patch review
Added file:
http://bugs.python.org/file25682/larry.pybytes_fromobject.identity.1.diff
___
Pyt
Larry Hastings added the comment:
1) Yes, whoopsies. It's late.
2) It fails, as in, it returns NULL.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
I can't reproduce this, and it was pretty late in my day when I saw it, so
let's assume I was mistaken and PyBytes_CheckBuffer() works fine. Nevertheless
I think the patch is a good idea--why create a new object when you don't have
to?
Larry Hastings added the comment:
Changing the name of the report to accurately reflect reality. If you passed
in a bytes object, PyBytes_FromObject would create a new object, when all it
really needed to do was incref and return. My checkin in a minute will add
that shortcut
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:
> As an example, ``os.startfile("a.py")`` will usually run `a.py`
> in the Python interpreter, while ``xdg-open a.py`` it will
> usually open the source code in an editor on Linux.
Well, so how about on UNIX shutil.launch (or whatever it
New submission from Larry Hastings :
The prototype for os.symlink on Windows adds a "target_is_directory" flag,
which indicates whether or not the destination is a directory.
Surely we could detect that and pass in the correct value ourselves? A quick
GetFileAttributes() call wo
Larry Hastings added the comment:
> Could even add an `operation` parameter to let the caller
> select actions,
> [...]
> operation in ['auto', 'run', 'edit', 'display', 'browse',
> 'explore', 'share', 's
Larry Hastings added the comment:
Here's my first pass at a patch. For this patch,
I took the proposal to its logical extreme: I removed
every function in os that was both mildly redundant
with an existing function *and* has been added since
3.2, and moved that functionality to the equiv
Larry Hastings added the comment:
> In Linux we could `try` nautilus then Mozilla
> (file://.../containing_folder) then fall back to a shell
> `cd && ls` if no browser is available, raising NotImplemented
> if all else fails... until someone implements for that
> user
Larry Hastings added the comment:
Second pass at my patch. Incorporates suggestions from Serhiy's
review--thanks, Serhiy!
Still not ready for checkin. > 80 col lines, no docs, docstrings are messy.
But code is ready for (further) review. Code passes regression test suite
withou
Larry Hastings added the comment:
I'm not sure that "long" and "impressive" are words that go together when
describing a patch ;-)
--
___
Python tracker
<http:
Larry Hastings added the comment:
I guess the answer was "no".
Attached is a new diff as you suggest. It isn't really any shorter--in fact
it's about 20% longer. Though I freely admit it is more written-in-Python-y.
The test currently passes. If you add support for a n
Larry Hastings added the comment:
Here's a nice fresh minor update.
Notes on this third patch:
* The docstrings are now done.
* I discovered that fchmodat() doesn't actually support
AT_SYMLINK_NOFOLLOW! glibc documents using the flag, then
comically notes that it doesn'
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.
601 - 700 of 2389 matches
Mail list logo
