Larry Hastings added the comment:
This bug is marked only for 3.4, and 3.4 is now EOL. Either it should be
relocated to an active version, or it should be marked wontfix.
--
nosy: +larry
___
Python tracker
<https://bugs.python.org/issue21
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue36863>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
As a reminder: I'm currently scheduled to tag Python 3.5.5rc1 on January 21st,
2018, aka about six days from now.
--
___
Python tracker
<https://bugs.python.org/is
Larry Hastings added the comment:
If you're certain it isn't a security bug, then please downgrade it from
release blocker.
I might permit a fix for it in 3.5.5 anyway, depending on how small it is,
because nobody likes regressions.
--
Larry Hastings added the comment:
Do all the parameters to the decorator take a default value of "None", so that
you can differentiate between explicit True, explicit False, and
did-not-specify?
Is this the complete list of these dunder-method-generation-control parameters?
in
Larry Hastings added the comment:
So if I understand correctly: the default value of the "repr" parameter is True.
Decision matrix: does dataclass insert a __repr__ into the class?
+-- row: argument passed in to decorator's repr parameter
|
|
v| yes | no
Larry Hastings added the comment:
New changeset c59731d92dc73111d224876f1caa064097aad786 by larryhastings (Serhiy
Storchaka) in branch '3.4':
[3.4] bpo-32072: Fix issues with binary plists. (GH-4455) (#4658)
https://github.com/python/cpython/commit/c59731d92dc73111d224876f1caa06
Larry Hastings added the comment:
Python 3.4 and 3.5 are in "security fixes only" mode. This is a minor bugfix,
so it's too late to accept it into 3.4 and 3.5.
--
nosy: +larry
versions: -Python 3.4, Python 3.5
___
Python
Larry Hastings added the comment:
New changeset 4a4c2743133e195cc3725b78a895d85d69e50089 by larryhastings (Nick
Coghlan) in branch '3.5':
[3.5] bpo-32620: Remove failing pyenv call from CI config (#5274)
https://github.com/python/cpython/commit/4a4c2743133e195cc3725b78a895d8
Larry Hastings added the comment:
New changeset 57fa0ab8911a70d91e5b60b8dc91f1085442a9e7 by larryhastings (Nick
Coghlan) in branch '3.5':
[3.5] bpo-32563: Get expat to compile under C89 (#5201)
https://github.com/python/cpython/commit/57fa0ab8911a70d91e5b60b8dc91f1
Larry Hastings added the comment:
New changeset 891c91d8d38848377a9f475242507510873eb9c3 by larryhastings (Nick
Coghlan) in branch '3.5':
[3.5] bpo-32551: Consistently configure sys.path[0] (#5197)
https://github.com/python/cpython/commit/891c91d8d38848377a9f4752425075
Larry Hastings added the comment:
New changeset 891c91d8d38848377a9f475242507510873eb9c3 by larryhastings (Nick
Coghlan) in branch '3.5':
[3.5] bpo-32551: Consistently configure sys.path[0] (#5197)
https://github.com/python/cpython/commit/891c91d8d38848377a9f4752425075
Larry Hastings added the comment:
New changeset 43f014d3f12468edf61046f0612edc7660042fd5 by larryhastings (Serhiy
Storchaka) in branch '3.5':
[3.5] bpo-32072: Fix issues with binary plists. (GH-4455) (#4656)
https://github.com/python/cpython/commit/43f014d3f12468edf61046f0612edc
Larry Hastings added the comment:
I'm using ZFS on 64-bit Linux.
I did see a Github issue / commit that claims to address this. I'm using a
reasonably recent ZoL build, that should have that commit, and I still see the
behavior.
I actually experimented with it a little, and, hmm.
New submission from Larry Hastings :
Following on from the "Can Python guarantee the order of keyword-only
parameters?", here's a patch to enforce that guarantee. It adds documentation
that makes the guarantee, and adds tests that make at least a passable attempt
at testing
Change by Larry Hastings :
--
keywords: +patch
pull_requests: +5226
___
Python tracker
<https://bugs.python.org/issue32697>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
New changeset f36ba12809d5db1b76464d8f1f04dad8d685ec78 by larryhastings in
branch 'master':
bpo-32697: Definition order of kwonly params is now guaranteed preserved.
(#5391)
https://github.com/python/cpython/commit/f36ba12809d5db1b76464d8f1f04da
Larry Hastings added the comment:
Thanks for the quick turnaround reviews! Today we've all collectively made
Python a better programming language.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Larry Hastings added the comment:
Thank you for the fix! I just wish I knew what plists were ;-)
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Larry Hastings :
--
pull_requests: +5360
___
Python tracker
<https://bugs.python.org/issue32620>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
New changeset 71b94e30b1d63c789908482b3b808cc613e57267 by larryhastings in
branch '3.4':
[3.4] [3.5] bpo-32620: Remove failing pyenv call from CI config (GH-5274)
(#5533)
https://github.com/python/cpython/commit/71b94e30b1d63c789908482b3b808c
Larry Hastings added the comment:
I wanted it in 3.4 too, it was breaking CI.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
versions: +Python 3.4
___
Python tracker
<https://
Larry Hastings added the comment:
This is not an Argument Clinic problem.
--
components: +Library (Lib) -Argument Clinic
___
Python tracker
<https://bugs.python.org/issue32
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue32786>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Larry Hastings :
--
keywords: +patch
pull_requests: +5425
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32397>
___
___
Py
Larry Hastings added the comment:
New changeset 942cc04ae44825ea120e3a19a80c9b348b8194d0 by larryhastings (Ned
Deily) in branch '3.4':
[3.4] bpo-32981: Fix catastrophic backtracking vulns (GH-5955) (#6035)
https://github.com/python/cpython/commit/942cc04ae44825ea120e3a19a80c9b
Larry Hastings added the comment:
New changeset 937ac1fe069a4dc8471dff205f553d82e724015b by larryhastings (Ned
Deily) in branch '3.5':
[3.5] bpo-32981: Fix catastrophic backtracking vulns (GH-5955) (#6034)
https://github.com/python/cpython/commit/937ac1fe069a4dc8471dff205f553d
Larry Hastings added the comment:
Is this ready to close?
--
___
Python tracker
<https://bugs.python.org/issue32981>
___
___
Python-bugs-list mailing list
Unsub
Larry Hastings added the comment:
New changeset 77c02cdce2d7b8360771be35b7676a4977e070c1 by larryhastings (Steve
Dower) in branch '3.4':
[3.4] bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) (#5992)
https://github.com/python/cpython/commit/77c02cdce2d7b8360771be35b7676a
Larry Hastings added the comment:
New changeset f381cfe07d15d52f27de771a62a8167668f0dd51 by larryhastings (Steve
Dower) in branch '3.5':
[3.5] bpo-33001: Prevent buffer overrun in os.symlink (GH-5989) (#5991)
https://github.com/python/cpython/commit/f381cfe07d15d52f27de771a62a816
Larry Hastings added the comment:
New changeset 86a713cb0c110b6798ca7f9e630fc511ee0a4028 by larryhastings (Victor
Stinner) in branch '3.4':
[3.4][Security] bpo-30947, bpo-31170: Update expat from 2.2.1 to 2.2.4 (#3353)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset 86a713cb0c110b6798ca7f9e630fc511ee0a4028 by larryhastings (Victor
Stinner) in branch '3.4':
[3.4][Security] bpo-30947, bpo-31170: Update expat from 2.2.1 to 2.2.4 (#3353)
https://github.com/python/cpyt
Larry Hastings added the comment:
Oh, and, Victor, I tagged you with this because git blame says you're the most
person to touch PYTHON_FOR_REGEN in the makefile, checkin ab6b962ef24 .
--
___
Python tracker
<https://bugs.python.org/is
New submission from Larry Hastings:
On Python 3.5, the makefile pseudotarget "regen-opcode" now fails if
"python3.5" can't be found on the path. What's strange is that the configure
script scans to see if it can find "python3.5", and it thinks it can,
Larry Hastings added the comment:
New changeset 70c630a7316f9f6063557786442e3c56502fe8ea by larryhastings (Victor
Stinner) in branch '3.5':
bpo-31568, Travis CI: Fix python3.5 (#3737)
https://github.com/python/cpython/commit/70c630a7316f9f6063557786442e3c
Larry Hastings added the comment:
New changeset f2492bb6aae061aea47e21fc7e56b7ab9bfdf543 by larryhastings (Victor
Stinner) in branch '3.5':
[3.5][Security] bpo-30947, bpo-31170: Update expat from 2.2.1 to 2.2.4 (#3354)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset f2492bb6aae061aea47e21fc7e56b7ab9bfdf543 by larryhastings (Victor
Stinner) in branch '3.5':
[3.5][Security] bpo-30947, bpo-31170: Update expat from 2.2.1 to 2.2.4 (#3354)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset 44c1b62939a6192776dc9d093546154044cb2ecb by larryhastings (Steve
Dower) in branch '3.5':
[3.5] bpo-31170: Fix inclusion of expat in Windows build projects. (#3751)
https://github.com/python/cpython/commit/44c1b62939a6192776dc9d09354615
Larry Hastings added the comment:
New changeset 0fcc03367b31f44c1e1b8d3d2dd940ef1e744326 by larryhastings (INADA
Naoki) in branch '3.5':
bpo-31095: fix potential crash during GC (GH-2974) (#3196)
https://github.com/python/cpython/commit/0fcc03367b31f44c1e1b8d3d2dd940
Larry Hastings added the comment:
Wait, what is all this nonsense?
inspect.getfullargspec is Python 3 only. It was added to support keyword-only
parameters. Python 2 doesn't *have* keyword-only parameters, so it isn't
needed there.
Check for yourself: Python 2 do
Larry Hastings added the comment:
> Most, if not all, calls to _PyMem_DebugRawRealloc() are protected by
> the GIL. If there is a single thread using the memory block,
> I think that it's perfectly fine to write after it's deallocated.
I don't quite follow where
Larry Hastings added the comment:
I would welcome a backport of this for 3.5 and even 3.4 (if it's vulnerable,
which it probably is).
--
___
Python tracker
<https://bugs.python.org/is
Larry Hastings added the comment:
Resetting to "needs patch", because we still need PRs for 3.4 and 3.5 (please!).
--
stage: resolved -> needs patch
___
Python tracker
<https://bugs.pytho
Larry Hastings added the comment:
New changeset 8b11e8de7aedacfbbcc8c780f3c4097396f1d1a3 by larryhastings (Victor
Stinner) in branch '3.4':
[3.4] bpo-31170: Fix inclusion of expat in Windows build projects (#3785)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset fd8614c5c5466a14a945db5b059c10c0fb8f76d9 by larryhastings (Miro
Hrončok) in branch '3.5':
bpo-30657: Fix CVE-2017-1000158 (#4664)
https://github.com/python/cpython/commit/fd8614c5c5466a14a945db5b059c10
Larry Hastings added the comment:
New changeset 6c004b40f9d51872d848981ef1a18bb08c2dfc42 by larryhastings (Miro
Hrončok) in branch '3.4':
bpo-30657: Fix CVE-2017-1000158 (#4758)
https://github.com/python/cpython/commit/6c004b40f9d51872d848981ef1a18b
Larry Hastings added the comment:
Merged into 3.4 and 3.5. Thanks for the patches!
Since I see 2.7 has already had the fix committed, and these are the only three
versions affected, I'm marking as closed / resolved / fixed.
--
resolution: -> fixed
stage: patch review -&g
Larry Hastings added the comment:
New changeset 092db6c3cb049052fbfca15efc85ad68093676e7 by larryhastings (Victor
Stinner) in branch '3.4':
bpo-29572: Update Windows build to OpenSSL 1.0.2k (GH-443) (#3445)
https://github.com/python/cpython/commit/092db6c3cb049052fbfca15efc85ad
Larry Hastings added the comment:
To confirm what Steve said: we no longer accept bug fixes for Python 3.5 (or
3.4). We only accept security fixes for 3.5 (and 3.4).
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue32245>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Larry Hastings :
If you word-wrap a paragraph twice with textwrap, you may get different
results. Specifically, you *will* get different results when:
* the original text has a line that is too long by one character,
* the last word on the line is the first word in a new
Larry Hastings added the comment:
FWIW, the test program produces this output:
--
original: ' . '
wrapped: ' .\n'
wrapped twice: ' . '
Tr
Larry Hastings added the comment:
The rationale: without this information, it is impossible for anybody else to
write a bytecode compiler / assembler, because when you create a code object
you have to specify its stack depth. I used this information for my "maynard"
bytecode
Change by Larry Hastings :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue32455>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
> 1. This will actually simplify the code for calculating the stack size.
Simplify whose code, the caller or the callee? It seems like it's simplifying
the life of the callee (PyCompile_OpcodeStackEffectEx) at the expense of
pushing complexity
Larry Hastings added the comment:
Serhiy, why did you mark this as a release blocker? This is a proposed
documentation fix.
--
priority: release blocker -> low
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
Documentation changes are okay.
--
___
Python tracker
<https://bugs.python.org/issue33216>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
Marking an issue as "Release Blocker" is completely inappropriate for "I'd like
to see this documentation change get into the next bugfix release."
Our Python Dev Guide discusses priority, here:
https://devguide.python.org/triaging/#
Larry Hastings added the comment:
Doc fixes are generally okay in security-fixes-only branches. Obviously I'd
want to review it before it went in; it sounds like a simple change (one line
change to an RE?), so you can send me a PR or just post it here if you want a
pre-r
Larry Hastings added the comment:
New changeset 1b141b9553424971639bde281feb1d4e4e586dbe by larryhastings (Julien
Palard) in branch '3.5':
Doc: Backport language switcher (bpo-33700, bpo-31045) (#8048)
https://github.com/python/cpython/commit/1b141b9553424971639bde281feb1d
Larry Hastings added the comment:
New changeset 1b141b9553424971639bde281feb1d4e4e586dbe by larryhastings (Julien
Palard) in branch '3.5':
Doc: Backport language switcher (bpo-33700, bpo-31045) (#8048)
https://github.com/python/cpython/commit/1b141b9553424971639bde281feb1d
Change by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Larry Hastings added the comment:
I'll accept this into 3.4 and 3.5, if someone produces a PR and someone else
reviews it. Given that the issue has already celebrated its fifth birthday I
can't say I feel a lot of urgency about it.
--
Change by Larry Hastings :
--
pull_requests: +7872
___
Python tracker
<https://bugs.python.org/issue33216>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
New changeset 76aa2c0a9a8dd3ac90b91e7342c8ce8125bf21f9 by larryhastings in
branch '3.5':
bpo-33216: Clarify the documentation for CALL_FUNCTION_* (#8338)
https://github.com/python/cpython/commit/76aa2c0a9a8dd3ac90b91e7342c8ce
Larry Hastings added the comment:
I'm a little surprised by this. It's not like slavery was acceptable when
these computer science terms were coined and it's only comparatively recently
that they've gone out of fashion. On the other hand, there are some areas in
com
Larry Hastings added the comment:
As a counter-example: A quick grep finds 555 occurrences of the word "kill" in
CPython master. Everybody knows killing is bad and using the term might upset
certain people. Yet I would not support expunging the word "ki
Larry Hastings added the comment:
> > Have there been any actual complaints?
> Yes, but sadly they are private.
I'm not super-excited by the idea that Python has to change its behavior based
on secret comments. Python has traditionally had a very open governance model
where a
New submission from Larry Hastings :
This patch was sent to me privately by Jeethu Rao at Facebook. It's a change
they're working with internally to improve startup time. What I've been told
by Carl Shapiro at Facebook is that we have their blessing to post it publicly
/ m
Change by Larry Hastings :
--
keywords: +patch
pull_requests: +8745
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
I should add that there were two novel test failures in the regression test
suite: test_module and test_site.
--
___
Python tracker
<https://bugs.python.org/issue34
Larry Hastings added the comment:
As Neil points out on python-dev, my "improvement" should have been multiplied
by 100, like 20.924239043734505 % instead of 0.20924239043734505 %, etc.
--
___
Python tracker
<https://bugs.python.o
Larry Hastings added the comment:
@Mariatta:
> There will be no further discussion about this.
Mariatta, why do you say that? As long as the participants in the discussion
are respectful I'm not aware of any mechanism in the CPython developer
guidelines that would require shutting
Larry Hastings added the comment:
@eric.araujo:
> I think the idea here is: don’t feed the trolls.
I understand this as a general-purpose metaphor. But I don't understand how
that translates into CPython issue tracker policy. And so far I wouldn't
describe anybody correspo
New submission from Larry Hastings:
I'm monkeying around with CPython trunk, and just noticed the following
declaration in Objects/dictobject.c:
static PyObject *
dict_contains(register PyDictObject *mp, PyObject *key)
Although dict_contains is a static method, it'
New submission from Larry Hastings:
There's a typedef in methodobject.h called PyNoArgsFunction. You might think
it's used for METH_NOARGS functions--you'd be wrong, those use PyCFunction and
pass in NULL for args.
No, PyNoArgsFunction is never used. Nor is it documented.
Changes by Larry Hastings :
--
nosy: +Mark.Shannon, rhettinger
___
Python tracker
<http://bugs.python.org/issue18090>
___
___
Python-bugs-list mailing list
Unsub
Larry Hastings added the comment:
Either of you gentlemen care to offer an opinion?
--
nosy: +benjamin.peterson, pitrou
___
Python tracker
<http://bugs.python.org/issue18
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 identifier 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
501 - 600 of 2389 matches
Mail list logo
