On 6 October 2017 at 11:48, Eric Snow wrote:
> > And that's the real pay-off that comes from defining this in terms of the
> > memoryview protocol: Py_buffer structs *aren't* Python objects, so it's
> only
> > a regular C struct that gets passed across the interpreter boundary (the
> > reference
On 2017-10-06 03:19, Yubin Ruan wrote:
Hi,
I am looking for the implementation of open() in the src, but so far I
am not able to do this.
From my observation, the implementation of open() in python2/3 does
not employ the open(2) system call. However without open(2) how can
one possibly obtain
2017-10-05 19:19 GMT-07:00 Yubin Ruan :
> Hi,
> I am looking for the implementation of open() in the src, but so far I
> am not able to do this.
>
> In Python 3, builtins.open is the same as io.open, which is implemented in
the _io_open function in Modules/_io/_iomodule.c.
> From my observation,
On 6 October 2017 at 06:35, Giampaolo Rodola' wrote:
> On Wed, Oct 4, 2017 at 11:52 AM, Victor Stinner
> wrote:
>
>> By the way, we need maybe also a new "module name" field in the bug
>> tracker. But then comes the question of normalizing module names. For
>> example, should "email.message" be
On 5 October 2017 at 23:44, Barry Warsaw wrote:
> On Oct 4, 2017, at 13:53, Benjamin Peterson wrote:
>
> > It might be helpful to enumerate the usecases for such an API. Perhaps a
> > narrow, specialized API could satisfy most needs in a supportable way.
>
> Currently `python -m dis thing.py` co
Hi,
I am looking for the implementation of open() in the src, but so far I
am not able to do this.
>From my observation, the implementation of open() in python2/3 does
not employ the open(2) system call. However without open(2) how can
one possibly obtain a file descriptor?
Yubin
On Thu, Oct 5, 2017 at 4:57 AM, Nick Coghlan wrote:
> This would be hard to get to work reliably, because "orig.tp_share()" would
> be running in the receiving interpreter, but all the attributes of "orig"
> would have been allocated by the sending interpreter. It gets more reliable
> if it's *Cha
> I don't know what is the best option, but I dislike adding two
> options, PYTHONBREAKPOINT and -X nobreakpoint, for the same features.
> I would become complicated to know which option has the priority.
Just to close the loop, I’ve landed the PEP 553 PR treating PYTHONBREAKPOINT
the same as all
On Tue, Oct 3, 2017 at 1:11 AM, Koos Zevenhoven wrote:
> On Oct 3, 2017 01:00, "Guido van Rossum" wrote:
>
> Mon, Oct 2, 2017 at 2:52 PM, Koos Zevenhoven wrote
>
> I don't mind this (or Nathaniel ;-) being academic. The backwards
>> incompatibility issue I've just described applies to any exte
On Wed, Oct 4, 2017 at 11:52 AM, Victor Stinner
wrote:
> Hi,
>
> Python uses a few categories to group bugs (on bugs.python.org) and
> NEWS entries (in the Python changelog). List used by the blurb tool:
>
> #.. section: Security
> #.. section: Core and Builtins
> #.. section: Library
> #.. secti
Honestly I think the API for accessing historic pyc headers should itself
also be 3rd party. CPython itself should not bother (backwards
compatibility with pyc files has never been a feature).
On Thu, Oct 5, 2017 at 6:44 AM, Barry Warsaw wrote:
> On Oct 4, 2017, at 13:53, Benjamin Peterson wrot
On Oct 4, 2017, at 13:53, Benjamin Peterson wrote:
> It might be helpful to enumerate the usecases for such an API. Perhaps a
> narrow, specialized API could satisfy most needs in a supportable way.
Currently `python -m dis thing.py` compiles the source then disassembles it.
It would be kind o
> What if make the default value depending on the debug level? In debug mode
> it is "pdb.set_trace", in optimized mode it is "0". Then in production
> environments you can use -E -O for ignoring environment settings and disable
> breakpoints.
I don't know what is the best option, but I dislike ad
On 5 October 2017 at 18:45, Eric Snow wrote:
> After we move to not sharing the GIL between interpreters:
>
> Channel.send(obj): # in interp A
> incref(obj)
> if type(obj).tp_share == NULL:
> raise ValueError("not a shareable type")
> set_owner(obj) # obj.owner or add an obj
On Tue, Oct 3, 2017 at 8:55 AM, Antoine Pitrou wrote:
> I think we need a sharing protocol, not just a flag. We also need to
> think carefully about that protocol, so that it does not imply
> unnecessary memory copies. Therefore I think the protocol should be
> something like the buffer protocol
04.10.17 21:06, Barry Warsaw пише:
Victor brings up a good question in his review of the PEP 553 implementation.
https://github.com/python/cpython/pull/3355
https://bugs.python.org/issue31353
The question is whether $PYTHONBREAKPOINT should be ignored if -E is given?
I think it makes sense for
I concur with Antoine, please don't add a special case for -E. But it seems
like you already agreed with that :-)
Victor
Le 5 oct. 2017 05:33, "Barry Warsaw" a écrit :
> On Oct 4, 2017, at 21:52, Nick Coghlan wrote:
> >
> >> Unfortunately we probably won’t really get a good answer in practice
17 matches
Mail list logo
