Re: [Python-Dev] TextIO seek and tell cookies

that they would be interpreted correctly in any receiving instance. Cheers, Ben On 26 September 2016 at 02:30, Ben Leslie <be...@benno.id.au> wrote: > I think the case of JSON or SQL database is even more important though. > > tell/seek can return 129-bit integers (maybe even more? my maths

Re: [Python-Dev] TextIO seek and tell cookies

PI idiot proof. > > On Sun, Sep 25, 2016 at 9:05 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 26 September 2016 at 10:21, MRAB <pyt...@mrabarnett.plus.com> wrote: >>> On 2016-09-26 00:21, Ben Leslie wrote: >>>> Are there any downsides to this?

Re: [Python-Dev] TextIO seek and tell cookies

On 25 September 2016 at 17:21, MRAB <pyt...@mrabarnett.plus.com> wrote: > On 2016-09-26 00:21, Ben Leslie wrote: >> >> Hi all, >> >> I recently shot myself in the foot by assuming that TextIO.tell >> returned integers rather than opaque cookies. Specifically

[Python-Dev] TextIO seek and tell cookies

Hi all, I recently shot myself in the foot by assuming that TextIO.tell returned integers rather than opaque cookies. Specifically I was adding an offset to the value returned by TextIO.tell. In retrospect this doesn't make sense/ Now, I don't want to drive change simply because I failed to read

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 9 June 2016 at 13:29, Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, Jun 09, 2016 at 12:54:31PM -0400, Ben Leslie wrote: > >> I think an exception is much easier for a user to deal with from a >> practical point of view. Trying to work out why a process has hung

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 9 June 2016 at 12:39, Donald Stufft wrote: > >> On Jun 9, 2016, at 12:30 PM, Steven D'Aprano wrote: >> >>> >>> os.urandom >>> -- >> [...] >>> With that in mind, I think that we should, to the best of our ability given >>> the >>> platform we're

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

at 6:16 PM, Nick Coghlan ncogh...@gmail.com wrote: On 14 Jun 2015 10:01, Ben Leslie be...@benno.id.au wrote: If this seems like a good approach I'll try and work it in to a suitable patch for contribution. I think it's a good approach, and worth opening an enhancement issue for. I expect

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

On 14 June 2015 at 09:20, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Nick Coghlan wrote: I wonder if in 3.6 it might be possible to *add* some bookkeeping to await and yield from expressions that provides external visibility into the underlying iterable or coroutine that the

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

On 13 June 2015 at 19:03, Guido van Rossum gu...@python.org wrote: On Sat, Jun 13, 2015 at 12:22 AM, Nick Coghlan ncogh...@gmail.com wrote: On 13 June 2015 at 04:13, Guido van Rossum gu...@python.org wrote: IOW I don't think that the problem here is that you haven't sufficiently motivated

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

On 13 June 2015 at 17:22, Nick Coghlan ncogh...@gmail.com wrote: On 13 June 2015 at 04:13, Guido van Rossum gu...@python.org wrote: IOW I don't think that the problem here is that you haven't sufficiently motivated your use case -- you are asking for information that just isn't available.

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

On 2 June 2015 at 14:39, Yury Selivanov yselivanov...@gmail.com wrote: Hi Ben, On 2015-05-31 8:35 AM, Ben Leslie wrote: Hi Yury, I'm just starting my exploration into using async/await; all my 'real-world' scenarios are currently hypothetical. One such hypothetical scenario however

Re: [Python-Dev] Obtaining stack-frames from co-routine objects

where you would need this? It looks like this can help with debugging, somehow, but the easiest solution is to put a if debug: log(...) before yield in your switch() function. You'll have a perfect traceback there. Thanks, Yury On 2015-05-29 12:46 AM, Ben Leslie wrote: Hi all, Apologies

[Python-Dev] Obtaining stack-frames from co-routine objects

Hi all, Apologies in advance; I'm not a regular, and this may have been handled already (but I couldn't find it when searching). I've been using the new async/await functionality (congrats again to Yury on getting that through!), and I'd like to get a stack trace between the place at which

Re: [Python-Dev] Introducing Electronic Contributor Agreements

On Tue, Mar 5, 2013 at 3:30 AM, Brian Curtin br...@python.org wrote: The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at

[Python-Dev] Should libpython.a go in eprefix?

Hi all, This issue: http://bugs.python.org/issue9807 from a couple of years ago seems to have changed the LIBPL build variable from pointing to a directory inside EPREFIX, to a directory in PREFIX. This doesn't seem ideal as LIBPL is populated with platform specific files such as libpython.a.

Re: [Python-Dev] fork or exec?

On Fri, Jan 11, 2013 at 5:30 PM, Charles-François Natali cf.nat...@gmail.com wrote: That could always be overcome by passing close_fds=False explicitly to subprocess from my code, though, right? I'm not doing that now, but then I'm not using the esoteric options in python-gnupg code,

[Python-Dev] http.client Nagle/delayed-ack optimization

The http.client HTTPConnection._send_output method has an optimization for avoiding bad interactions between delayed-ack and the Nagle algorithm: http://hg.python.org/cpython/file/f32f67d26035/Lib/http/client.py#l884 Unfortunately this interacts rather poorly if the case where the message_body

[Python-Dev] Thread/garbage collection race in Popen

Hi all, I have a Python program where I have many threads each calling Popen, and I was hitting some trouble. I've been seeing this on 3.2.3, however I believe the same issue is still potentially a problem on head. The error manifests itself when a call to os.close(errpipe_read) fails with