On Jul 14, 2013, at 8:13 AM, Brett Cannon wrote:
>
>
>
> On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan wrote:
> On 13 July 2013 23:26, David Beazley wrote:
> I'm in favor of PLY going into stdlib with the caveat that there are some
> things about it that should
akes it an ideal candidate for
> >> standard library inclusion.
> >>
> >> Is this still on the table?
> >
> > 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
>
> From: Eli Bendersky
>
> 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 somewhat more ge
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
ready do this. For instance array.buffer_info().
Cheers
Dave
Sent from cell
On Sep 20, 2012, at 6:16 PM, Glyph wrote:
> Le Sep 20, 2012 à 11:35 AM, David Beazley a écrit :
>
>> Well, if it's supposed to do that, it certainly doesn't work for me in 3.3.
>> I ge
a bunch of code generated via
LLVM.
Cheers,
Dave
On Sep 20, 2012, at 1:20 PM, Benjamin Peterson wrote:
> 2012/9/20 David Beazley :
>> How? I must be missing something very obvious.
>
> If you have some ctypes function that requires a pointer and you pass
> a memoryview, ctyp
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 :
>> I have recently been experimenting with the memoryview() built-in and have
>> come to believe that it really needs to expose the &#x
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 mean
On Mon, Aug 29, 2011 at 12:27 PM, Guido van Rossum 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
;-). I thin
On Aug 10, 2011, at 6:15 AM, Nick Coghlan wrote:
> On Wed, Aug 10, 2011 at 9:09 PM, David Beazley wrote:
>> You're forgetting step 5.
>>
>> 5. Put fine-grain locks around all reference counting operations (or rewrite
>> all of Python's memory managemen
>
> Message: 1
> Date: Tue, 9 Aug 2011 15:31:47 +0600
> From: ?
> To: python-dev@python.org
> Subject: [Python-Dev] GIL removal question
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> Probably I want to re-invent a bicycle. I want developers to say me
> why we
> 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 y
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 hav
> From: "Martin v. L?wis"
> To: Dj Gilcrease
> 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 given a year or so in the wild
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 ad
gt; Robert Hancock
> Sent: 16. mars 2010 20:10
> To: Peter Portante
> Cc: David Beazley; python-dev@python.org
> Subject: Re: [Python-Dev] "Fixing" the new GIL
>
> The Linux kernel scheduler deals with two types of ratings and has a
> heuristic algorithm that rewards
d 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--especia
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
