Change by Larry Hastings :
--
components: +Interpreter Core -Argument Clinic
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue41716>
___
___
Pytho
Larry Hastings added the comment:
Nope, it's not fixed.
--
resolution: fixed ->
stage: resolved -> needs patch
status: closed -> open
___
Python tracker
<https://bugs.pyth
Larry Hastings added the comment:
It depends on whether or not I get any more fixes for the rest of the month.
(Theoretically 3.5 support ends on Sep 13, but I decided to extend it to the
end of the month.)
I filed this on July 1, so it's already been two months, and the develope
Larry Hastings added the comment:
> Also note that httplib (python-2.7.18) seems to be affected too. Any
> particular reason for it not to be listed in the same vulnerability page?
Yes: 2.7 has been end-of-lifed and is no longer sup
Larry Hastings added the comment:
A day and a half to go! Again, assuming that this won't be fixed and 3.5 will
go EOL without supporting this year's Linux distro updates.
--
___
Python tracker
<https://bugs.python.o
Larry Hastings added the comment:
FWIW: I think David's cited behavior proves that the GIL is de facto a
scheduler. And, in case you missed it, scheduling is a hard problem, and not a
solved problem. There are increasingly complicated schedulers with new
approaches and heuri
Larry Hastings added the comment:
Yes. Read the documentation for "defaultdict".
In the future, please read the documentation before filing bugs.
--
components: -Argument Clinic
resolution: -> not a bug
stage: -> resolved
status: open -> cl
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue42310>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Victor: I think your patch merits its own tracker issue; it's only tangentially
related to the proposed changes to os.stat.
That said, please do add me to the nosy list if you create one.
One more thing: I haven't given it a lot of thought, so ther
Larry Hastings added the comment:
Victor: I *think* Raymond's comments were directed at my patch, not yours.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Larry Hastings :
Following on from Guido's rejection of PEP 410:
http://mail.python.org/pipermail/python-dev/2012-February/116837.html
This bug is the proposed hammering-out space for how to preserve exact metadata
for st_atime / st_mtime between os.stat and os.utime.
Larry Hastings added the comment:
Guido proposed st_atime_ns et al. I'll make an alternate proposal.
I'd like to avoid tying ourselves to ns resolution. As MvL said: "I don't want
to deal with this issue *again* in my lifetime".
If all we want is to facilitate c
Larry Hastings added the comment:
I suggest that publishing nanoseconds as a plain int would be a nasty API.
Consider what it would do to os.utime:
if isinstance(mtime, int):
# must be st_mtime_ns, it's in nanoseconds, use as-is
value = mtime
else:
a
Larry Hastings added the comment:
(D'oh. My pseudo-code should have said
value = int(mtime * 10)
for that second assignment. Hopefully my point was still clear.)
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
@pitrou: What would that look like when passed in to os.utime?
--
___
Python tracker
<http://bugs.python.org/issue14
Larry Hastings added the comment:
My mistake! That ought to teach me to bound out of bed Sunday morning with my
"brilliant realization". (But it probably won't.)
I volunteer to implement this, with the new custom class for the os.stat
object. I'll have it done no
Larry Hastings added the comment:
Gah! This one fell through the cracks.
Attached is an updated patch with Ezio's "Python-level" fix, and a little more
paragraph tidying. (Apart from that one ^ dash, the only changes
between r1 and r2 are eols.)
Unless I hear otherwise,
Larry Hastings added the comment:
This was committed last September; I should have marked it closed then.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
Given Guido's rejection of PEP 410, this won't happen, so I'm closing this bug.
Our BFDL has specifically rejected any of the complicated representations; he
ruled that all we need are new _ns fields representing the time in nanoseconds,
and
Larry Hastings added the comment:
Given Guido's rejection of PEP 410, this won't happen, so I'm closing this bug.
Our BFDL has specifically rejected any of the complicated representations; he
ruled that all we need are new _ns fields representing the time in nanoseconds,
and
Larry Hastings added the comment:
Whoops--I hadn't updated my repo since last year, and someone had already
changed to :c:macro:, :c:func:, and :c:type:. When will I learn!
Attached is a new diff with those changes, against revision @4c6662090870 (on
the 2.7 branch). Also, while I w
Larry Hastings added the comment:
I have some more changes for cporting.rst (see #13086). Once those are in,
I'll manually merge the edits over to 3.2, then forward-port to trunk. Does
anyone want to see those as patches before I commit them? (Your silence will
be interpreted as &quo
Changes by Larry Hastings :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Python-bugs-list mailing list
Unsubscri
Larry Hastings added the comment:
@eric.araujo: I talked to Brett about it. We don't pretend that Python 3.0
never existed; we tell people it's unsupported and unsuitable for production
use. At his suggestion I added a statement to that effect, and left the rest
the same.
Larry Hastings added the comment:
Now checked in to 2.7, 3.2, and default. Thanks everyone!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
Now checked in to 2.7, 3.2, and default. Thanks everyone!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Larry Hastings :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue13405>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Um, doesn't the rejection of PEP 410 mean this should be discontinued?
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
After Guido rejected 410 and said "let's just do nanoseconds, take it to the
bug tracker" I created issue #14127. Your having changed this issue to be the
same thing means that at least one of 'em is redundant. Could you engage on
tha
Larry Hastings added the comment:
Actually, I'm hoping that by the time we get better than nanosecond resolution,
we can also switch to 128-bit floats, and then the existing st_[acm]time field
will become the preferred representation once more. What goes around comes
a
Larry Hastings added the comment:
Well, Guido has already nixed future-proof formats, see his comments above:
"I take full responsibility for fixing the precision at ns."
So hope is all I have left.
--
___
Python tracker
<http://bu
Larry Hastings added the comment:
I grant you that (int, float) is probably, theoretically better than (int,
int). But it's academic as Guido has ruled against anything but a straight int
representing nanoseconds, and I doubt he's gonna chang
Larry Hastings added the comment:
I just asked Guido in person, and he says he never intended to suggest
accepting a (sec, nsec) tuple. os.*utime* may accept atime and mtime as either
float seconds-since-the-epoch, or int nanoseconds-since-the-epoch when passed
in using the ns= named
Larry Hastings added the comment:
> Larry, are you sprinting on this? I'd love to help.
I am. Come on by--mi CPU es tu CPU!
--
___
Python tracker
<http://bugs.python.org
Larry Hastings added the comment:
Guido suggested I break the work up into small patches. So here's the first
patch: adds st_?time_ns fields to os.stat() result. Includes doc changes and a
reasonable smoke-test in the regrtest suite; suite passes all expected tests.
FYI I wasn't
Larry Hastings added the comment:
I was notified by email of both Antoine's and Guido's reviews.
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
My revised patch, incorporating changes suggested by Antoine and Guido.
--
Added file: http://bugs.python.org/file24859/larry.st_mtime_ns.patch.2.txt
___
Python tracker
<http://bugs.python.org/issue14
Larry Hastings added the comment:
Attached is a second patch that adds keyword-only argument support to
PyArg_ParseTupleAndKeywords. This was developed in isolation.
The magic character is '$'; I would have used '*', but we already use '*' in
the format stri
Larry Hastings added the comment:
Do you insist? It's a small patch, and I need it as a precondition to posting
the... *third* patch in this series, which adds the ns= parameter to utime and
its brothers. (Most of the patch is test and doc; it really only adds about
twenty lines
Larry Hastings added the comment:
A fresh patch for adding st_mtime_ns etc to os.stat output. This is the same
as last night's patch but with fresh line numbers. (Generated against
44eba26951f6.)
--
Added file: http://bugs.python.org/file24875/larry.st_mtime_ns.patch.
New submission from Larry Hastings :
This has been split off from #14127 at Antoine's request.
The attached patch adds support for keyword-only arguments to the
PyArg_ParseTupleAndKeywords() family of functions. Includes doc and test.
I used '$' to indicate "all param
Larry Hastings added the comment:
I've created a separate issue for adding keyword-only parameter support to
PyArg_ParseTupleAndKeywords, #14328. I've also posted a new patch to that
issue incorporating Greg's suggestions. Please file all further comments
regarding this topi
Larry Hastings added the comment:
It frankly never occurred to me that you'd want mandatory keyword-only
arguments. Implementing them as optional-only was easy; I'm not sure but
making them possibly mandatory (or both!) might complicate matters.
Is there a use ca
Larry Hastings added the comment:
How about we leave it for now, and if we need it later we can fix the
implementation. Adding that feature won't break existing calls--we'll just
permit $ to occur before/without | in the for
Larry Hastings added the comment:
BTW, I have the os.utime patch nearly ready for review; it works, it just needs
doc and test. But it's dependent on this patch--and it'd be smoother if #14127
were finished too. So I'll hold off on posting the new patch until the fates
o
Larry Hastings added the comment:
Attached is r3 of my patch incorporated Benjamin's suggestions.
> I want #14325 to go in first.
Why do you care? If I get signoff before 14325 does please explain to me why I
should wait. They don't touch the same lines; should be a clean mer
Larry Hastings added the comment:
Updated patch incorporating only one of Antoine's latest suggestions. Please
see my reply on Reitveld for r3 as to why I skipped two of your three
suggestions.
--
Added file: http://bugs.python.org/file24884/larry.st_mtime_ns.patch.
Larry Hastings added the comment:
> Shouldn't using vgetargs1 with '$' in the format string just be
> an error? vgetargs1 doesn't know anything about keyword arguments.
Thank you for catching that! Serves me right for search-and-destroy style
development--I'm n
Larry Hastings added the comment:
Incorporated Greg's (hopefully) parting shot. Also put the "as an integer"
back for the docs. Finally, munged the note about float seconds vs integer
nanoseconds a bit; I think it's an improvement.
Can I get the go ahea
Larry Hastings added the comment:
Incorporated the latest round of suggestions from Benjamin's most recent--and
very thorough!--review. Thanks, Benjamin!
--
Added file: http://bugs.python.org/file24912/larry.parsekwonly.diff.5.txt
___
P
Larry Hastings added the comment:
Anyone else? Or can I get the go-ahead?
--
___
Python tracker
<http://bugs.python.org/issue14328>
___
___
Python-bugs-list m
Larry Hastings added the comment:
Revision 7 of my patch. Incorporates all suggestions from Georg. Added "as an
integer" in the docs to make Antoine happy.
If I fail to create the "billion" int in INITFUNC, I return NULL and leak
references. I figure this is fine,
Larry Hastings added the comment:
Incorporated Victor's reinstated assert suggestion. Fingers crossed.
--
Added file: http://bugs.python.org/file24952/larry.st_mtime_ns.patch.8.txt
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
> The patch looks good to me. I was going to commit it
> but then I realized that Larry is a core developer.
Indeed; please permit me the pleasure of checking it in myself. That is,
assuming I actually get the go-ahead someday. (Probably in the far
Larry Hastings added the comment:
Whoops! Actually, I did. But then I promptly forgot about them. They're now
all incorporated; please see attached patch.
--
Added file: http://bugs.python.org/file24955/larry.parsekwonly.diff.7.txt
___
P
Changes by Larry Hastings :
--
keywords: -patch
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Larry Hastings added the comment:
Sorry to let this slide but I just got back from vacation. Unless anybody has
any more feedback I'm checking this in tomorrow (Wednesday April 4). Phew!
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
It's not surprising that you crashed the CPython interpreter by using
ctypes--it's very easy to do by accident, or via a bug in your own code.
That's why we don't accept crash reports involving ctypes.
Also, it's rude to "nosy
Larry Hastings added the comment:
Inada-san, while it is best to not call PyDict_ functions without holding the
GIL, it doesn't matter unless one creates a second thread. The GIL doesn't
even exist until Python creates a second thread.
But, I too don't want bugs.python.
Change by Larry Hastings :
--
assignee: -> eric.smith
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue37003>
___
___
Python-bugs-list mai
Larry Hastings added the comment:
Maynard is unsupported; it only understands the old bytecode format, pre-3.6
16-bit "wordcode".
https://docs.python.org/3.6/whatsnew/3.6.html#optimizations
--
___
Python tracker
<https://bu
Larry Hastings added the comment:
New changeset 221178aea686abf13ff92b7e2b5ed3e739a53b3f by larryhastings
(Gregory P. Smith) in branch '3.5':
[3.5] bpo-36816: Update the self-signed.pythontest.net cert (GH-13192) (#13200)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset 4fe82a8eef7aed60de05bfca0f2c322730ea921e by larryhastings (Victor
Stinner) in branch '3.5':
bpo-35907, CVE-2019-9948: urllib rejects local_file:// scheme (GH-13474)
(GH-13505) (#13510)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset 4655d576141ee56a69d2052431c636858fcb916a by larryhastings (Steve
Dower) in branch '3.5':
bpo-36742: Fixes handling of pre-normalization characters in urlsplit()
(GH-13017) (#13042)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset afe3a4975cf93c97e5d6eb8800e48f368011d37a by larryhastings (Miro
Hrončok) in branch '3.5':
bpo-30458: Disallow control chars in http URLs. (GH-12755) (#13207)
https://github.com/python/cpython/commit/afe3a4975cf93c97e5d6eb8800e48f
Larry Hastings added the comment:
"Special cases aren't special enough to break the rules." I want the error
message to mirror the API, which it currently does. If we swapped them, the
error message would now contradict the API. So no, I don't support swapping
"sr
Larry Hastings added the comment:
Serhiy, I don't see where you got a full review of this change. Eryksun
reviewed the code and asked for changes; you made the he asked for changes but
didn't get any further review. Nor did you get a full review / "looks good to
me"
Larry Hastings added the comment:
It seems that os.execve() still permits this, even on Windows. Shouldn't we
solve it there too? (Thanks to Steve Dower for realizing this.)
--
import os
cmdline=["/usr/bin/printenv"]
env={'a=b': 'c'}
os.execve(cmdline[0]
Larry Hastings added the comment:
(never-mind, 3.6.1 still permits this, but I see that it's been fixed in trunk)
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
New changeset fe82c46327effc124ff166e1fa1e611579e1176b by larryhastings (Serhiy
Storchaka) in branch '3.4':
[security][3.4] bpo-30730: Prevent environment variables injection in
subprocess on Windows. (GH-2325) (#2362)
https://github.com/python/cpyt
Larry Hastings added the comment:
Python 3.4 no longer accepts bug fixes; it is in "security fixes only" mode.
Since this is not a security fix, it will not be accepted into Python 3.4.
If this bug affects other versions of Python, please file a new bug. Although,
unless you
Larry Hastings added the comment:
Will this be backported to 3.3 or 3.6? I don't see a PR or checkin for either
of those versions on this issue, and both those versions are open for security
fixes.b
--
nosy: +larry
___
Python tracker
Larry Hastings added the comment:
I don't quite understand what's happening on this issue. I see that master,
3.6, 3.6, and 2.7 have been upgraded to expat 2.2.0. This issue was created to
upgrade CPython to 2.2.0. But the PR against 3.3 and 3.4 upgrade expat to
2.2.1?!
I
Larry Hastings added the comment:
Yes, and thank you for submitting the PR to backport it to 3.4!
(And thank you for backporting it to 3.3, too!)
--
___
Python tracker
<http://bugs.python.org/issue30
Larry Hastings added the comment:
New changeset f7344798e57da6b9c4ed9372e8eaecde80989c86 by larryhastings (Serhiy
Storchaka) in branch '3.4':
[3.4] [3.5] bpo-27945: Fixed various segfaults with dict. (GH-1657) (GH-1678)
(#2248)
https://github.com/python/cpyt
Larry Hastings added the comment:
Please instead choose to use bpo-30694 for the upgrades of 3.3 and 3.4 to expat
2.2.1. I guess there are historical reasons why the PRs are here, but bpo
stands as a historical record; let's not confuse posterity by upgrading to
2.2.1 using a bpo
Larry Hastings added the comment:
Okay. Closing this bug, because all the branches that are being upgraded to
expat 2.2.*0* have already gotten their upgrades. Job done.
The discussions for PRs 2203 and 2204 should move to Issue #30694, which is for
the upgrade to expat 2.2.*1
Larry Hastings added the comment:
New changeset 71572bbe82aa0836c036d44d41c8269ba6a321be by larryhastings (Victor
Stinner) in branch '3.4':
[3.4] bpo-29591, bpo-30694: Upgrade Modules/expat to libexpat 2.2.1 (#2164)
(#2203)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset 71572bbe82aa0836c036d44d41c8269ba6a321be by larryhastings (Victor
Stinner) in branch '3.4':
[3.4] bpo-29591, bpo-30694: Upgrade Modules/expat to libexpat 2.2.1 (#2164)
(#2203)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset 71572bbe82aa0836c036d44d41c8269ba6a321be by larryhastings (Victor
Stinner) in branch '3.4':
[3.4] bpo-29591, bpo-30694: Upgrade Modules/expat to libexpat 2.2.1 (#2164)
(#2203)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset cc54c1c0d2d05fe7404ba64c53df4b1352ed2262 by larryhastings (Victor
Stinner) in branch '3.4':
bpo-30500: urllib: Simplify splithost by calling into urlparse. (#1849) (#2291)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset 6f6bc1da8aaae52664e7747e328d26eb59c0e74f by larryhastings (Victor
Stinner) in branch '3.4':
bpo-26657: Fix Windows directory traversal vulnerability with http.server (#782)
https://github.com/python/cpyt
Larry Hastings added the comment:
Here, I'll remove 3.4 and 3.5 from the versions affected. Now everybody can be
pedantic!
--
versions: -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Correct. But technically 3.3 is being upgraded to 2.2.*1*, which is being
tracked on--repeating myself here--Issue #30694.
--
___
Python tracker
<http://bugs.python.org/issue29
Larry Hastings added the comment:
I'll accept this as a backport for 3.4. I'm convinced that, although the
sample programs don't crash in release builds, the behavior is wrong and could
be exploited.
Will someone have time to create the PR in the next day or two? (It&#
Larry Hastings added the comment:
I tested this in a freshly-built 3.4.6. Although it reproduced the behavior
you're complaining about--it threw the assert in Armin's test.py, and Serhiy's
issue28427.py prints an admonishing FAIL--neither test *crashes* CPython. So
I'm
Larry Hastings added the comment:
I'm closing this. It isn't a security issue, so it's not applicable for 3.4.
3.5 is about to close for bugfixes too, so you'd have to work very... quickly.
If this applies to 3.6, figure out whether or not it's a duplicate of Is
Changes by Larry Hastings :
--
pull_requests: +2781
___
Python tracker
<http://bugs.python.org/issue30939>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
New changeset 34fae03cd6c9e304e02c571b3bf9e8df0cfe76be by larryhastings (Serhiy
Storchaka) in branch '3.4':
[3.4] bpo-26617: Ensure gc tracking is off when invoking weakref callbacks.
(#2695)
https://github.com/python/cpyt
Larry Hastings added the comment:
Sorry for the delay in merging your PR. I believe Ned is planning to tag the
next 3.3 rc1 tomorrow (Sunday). If you see this, and you have time, it'd be
great if you could make a PR for the 3.3 backport.
Note that 3.3 is probably *not* getting convert
Larry Hastings added the comment:
New changeset 3b3a5a5b70dc468dcfacb17a3d6b342820b480ff by larryhastings (Ned
Deily) in branch '3.4':
bpo-30939: Avoid Sphinx deprecation warning in docs build. (#2721) (#2724)
https://github.com/python/cpython/commit/3b3a5a5b70dc468dcfacb17a3d6b34
Larry Hastings added the comment:
New changeset b1549175ed30f2931e2bb980a7e3c360ed19e1c9 by larryhastings (Victor
Stinner) in branch '3.4':
[3.4] Backport CI config from master (#2475)
https://github.com/python/cpython/commit/b1549175ed30f2931e2bb980a7e3c3
Larry Hastings added the comment:
New changeset b1549175ed30f2931e2bb980a7e3c360ed19e1c9 by larryhastings (Victor
Stinner) in branch '3.4':
[3.4] Backport CI config from master (#2475)
https://github.com/python/cpython/commit/b1549175ed30f2931e2bb980a7e3c360ed19e1c9
--
no
Larry Hastings added the comment:
I don't see how a fix for a *test* can be considered a *release blocker*. The
PR literally doesn't change Python's behavior; it only modifies two text files
and a test. There is no crash or exploitable security hole being
Larry Hastings added the comment:
Quoting from the Python Dev Guide:
"As a guideline, critical and above are usually reserved for crashes, serious
regressions or breakage of very important APIs. Whether a bug is a release
blocker is a decision better left to the release manager so, i
New submission from Larry Hastings:
I use Linux (Ubuntu GNOME, 17.04, 64-bit) on all my computers, and I use ZFS
for the /home partition. While releasing 3.4.7rc1 and 3.5.4rc1, I encountered
this test failure:
% ./python -m test test_resource
0:00:00 load avg: 0.40 [1/1] test_resource
test
Larry Hastings added the comment:
* I was told that blurb needed to be in the core-workflow repo, that this was
better than checking it in to CPython itself. Okay. If you want to debate the
point, loop in Brett Cannon, he's the one with the strong opinions.
* Ned has taken over th
Larry Hastings added the comment:
> Sorry to say, but the assumption that pip should be used to be able to build
> core python seems to be the wrong direction.
I'm not sure I understand your position. External tools are only permissible
if Debian packages exist for them?
An
Larry Hastings added the comment:
I guess it depends on what the upstream patches look like. If they're always
coded against release tarballs and not against git repos, then they'll assume
(correctly) that Misc/NEWS exists. In that case you shouldn't have to do
anything.
Larry Hastings added the comment:
What you're missing is that Misc/NEWS.d is removed from tarballs. We ship
Misc/NEWS in tarballs but *not* Misc/NEWS.d.
If you start with a CPython tarball (e.g. 3.5.4rc1), and then apply
vendor-specific patches on top of that, and those patches include
301 - 400 of 2415 matches
Mail list logo
