On Jul 14, 2013, at 8:13 AM, Brett Cannon wrote:
On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 13 July 2013 23:26, David Beazley d...@dabeaz.com wrote:
I'm in favor of PLY going into stdlib with the caveat that there are some
things about it that should
?
Who is the maintainer and what is his opinion?
The maintainer is David Beazley and as far as I recall he has not expressed
an opinion on this particular question. It would obviously need his agreement
(and maintenance commitment) if it is to fly.
Just because we have now had two
From: Eli Bendersky eli...@gmail.com
I'll be the first one to admit that pycparser is almost certainly not
generally useful enough to be exposed in the stdlib. So just using it as an
implementation detail is absolutely fine. PLY is a more interesting
question, however, since PLY is
On Sep 21, 2012, at 4:45 AM, Maciej Fijalkowski wrote:
This is also kind of a problem with PyPy and CFFI, where we actively
discourage people from using C. Passing address as an int sounds like
a very reasonable solution.
I just wanted to add that getting the address as an integer is
I have recently been experimenting with the memoryview() built-in and have come
to believe that it really needs to expose the 'buf' attribute of the underlying
Py_buffer structure as an integer (see PEP 3118). Let me explain.
The whole point of PEP 3118 (as I understand it) is to provide a
How? I must be missing something very obvious.
Cheers,
Dave
On Sep 20, 2012, at 11:48 AM, Benjamin Peterson wrote:
2012/9/20 David Beazley d...@dabeaz.com:
I have recently been experimenting with the memoryview() built-in and have
come to believe that it really needs to expose the 'buf
generated via
LLVM.
Cheers,
Dave
On Sep 20, 2012, at 1:20 PM, Benjamin Peterson wrote:
2012/9/20 David Beazley d...@dabeaz.com:
How? I must be missing something very obvious.
If you have some ctypes function that requires a pointer and you pass
a memoryview, ctypes should pass
this. For instance array.buffer_info().
Cheers
Dave
Sent from cell
On Sep 20, 2012, at 6:16 PM, Glyph gl...@twistedmatrix.com wrote:
Le Sep 20, 2012 à 11:35 AM, David Beazley d...@dabeaz.com a écrit :
Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.
I get a type error
On Mon, Aug 29, 2011 at 12:27 PM, Guido van Rossum gu...@python.org wrote:
I wonder if for
this particular purpose SWIG isn't the better match. (If SWIG weren't
universally hated, even by its original author. :-)
Hate is probably a strong word, but as the author of Swig, let me chime in here
Message: 1
Date: Tue, 9 Aug 2011 15:31:47 +0600
From: ? socketp...@gmail.com
To: python-dev@python.org
Subject: [Python-Dev] GIL removal question
Message-ID:
CAEmTpZGe2J6poDUW3sihHS3LHDdQ3cq5gWqfty_=z5w8r0r...@mail.gmail.com
Content-Type: text/plain; charset=UTF-8
On Aug 10, 2011, at 6:15 AM, Nick Coghlan wrote:
On Wed, Aug 10, 2011 at 9:09 PM, David Beazley d...@dabeaz.com wrote:
You're forgetting step 5.
5. Put fine-grain locks around all reference counting operations (or rewrite
all of Python's memory management and garbage collection from
I would like to propose removing IDLE from the standard library.
-1000. From the Python training department, I would like to say that this
would be a horrible idea. Having taught numerous on-site training courses for
Python, the one thing that I've learned is that you never know what
From: Martin v. L?wis mar...@v.loewis.de
To: Dj Gilcrease digitalx...@gmail.com
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)
Message-ID: 4bf385e3.9030...@v.loewis.de
Content-Type: text/plain; charset=ISO-8859-1
I think the new GIL should be
Yes, but the million dollar question is whether or not it really is superior
with the I/O convoying problem in the current implementation (an effect that is
substantially worse with the new GIL than with the old one by the way).
Personally, I think the convoying issue is something that will
Antoine,
This is a pretty good summary that mirrors my thoughts on the GIL matter as
well. In the big picture, I do think it's desirable for Python to address the
multicore performance issue--namely to not have the performance needlessly
thrashed in that environment. The original new GIL
) and the turnaround
time to test new approaches in production for us is a bit high J
K
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Robert Hancock
Sent: 16. mars 2010 20:10
To: Peter Portante
Cc: David
.
What we are trying to write here is a thread scheduler, and that is complex
business.
K
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
Of David Beazley
Sent: 15. mars 2010 03:07
On Mon 15/03/10 4:34 AM , Martin v. Löwis mar...@v.loewis.de sent:
So, just to be clear about the my bug report, it
is directly related to the problem of overlapping I/O requests with
CPU-bound processing. This kind of scenario comes up in the context of
many applications--especially those
I have been following this discussion about fixing the GIL and just wanted to
make a few comments about it.
To the doubters who don't think this is a real problem worth fixing, I must
respectfully disagree. Multicore systems and parallel programming issues are
not
going away any time in the
19 matches
Mail list logo
