Larry Hastings added the comment:
> The register qualifier on the parameter does not alter the calling
> convention, it determines the storage class of the parameter variable
> within the function.
You assert that declaring a parameter as "register" instructs the compiler t
Larry Hastings added the comment:
I poked around in a draft of the next ANSI C standard dated April 12 2011.
They don't have much to say about the semantics of "register". The definition
is found in 6.7.1.6:
A declaration of an identiļ¬er for an object with storage-cla
Larry Hastings added the comment:
Having re-read the spec a couple times, I am now thoroughly confused and don't
know what to think. Certainly I now believe I was previously misinterpreting
aspects of the spec.
I still think removing "register" from the parameter lists of exte
Larry Hastings added the comment:
Duplicate of #17899.
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
type: -> resource usage
___
Python tracker
<http://bugs.python
Larry Hastings added the comment:
Second rev incorporating a suggestion from the ever-present Serhiy. Also, for
what it's worth, I walked through this with the debugger when using
os.listdir(0) and it worked fine.
--
Added file:
http://bugs.python.org/file
Larry Hastings added the comment:
Here's a patch for 3.3. There's been enough churn around listdir in trunk that
I was gonna have to write the patches separately anyway.
--
Added file:
http://bugs.python.org/file30521/larry.3.3.listdir.fd.leakage.b
Larry Hastings added the comment:
How about if the shell script detected that it was running on OS X and exited
with an error instructing the user to use the Python script instead?
I don't agree that this is a release blocker. Most people on OS X use the
prebuilt bin
Larry Hastings added the comment:
Patch for 3.3. or trunk?
--
___
Python tracker
<http://bugs.python.org/issue17899>
___
___
Python-bugs-list mailing list
Unsub
Larry Hastings added the comment:
I've been staring at the code. I just realized: we really should call
path_error() as soon as possible once we detect the error--as Christian's patch
points out, close() will clear the error. So instead of playing footsie with
assigning (further
Larry Hastings added the comment:
Attached is a new patch for trunk, removing the #undef HAVE_FDOPENDIR debug
scaffolding, and rearranging the lines of error handling so close doesn't clear
the errno before we use it.
By cracky, while most days I do enjoy the exacting pedantry of the P
Larry Hastings added the comment:
If someone will give me an LGTM I'll check these in tonight, honest, cross my
heart.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
And here's an updated patch for 3.3; the only change from the previous 3.3
patch is that I call path_error before calling close.
--
Added file:
http://bugs.python.org/file31021/larry.3.3.listdir.fd.leakage.bug.2.
Larry Hastings added the comment:
Looks like it's too late for Christian, he's already generated the report with
Coverity:
https://docs.google.com/file/d/0B5wQCOK_TiRiMWVqQ0xPaDEzbkU/edit
But I'm still interested in putt
Larry Hastings added the comment:
I swear I've seen a compiler where you couldn't assign to errno. But now I'm
pretty sure it was MSVC, and possibly a version back in the 90s. So I'm happy
to live in a world wher
Larry Hastings added the comment:
Okay, this bug has dragged on long enough. Serhiy already said they looked
good to him, and I am now declaring that that's good enough for me.
I'll check in my patches Saturday-ish unless someon
Larry Hastings added the comment:
There is now a need to rush. I'm hoping to cut the release in about two days,
so we can have Python 3.4a1 on time. Can we resolve this in the next day or
two? Sorry for the short notice.
--
___
Python tr
Larry Hastings added the comment:
Is there any resolution for this likely to happen soon? I'm hoping to cut
Python 3.4a1 in about two days, so one of three things is gonna happen:
1) This gets fixed.
2) This gets lowered from "release blocker".
3) Th
Larry Hastings added the comment:
This issue seems to have stalled. But it's still marked as a release blocker,
which means I can't release Python 3.4a1 in two days if this issue is still
open.
One of three things will happen:
1) This issue is marked "closed".
2) This
Larry Hastings added the comment:
This is still marked as a release blocker. I guess this is a "tickler" for
Ezio to go check and see if there's a new entities file.
Ezio: can you get this issue closed or downgraded in th
Larry Hastings added the comment:
What's the status of this? I want to release Python 3.4a1 in two days, and
this issue is still marked as a "release blocker".
Given the age of this issue I doubt anything is going to happen in the next two
days. Unless I hear a great wailing
Larry Hastings added the comment:
I'm downgrading this to "deferred blocker". We'll make sure it happens before
Python 3.4.0, but there's no need to hold up Python 3.4a1 for this.
--
priority: release blocker -> deferred blocker
__
Larry Hastings added the comment:
Okay, downgrading to "deferred blocker".
--
priority: release blocker -> deferred blocker
___
Python tracker
<http://bugs.pytho
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'
601 - 700 of 2415 matches
Mail list logo
