[issue29057] Compiler failure on Mac OS X - sys/random.h

Larry Hastings added the comment: I'm making an executive decision to not hold up the 3.5.3rc1 release for OpenBSD. Hopefully the OpenBSD folks can make sure it works for them before 3.5.3 final ships in two weeks. -- ___ Python tracker

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

Larry Hastings added the comment: This code hasn't changed in years. So while I believe it's a security bug and should be fixed, I don't know if I agree it's a bad enough security bug to stop Python 3.5.3rc1, which is literally in the middle of the release process.

[issue29057] Compiler failure on Mac OS X - sys/random.h

Larry Hastings added the comment: Mr. Nasby, as long as you're in a test-reproducing mood, would you mind downloading the source to 3.5.3rc1 and confirming that it builds correctly for you? I'd appreciate it! (Not that I don't trust Ned et al, but independent confirmati

[issue29169] update zlib to 1.2.10

Larry Hastings added the comment: I cut 3.4.6rc1 and 3.5.3rc1 a couple of days ago. Do you think the CVEs are bad enough to warrant cherry-picking this? A quick google suggests they were all low severity: http://www.openwall.com/lists/oss-security/2016/12/05/21 I'm inclined to not c

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

Larry Hastings added the comment: I don't understand the fix. Does this really prevent the injection? I would fix it this way: if tixlib is not None and os.path.exists(tixlib): -- ___ Python tracker <http://bugs.python.org/is

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Larry Hastings added the comment: FYI I'm keeping an eye on this for possible cherry-picking into 3.5.3 final, depending on the resolution. Reverting 030e100f048a work for me, assuming that's a reasonable solution. -- ___ Python trac

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

Larry Hastings added the comment: Well, clearly I'm not qualified to review the patch. Could someone please review it? I want to cherry-pick the fix for this issue for 3.5.3 final, which I tag in about four days. -- ___ Python tracker

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Larry Hastings added the comment: Ping. Hoping to resolve this in time for 3.5.3, which I tag in about four days. -- ___ Python tracker <http://bugs.python.org/issue29

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

Larry Hastings added the comment: Hoping to tag in less than 48 hours...! -- ___ Python tracker <http://bugs.python.org/issue29006> ___ ___ Python-bugs-list mailin

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

Larry Hastings added the comment: Could one of you recent tagees (Terry, Zach) review the patch? Hoping to tag 3.5.3 final in less than 48 hours, and I want to cherry-pick the fix for this...! -- ___ Python tracker <http://bugs.python.

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

Larry Hastings added the comment: I'll make you a deal. If you check this in in the next 3 hours, I'll cherry-pick it for 3.5.3. Otherwise I don't want to hold up the release. To be honest I'm not sure why it's marked as "release b

[issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix

Larry Hastings added the comment: If it "has a small attack surface" and affects "a very small number of applications", I don't think it's a release blocker. Demoting to "high" priority, which will permit me to release 3.5.3.

[issue29057] Compiler failure on Mac OS X - sys/random.h

Larry Hastings added the comment: Releasing 3.5.3 even though technically this is an open release blocker. IIUC the fix is checked in, and fixed the issue for OS X. We don't know whether or not it is also fixed on OpenBSD, because we don't know anybody running OpenBSD, and nobody

[issue28339] "TypeError: Parameterized generics cannot be used with class or instance checks" in test_functools after importing typing module

Changes by Larry Hastings : -- nosy: -larry ___ Python tracker <http://bugs.python.org/issue28339> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27647] Update Windows build to Tcl/Tk 8.6.6

Larry Hastings added the comment: I don't think we should update it in 3.5. That sounds destabilizing. -- ___ Python tracker <http://bugs.python.org/is

[issue27286] str object got multiple values for keyword argument

Larry Hastings added the comment: Sorry about that! It's almost like manually updating Misc/NEWS is a bad design :( -- ___ Python tracker <http://bugs.python.org/is

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: Speaking as the 3.5 RM, I suppose I have to have an opinion. I don't think "Python now uses a better source of randomness to seed the random module at startup" is a major feature. It's a nice-to-have, not a must-have. And people

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: > I'm uploading a third version of the patch (against clean 3.5.1 source Not against the 3.5 branch from hg.python.org/cpython ? If not, why not? -- ___ Python tracker <http://bugs.python.org

[issue27243] __aiter__ should return async iterator instead of awaitable

Larry Hastings added the comment: As RM my default position is naturally "don't change behavior in point releases". I'm willing to be overruled by the BDFL, less so by anybody else. -- ___ Python tracker <http://bug

[issue27243] __aiter__ should return async iterator instead of awaitable

Larry Hastings added the comment: Okay. I'm hoping to not delay 3.5.2 RC1, and the schedule calls for me to tag the release Saturday afternoon. Can you guys get this solid and checked in before then? -- ___ Python tracker <http://bugs.py

[issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c)

Larry Hastings added the comment: I agree with the previous comment author. Can you post a sample program that crashes Python? Please specify what platform you're running on. On 32-bit platforms, you'd be unable to construct even the first "r" * ((2**32)-1) string. T

[issue26556] Update expat to 2.2.1

Larry Hastings added the comment: Was this critical bug fix released on May 17th as promised? I will not hold up 3.5.2 for this. 3.5.2 has waited long enough. -- ___ Python tracker <http://bugs.python.org/issue26

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: > PSRT VETO! This is an amusing concept, but membership in the PSRT does not empower you with a "veto". On the other hand, being Release Manager does give me some say here. > You wouldn't add a workaround for broken CPU instructions

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: Thank you for summarizing the debate. It made it a lot easier to > * blocking initialization of the hash secret. This occurs regardless of > script contents; at present Python simply can't be used at all in low-entropy > situations. I feel that

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: Everybody: let's drop discussing "hashlib" unless someone says it actually is a problem. I think it was always, as we say in English, a "red herring". > The secret for SipHash is composed of two 64bit integers. The entire >

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: That reminds me. I want to be clear: I think it's preferable that os.urandom() blocks when insufficient entropy is available. If Victor's patch changed that, it should be backed out. (Since non-blocking urandom is useful, perhaps in 3.6 os.urando

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: > This is only a DoS vector if you can hit the server so early in the boot > process that it doesn't have enough entropy. Python hash randomization only happens once. So it's not a matter of how early we try the attack, it's a matter

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: I fear I may be changing my mind a little bit. However, I skipped breakfast--and now it's looking like a late lunch--so I simply have to step away for a while. Expect me to post in about two hours when I get some calories down and finally make up my

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: I've revised my thinking on the subject. First, my previous statements stand: Python startup must not block. "import random" must not block. Now I'm thinking that "os.urandom()" must not block, too. Here's my reasoning.

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: Are you certain that /dev/urandom will block on Mac OS X if sufficient entropy is not available? The dismissive tone ("this choice and distinction is not necessary") suggests that *their* implementation is superior, and it could hardly be seen as s

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: So, in short, you don't know. #25003 is about Solaris, and the reporter clearly had the expectation that /dev/urandom would never block. The documentation on Linux is clear: /dev/urandom will never block. That's two. This "StackExcha

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: I don't know if anyone literally still uses BSD. But on FreeBSD, /dev/urandom can block. So let me revise my statement slightly. Developers on platform X know how *their* /dev/urandom behaves. They should rightly expect that os.urandom() is a thin wr

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: You're right, it's remotely possible that on platforms where /dev/urandom could block, Python startup could therefore also block. And I'm not proposing we fix that, as so far nobody has reported it as a problem. This suggests to me that

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: > Hi. I created the issue #27266 "Add block keyword-only optional parameter > to os.urandom()" which is compromise between all proposed solutions and > should fix *all* urandom issues ;-) > > * os.urandom() remains secure by default,

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: First, DO NOT merge this change into 3.5.2 without my explicit permission. Second, unless you can guarantee you support blocking / non-blocking behavior on all platforms, this is a bad move. -- ___ Python tracker

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > getentropy() is non-blocking. By the way, os.urandom() is now implemented > with getentropy() on OpenBSD. I quote issue #25003: > You can not substitute getentropy() for getrandom(), if you need randomness > then entropy does

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing /arguinthe random module on getrandom()

Larry Hastings added the comment: I am increasingly convinced that I'm right. -- First, consider that the functions in the os module, as a rule, are a thin shell over the equivalent function provided by the operating system. If Python exposes a function called os.XYZ(), and it calls t

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: This is why I'm unwilling to accept this change in 3.5.2. This sort of "we think it's right" behavior is only appropriate in a point release like 3.6. I think odds are better than even that I'm going to get an os.getrandom(n, block

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: os.getrandom() would be a thin shell around what the local OS provides, and has the advantage of behaving in a predictable manner. If you provide block=, its implementation and semantics will vary wildly between platforms. * On Linux, block=False should be

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > There are a number of functions in os.py that add additional logic ontop of > the system calls, like: All the functions you name don't have POSIX equivalents, except popen and scandir. popen provides a lot of functionality around popen (which

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: Let me make one more thing clear. I'm willing for os.urandom() to try to use getrandom(GRND_NOBLOCK) (or whatever the flag is called). This will not block unless the entropy pool is low--which almost never happens. So 99.% of the time, os.ur

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: Wait a minute. If I read the code correctly, currently os.urandom() is implemented strictly using getrandom() *on all platforms*. And if block=false, it... returns an empty buffer? Am I reading that right? And what does it do on platforms that don't h

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > I don't think most people calling os.urandom have any idea how /dev/urandom > behaves on their machine nor do I think most people have any idea how > /dev/urandom behaves on other people's machines. Here I invoke the "consenting

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: > Regardless of the behavior of os.urandom (and 'import random'), is it agreed > that the current state of _PyRandom_Init is acceptable for 3.5.2? I'll get back to you with a specific yes or no. What I want is that it the behavior

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > I'd also *STRONGLY* request that we avoid adding any new APIs in relation to > this that mean "Use os.urandom" is no longer the preferred option to obtain > cryptographically strong random numbers in Python. According to the document

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > As a process comment: I agree with what Victor wrote in > http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2, > when he suggests that we leave 3.5.2 as is for now [...] I agree in principle. Certainly we all agre

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > Larry, I'm sorry but I think you're just flat wrong here and I don't know > what else to say about it. Yeah, I think maybe asking Guido to make a ruling would be the right thing here. Again, I cite #25003: he implicitly rule

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: Victor: just to confirm, would "os.getrandom(n, block=True)" be okay with you? Do you strongly prefer adding the "block" parameter to os.urandom(), or do you not care much? -- ___ P

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: AFAICT, the history is, Linux added /dev/urandom, then all the other UNIXes followed suit. I've read a lot of man pages for /dev/urandom (or equivalent) on a lot of different platforms and most of them say "this was added to Linux, so we add

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > I wonder what we should do on Linux if /dev/urandom is unavailable and > getrandom() would block. I don't think that happens. getrandom() actually supports two flags. The flag GRND_RANDOM tells it "behave like /dev/random".

[issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom()

Larry Hastings added the comment: I +1 on new functions that are designated the best-practice places to get your pseudo-random numbers. (IDK if the best place for both is in random; maybe the crypto one should be in secrets?) To be precise: on most OSes what you're calling "cry

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: Fair enough. But Theodore Ts'o said on the tracker: if you call getrandom() and don't pass in GRND_RANDOM, it's equivalent to /dev/urandom. So, if getrandom is available, getrandom(flags=0) will always work

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > Can we please try to be clear about what kind of blocking we mean? > getrandom(flags=0) absolutely *can* block: that's what the original issue was > all about. To ensure it *never* blocks you need to call > getrandom(GRND_NONBLOCK): th

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > Oh, I found how to start a task before the user login, and os.urandom() still > works: it produces 16 bytes immediatly (in 0.0 second). Just to confirm: that's a fresh Windows VM, never been booted before ever? If it had ever been booted befor

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

Larry Hastings added the comment: > In my tests, reading from /dev/urandom never blocks even before urandom is > initialized. That's correct, and is the big difference between getrandom(0) and reading from /dev/urandom. If "the entropy pool has not been initialized" (

[issue27279] Add random.cryptorandom() and random.pseudorandom, deprecate os.urandom()

Larry Hastings added the comment: > * FreeBSD will likely switch to the new Fortuna successor of Yarrow in an > upcoming release: A little more information about that. FreeBSD did a major refactoring of their /dev/urandom (etc) support, which landed in October 2014:

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: I just posted to python-dev and asked Guido to make a BDFL ruling. I only represented my side, both because I worried I'd do a bad job of representing *cough* literally everybody else *cough*, and because it already took me so long to write the email.

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

Larry Hastings added the comment: Colm Buckley: I've read the code, *and* stepped through it, and AFAICT it is no longer even possible for Python on Linux to call getrandom() in a blocking way. Thanks for doing this! I'm marking the issue as closed. -- stage: pa

[issue26556] Update expat to 2.2.1

Larry Hastings added the comment: Christian: I don't see any checkins on this issue, and I tag 3.4.4 rc1 and 3.5.2 rc1 in about twelve hours. As I mentioned to you in person at the PyCon 2016 sprints, I'm not holding up either of these releases for the expat update. If this is

[issue27292] Warn users that os.urandom() can return insecure values

Larry Hastings added the comment: I don't think this is necessary, as the documentation for os.urandom() is already pretty good. Here's the relevant bit: This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable

[issue27292] Warn users that os.urandom() can return insecure values

Larry Hastings added the comment: Oh, and, for 3.6 I would definitely support adding a mention of "Instead of using this function directly, we recommend you use the token_bytes() function in the secrets module", blah blah best practices etc. That goes for os.getrandom() too, if we

[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

Larry Hastings added the comment: As with #27292, I'm going to nosy Georg Brandl about this so he can guide us in how to approach it. My hunch is, it'd be best if we avoided specifics, and talked instead in generalities. Perhaps all that's really necessary is to consistently

[issue27293] Summarize issues related to urandom, getrandom etc in secrets documentation

Larry Hastings added the comment: Oops, sorry, forgot to actually nosy Georg. D'oh! -- nosy: +georg.brandl ___ Python tracker <http://bugs.python.org/is

[issue27297] Add support for /dev/random to "secrets"

New submission from Larry Hastings: Linux contains two separate sources for random numbers: /dev/urandom and /dev/random. On a reasonably-current Linux box, the urandom(4) man page states: As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys

[issue27292] Warn users that os.urandom() can return insecure values

Larry Hastings added the comment: I would suggest weakening the one-line summary. Currently the first line reads: Return a string of n random bytes suitable for cryptographic use. I'd support adding some "weasel words" to this, e.g.: Return a string of n random bytes

[issue27297] Add support for /dev/random to "secrets"

Larry Hastings added the comment: So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of identically high quality? I'm curious about this political pressure you cite. It seems bizarre to me that the Linux developers would bow to such a thing, given how they behav

[issue27297] Add support for /dev/random to "secrets"

Larry Hastings added the comment: I understand. It's just that the manpage for urandom (and in fact the comments in the source code for /dev/random and /dev/urandom) both recommend using /dev/random for these long-lived cryptographic keys. Under normal circumstances I'd simply a

[issue25782] CPython hangs on error __context__ set to the error itself

Larry Hastings added the comment: I'm not the right person to decide this. As RM, all I can do is decide whether or not to hold up a release based on the bug. The answer: no. Since this isn't fixed yet in the 3.5 branch, 3.5.2 will go out without it being fixed. S

[issue27292] Warn users that os.urandom() can return insecure values

Larry Hastings added the comment: This is not a release blocker. -- priority: release blocker -> normal ___ Python tracker <http://bugs.python.org/issu

[issue26867] test_ssl test_options fails on ubuntu 16.04

Larry Hastings added the comment: I got this when testing 3.5.2rc1 on my Ubuntu 16.04 machine. CAs Xiang Zhang showed, this is Ubuntu doing something crazy. I ignored the failure and shipped 3.5.2rc1, however I would be interested in suppressing the test for 3.5.2 final. That way it has a

[issue26867] test_ssl test_options fails on ubuntu 16.04

Larry Hastings added the comment: This still affects 3.4 and 3.5. It'd be lovely if it could be fixed in all the still-alive versions. (Yes, this is technically a "bug fix", but I'd still like it fixed in 3.4.) -- versions: +Py

[issue26867] test_ssl test_options fails on ubuntu 16.04

Larry Hastings added the comment: That does seem like it'd make the test failure go away. But the fix seems a little Ubuntu-specific. Is it reasonable to do that when testing on every platform? -- ___ Python tracker <http://bugs.py

[issue27314] Cannot install 3.5.2 with 3.6.0a1 installed

Changes by Larry Hastings : -- nosy: -larry ___ Python tracker <http://bugs.python.org/issue27314> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25843] code_richcompare() don't use constant type when comparing code constants

Larry Hastings added the comment: Someone asked on reddit. The Misc/NEWS entry for this reads: Issue #25843: When compiling code, don’t merge constants if they are equal but have a different types. For example, f1, f2 = lambda: 1, lambda: 1.0 is now correctly compiled to two different

[issue25843] code_richcompare() don't use constant type when comparing code constants

Larry Hastings added the comment: Yes, which doesn't help 3.5.2 final as I don't pull revisions by default after rc1. :p -- ___ Python tracker <http://bugs.python.o

[issue26930] Upgrade installers to OpenSSL 1.0.2h

Larry Hastings added the comment: Yes, I'll accept this for 3.5.2 final. Steve: do I need to do anything besides cherry-pick these revisions? -- ___ Python tracker <http://bugs.python.org/is

[issue27355] Strip out the last lingering vestiges of Windows CE support

New submission from Larry Hastings: I can't tell if CPython ever really officially supported Windows CE or not. There are some checkins around 2.5 that suggest there was at least partial support. However posixmodule was supposed to be renamed "ce" on Windows CE, and that wa

[issue27355] Strip out the last lingering vestiges of Windows CE support

Larry Hastings added the comment: Nosying two people who I know worked on the port originally, just in case they have an opinion about removing WinCE. (Remind me. Why is our private copy of libffi a divergent unmaintained fork? libffi still gets updates; last update was two years ago. Why

[issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names)

Larry Hastings added the comment: If the diff is literally changing two lines, I'll accept it. Guido relaxed the rules for IDLE changes. If it breaks something it's on *your* head ;-) Please just check it in normally. Either I'm going to use hg to cherry-pick the changes

[issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names)

Larry Hastings added the comment: You speak confidently, for a guy who hasn't seen any sort of schedule from the 3.5 RM. :-O After 3.6 comes out, I expect 3.5 to get one more "bug fix" release. And *then* it will transition to "security fixes only" mode. Six months

[issue26867] test_ssl test_options fails on ubuntu 16.04

Larry Hastings added the comment: Well, I want this fixed in 3.5.2 final. If nobody can propose a better patch in the next 24 hours then I'm going with Matthias's patch. -- ___ Python tracker <http://bugs.python.o

[issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor names)

Larry Hastings added the comment: If this is fixed, and resolved, why is it still open? Closing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issu

[issue26867] test_ssl test_options fails on ubuntu 16.04

Larry Hastings added the comment: Well, as Donald Rumsfeld said in 2008: "As you know, you go to war with the army you have, not the army you might want or wish to have at a later time." 3.5.2 final and 3.4.5 final will ship with Matthias's patch as proposed. FWIW I'

[issue27401] Wrong FTP links in 3.5.2 installer

Larry Hastings added the comment: I can independently confirm that the "amd64" directory is in the proper place, and all relevant files & directories look like they have the correct permissions. I did that by logging in to the appropriate server and nosing around. Also, the

[issue19802] socket.SO_PRIORITY is missing

Larry Hastings added the comment: Sorry, this is now too late for 3.4. 3.4 is now in "security fixes only" mode. This is not a security fix, therefore 3.4 is now ineligible. Since this change was committed to 3.5, it's better to let the historical record reflect that. So I

[issue24557] Refactor LibreSSL / EGD detection

Changes by Larry Hastings : -- nosy: -larry ___ Python tracker <http://bugs.python.org/issue24557> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24557] Refactor LibreSSL / EGD detection

Larry Hastings added the comment: At this point you're not adding this to 3.5. -- versions: -Python 3.5 ___ Python tracker <http://bugs.python.org/is

[issue26944] android: test_posix fails

Larry Hastings added the comment: Is there a plan to make Android a supported platform in 3.6? -- ___ Python tracker <http://bugs.python.org/issue26944> ___ ___

[issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing

Larry Hastings added the comment: I can fix it. Are instructions on how to update that in PEP 101 and I missed it? (Do you know where it is in the Django maze of twisty little passages?) -- ___ Python tracker <http://bugs.python.org/issue25

[issue25170] 3.4.4, 3.4.5, 3.5.0, 3.5.1, 3.5.2 documentation archives missing

Larry Hastings added the comment: Okay, I've updated the doc, and verified that the links work. The releases/3.5.0 directory had problems; it had bad permissions, and was stuck on 3.5.0a3 or something. I blew it away and installed the 3.5.0 final docs from the tarball and se

[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)

Larry Hastings added the comment: 3.4 is also in security-fixes-only mode, which also means it's in no-binary-installers mode. Good luck making the case that "this bugfix, which took us more than 2.5 years to finalize, is so critical that the release team must immediately is

[issue24648] Allocation of values array in split dicts should use small object allocator.

Changes by Larry Hastings : -- nosy: +aniawsz, larry ___ Python tracker <http://bugs.python.org/issue24648> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24648] Allocation of values array in split dicts should use small object allocator.

Larry Hastings added the comment: Assigning to myself on behalf of "aniawsz". I actually want to assign it to her but for some reason I can't. (Maybe because she doesn't have the commit bit?) -- assignee: -> larry __

[issue17170] string method lookup is too slow

Larry Hastings added the comment: Argument Clinic has languished for lack of time. I didn't get much feedback, though a couple people were shouting for a PEP, which I was resisting. I figured, if they have something to say, they can go ahead and reply on the tracker issue, and if they

[issue17170] string method lookup is too slow

Larry Hastings added the comment: Oh, and, as to whether Argument Clinic would solve this problem, the answer is "not yet". Right now Argument Clinic literally generates calls to PyArg_ParseTupleAndKeywords. (In special cases it switches to PyArg_ParseTuple.) I'm mor

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

Larry Hastings added the comment: Okay, I have finally addressed all the comments so far. Changes described below are my patch #2. They're also checked in to https://bitbucket.org/larry/python-clinic/ . * Antoine, Nick, et al: I've converted clinic.txt into a PEP. I've alr

[issue16801] Preserve original representation for integers / floats in docstrings

Larry Hastings added the comment: FWIW I think the octint class is a great idea. It's nice and localized, and it should have no performance impact and only a small maintenance impact. It'll also preserve the readability of the default if you pull it out with inspect.getf

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

Larry Hastings added the comment: Argument Clinic is now PEP 436. http://www.python.org/dev/peps/pep-0436/ -- ___ Python tracker <http://bugs.python.org/issue16

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

Larry Hastings added the comment: A quick note about the extension mechanism. Currently the only way to extend PyArg_Parse* is via O&. Therefore, any extended type you add will use O&, and will have a "converter". So internally all I did was say "if the parameter h

[issue16612] Integrate "Argument Clinic" specialized preprocessor into CPython trunk

Larry Hastings added the comment: As a rule I'm unlikely to mention things I haven't heard about. I've never used Cython, and I don't recall anyone mentioning this technology previously. Once skrah posts his alternative DSL proposal, I'll amend the PEP to discuss

<    14   15   16   17   18   19   20   21   22   23   >