[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 <rep...@bugs.python.org> <http://bugs.python.org/i

[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 <rep...@bugs.python.org> <http://bugs.python.org/i

[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

Re: how to search item in list of list

ing brackets to find it yourself. Most programming editors have that bracket matching capability. -- -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list

[issue27314] Cannot install 3.5.2 with 3.6.0a1 installed

Changes by Larry Hastings <la...@hastings.org>: -- nosy: -larry ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27314> ___ __

[RELEASED] Python 3.4.5rc1 and Python 3.5.2rc1 are now available

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.5rc1 and Python 3.5.2rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. All changes

[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 <rep...@bugs.python.org>

[RELEASED] Python 3.4.5rc1 and Python 3.5.2rc1 are now available

On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm pleased to announce the availability of Python 3.4.5rc1 and Python 3.5.2rc1. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. All changes

[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: +Python 3.4,

[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

[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 <rep...@bugs.python.org> <http://bugs.python.or

[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. Sorry folks

[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 assume

[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 behave

[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 t

[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

[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 <rep...@bugs.python.org> <http://bugs.python.org/i

[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 assure the user

[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,

[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 enough

[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 still open

[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: patch review

Re: i'm a python newbie & wrote my first script, can someone critique it?

it is usually better and safer to avoid globals if possible. # ---- # NOW FINISH print("" + get_timestamp() + " " + get_script_filename() + " FINISHED.") #import os #os._exit(0) Yes, your exit() is redundant and you are correct to comment it out. But again I suggest that you get used to using print formatting, it is really versatile. -- -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list

[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. All

[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:

[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" (

[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 before, it

[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): that's

[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 and never block

[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 "crypto r

[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". I

[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 added ou

[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? -- ___

[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 ruled there tha

[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 a

[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 documentation

[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 removed where &

[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 adults&quo

[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 have

[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.urandom

[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 inte

[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

[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=True) cal

[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 the OS

[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

[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

[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,

[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 yes I'm talking

[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 wrapper

[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 "StackExchange"

[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 a

[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. -- If you rea

[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 tiny

[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 of how early w

[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.urandom() should

[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 > _Py

[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 t

[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 to m

[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 <rep...@bugs.python.org> <http://bugs.python.org/i

[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. That string

[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 <rep...@bugs.python.

[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 <rep...@bugs.pyth

[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 <rep...@bugs.python.org&

[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 who care

Re: Summing/combining tuples

On 05/18/2016 09:53 PM, DFS wrote: On 5/18/2016 10:58 PM, Larry Hudson wrote: [snip...] Why two loops? Put both summations in a single loop. Then you're only scanning the alist once instead of twice. groups1 = defaultdict(int) groups2 = defaultdict(int) for nm, matches, words in alist

Re: Program prints questions for user input, but won't show the answer output

t language to learn. -=- Larry -=- PS. A final thought... I don't know your situation so this may not be reasonable but... I HIGHLY recommend switching to Python 3 instead of 2. Version 2 is at "end-of-life" and won't be updated any further. Version 3 is where all future development

Re: Summing/combining tuples

instead of twice. groups1 = defaultdict(int) groups2 = defaultdict(int) for nm, matches, words in alist: groups1[nm] += matches groups2[nm] += words -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list

Re: Wanted Python programmer to join team

On Tue, May 17, 2016 at 1:29 AM, Chris Angelico wrote: > On Tue, May 17, 2016 at 3:20 PM, Steven D'Aprano > wrote: >>> And a lot of job postings do come from that sort of really small >>> business, trying to expand a bit. Plus, some of them

gevent

Does anyone here use gevent? I posted a question on the gevent mailing list, here, and on SO and did not get any replies on any of them. I have a client that is using it - I had never heard of it before, and now I am wondering how big the user base and community is. --

[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length

Larry Hastings added the comment: Martin said: > Josh: it's not as simple as just changing the type code and variable type. > Systems used to require all kinds of types in the length parameter of read(2) > and fread(3), including int, long, and size_t. If it was int, passing size_t

[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length

Larry Hastings added the comment: Updated patch based on feedback from Serihy. Thanks for the ping. -- Added file: http://bugs.python.org/file42860/larry.make.file_read.use.size_t.2.diff ___ Python tracker <rep...@bugs.python.org>

[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length

Larry Hastings added the comment: Summary: read Matt's original message on the bug. Status: still broken. Some people think it should be left that way. Proposed fix: it's straightforward to fix. You wrote a patch, I modified yours a little. The patch is short and easy to read

Re: pylint woes

On 05/08/2016 03:07 PM, Chris Angelico wrote: On Mon, May 9, 2016 at 6:45 AM, Larry Hudson via Python-list <python-list@python.org> wrote: On 05/08/2016 06:01 AM, Chris Angelico wrote: [snip...] ... I like to recommend a little thing called &

Re: pylint woes

On 05/08/2016 06:01 AM, Chris Angelico wrote: [snip...] ... I like to recommend a little thing called "IIDPIO debugging" - If In Doubt, Print It Out. That means: If you have no idea what a piece of code is doing, slap in a print() call somewhere. It'll

Re: starting docker container messes up terminal settings

On Mon, May 2, 2016 at 10:28 AM, Larry Martell <larry.mart...@gmail.com> wrote: > On Mon, May 2, 2016 at 10:08 AM, Joaquin Alzola > <joaquin.alz...@lebara.com> wrote: >>>I am starting a docker container from a subprocess.Popen and it works, but >>>when the s

Re: How to see html code under the particular web page element?

On Sat, May 7, 2016 at 10:27 AM, wrote: > Hi, > > on page: > https://hrti.hrt.hr/#/video/show/2203605/trebizat-prica-o-jednoj-vodi-i-jednom-narodu-dokumentarni-film > > there is a picture and in the middle of the picture there is a text > "Prijavite se za gledanje!" > > If

[issue16113] Add SHA-3 and SHAKE (Keccak) support

Larry Hastings added the comment: Christian: any interest in proposing this for 2.7? We could ask Benjamin. It could still make 2.7.11--rc1 should be tagged in about a month. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.p

Re: How to become more motivated to learn Python

On 05/03/2016 07:55 PM, Cai Gengyang wrote: Cool, I have finally summoned up enough activation energy to start on Unit 3, now going through the topic on Conditionals and Control Flows (stuff like this) boolthree = 200 == (50 * 5) boolthree False Guess it would be really cool to work on AI

Broken pipe from gevent/pywsgi.py

I have a python server that has this in the main: from gevent import pywsgi try: httpd = pywsgi.WSGIServer(('0.0.0.0', 8000), app) httpd.serve_forever() except KeyboardInterrupt: pass Recently we began getting HTTPError: 504 Server Error: Gateway Time-out on requests to the server.

Re: You gotta love a 2-line python solution

On Mon, May 2, 2016 at 11:15 AM, DFS wrote: > Of course. Taken to its extreme, I could eventually replace you with one > line of code :) That reminds me of something I heard many years ago. Every non-trivial program can be simplified by at least one line of code. Every non

Re: starting docker container messes up terminal settings

On Mon, May 2, 2016 at 10:08 AM, Joaquin Alzola wrote: >>I am starting a docker container from a subprocess.Popen and it works, but >>when the script returns, the terminal settings of my shell are messed up. >>Nothing is echoed and return doesn't cause a >newline. I

starting docker container messes up terminal settings

I am starting a docker container from a subprocess.Popen and it works, but when the script returns, the terminal settings of my shell are messed up. Nothing is echoed and return doesn't cause a newline. I can fix this with 'tset' in the terminal, but I don't want to require that. Has anyone here

[issue26905] from multiprocessing.pool import Pool bug on linux

Larry Hastings added the comment: This has nothing to do with Argument Clinic, which is an internal tool used in the Python 3.x series. -- components: -Argument Clinic nosy: -859911096 ___ Python tracker <rep...@bugs.python.org>

[issue23867] Argument Clinic: inline parsing code for 1-argument functions

Larry Hastings added the comment: Why is this dependent on #26305? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23867> ___ ___

[issue26305] Make Argument Clinic to generate PEP 7 conforming code

Larry Hastings added the comment: I'm not excited by this new addition to PEP 7, so I'm excusing myself from this issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue26902] Argument Clinic incorrectly works with custom converter and renamed parameter

Larry Hastings added the comment: This is caused by your "meth_o inline" code, which isn't checked in yet. A clean checkout of CPython trunk generates this correct code: if (!PyArg_Parse(arg, "O&:test", PyUnicode_FSConverter, )) Maybe you don't need to use

[issue26901] Argument Clinic test is broken

Larry Hastings added the comment: I will admit that even during development I rarely used Clinic's test suite. My test suite is: make a change, then run Clinic over all of CPython and do a diff. If nothing changed then Clinic is still working

[issue26891] CPython doesn't work when you disable refcounting

Larry Hastings added the comment: Here is my theory: if the code asserts that it's true, and the code normally runs fine, then it's normally true, and therefore I can remove the assertion and the code will run correctly. I haven't hit that assertion in the peephole optimizer. But I have

[issue26891] CPython doesn't work when you disable refcounting

Larry Hastings added the comment: I did as you suggested. I also discovered that _Py_NewReference is usually a macro, and I'd only fixed the version in Objects/object.c (the one not being used). When I fixed both those things, and switched the makefile so it uses a different Python

[issue26891] CPython doesn't work when you disable refcounting

Changes by Larry Hastings <la...@hastings.org>: -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26891> ___

[issue26891] CPython doesn't work when you disable refcounting

New submission from Larry Hastings: So here's a strange one. I want to do some mysterious experiments with CPython. So I disabled refcount changes in CPython. I changed Py_INCR and Py_DECR so they expand to nothing. I had to change some other macros to match (SETREF, XSETREF

[issue26825] Variable defined in exec(code) unreachable inside function call with visible name in dir() results

Changes by Larry Hastings <la...@hastings.org>: -- nosy: -larry ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26825> ___ __

[issue26800] Don't accept bytearray as filenames part 2

Larry Hastings added the comment: I did the path_converter change. IIRC some functions supported bytearray, some did not, and in my quest for consistency I took the superset of functionality and supported bytearray for everything. Sounds to me like bytearray support should be dropped

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

Larry Hastings added the comment: Yes, I've been working on a patch to do this as well. I called the calling convention METH_RAW, to go alongside METH_ZERO METH_O etc. My calling convention was exactly the same as yours: PyObject *(PyObject *o, PyObject **stack, int na, int nk). I only had

Re: Guido sees the light: PEP 8 updated

On Tue, Apr 19, 2016 at 11:50 AM, Steven D'Aprano wrote: > On Wed, 20 Apr 2016 12:54 am, Rustom Mody wrote: > > >> I wonder who the joke is on: >> >> | A study comparing Canadian and Chinese students found that the latter >> | were better at complex maths > > Most published

Re: read datas from sensors and plotting

On Sunday, April 17, 2016, ranran wrote: > I'm reading in python some values from some sensors and I write them in a > csv file. > My problem now is to use this datas to plot a realtime graph for a example > in a web server. > Is it possible to read in the same time the values,

Re: Guido sees the light: PEP 8 updated

On Sat, Apr 16, 2016 at 2:18 PM, BartC <b...@freeuk.com> wrote: > On 16/04/2016 17:58, Larry Martell wrote: >> >> On Sat, Apr 16, 2016 at 12:51 PM, Marko Rauhamaa <ma...@pacujo.net> wrote: >>> >>> Larry Martell <larry.mart...@gmail.com>:

Re: Guido sees the light: PEP 8 updated

On Sat, Apr 16, 2016 at 12:51 PM, Marko Rauhamaa <ma...@pacujo.net> wrote: > Larry Martell <larry.mart...@gmail.com>: > >> I have worked for many companies where you are required to get a clean >> run of pep8 on your code before your pull request will even be >&

Re: Guido sees the light: PEP 8 updated

On Sat, Apr 16, 2016 at 8:32 AM, Stephen Hansen wrote: > On Sat, Apr 16, 2016, at 01:51 AM, Marko Rauhamaa wrote: >> Chris Angelico : >> >> > On Sat, Apr 16, 2016 at 6:06 PM, Marko Rauhamaa wrote: >> >> It doesn't really matter one way or

[issue26753] Obmalloc lock LOCK_INIT and LOCK_FINI are never used

Larry Hastings added the comment: Oy veh, in editing the issue I dropped the attached file. Here it is. -- keywords: +patch Added file: http://bugs.python.org/file42479/larry.refresh.lock.macros.for.obmalloc.diff ___ Python tracker <

<    5   6   7   8   9   10   11   12   13   14   >