On Thu, Feb 04, 2016 at 07:58:30PM -0500, Terry Reedy wrote:
> >>For folks that *do* know how to use the terminal:
> >>
> >>$ python3 -m inspect --details inspect
> >>Target: inspect
> >>Origin: /usr/lib64/python3.4/inspect.py
> >>Cached: /usr/lib64/python3.4/__pycache__/inspect.cpython-34.pyc
> >
Nick Coghlan writes:
> If someone else wanted to also describe the change in a PEP for ease
> of future reference, using Yury's ceval.txt as input, I do think that
> would be a good thing, but I wouldn't want to make the enhancement
> conditional on someone volunteering to do that.
I wasn't s
On 2/4/2016 12:18 PM, Sven R. Kunze wrote:
On 04.02.2016 14:09, Nick Coghlan wrote:
On 2 February 2016 at 06:39, Andrew Barnert via Python-Dev
wrote:
On Feb 1, 2016, at 09:59,mike.romb...@comcast.net wrote:
If the stdlib were to use implicit namespace packages
(https://www.python.org/dev/
> On Feb 4, 2016, at 08:22, Sven R. Kunze wrote:
>
> On 04.02.2016 16:57, Matthias Bussonnier wrote:
>>> On Feb 3, 2016, at 13:22, Yury Selivanov wrote:
>>>
>>>
>>> An ideal way would be to calculate a hit/miss ratio over time
>>> for each cached opcode, but that would be an expensive
>>> cal
I am well aware of this. In the SO question I referenced, being the
first google hit related this this... that is the answer *I* gave. It
only works, in my experience, 60% of the time, and not with two biggie
packages (pywin32, for which you have to go to third parties to get the
wheel, which
On 04.02.2016 14:09, Nick Coghlan wrote:
On 2 February 2016 at 06:39, Andrew Barnert via Python-Dev
wrote:
On Feb 1, 2016, at 09:59, mike.romb...@comcast.net wrote:
If the stdlib were to use implicit namespace packages
( https://www.python.org/dev/peps/pep-0420/ ) and the various
loaders/imp
On 04.02.2016 16:57, Matthias Bussonnier wrote:
On Feb 3, 2016, at 13:22, Yury Selivanov wrote:
An ideal way would be to calculate a hit/miss ratio over time
for each cached opcode, but that would be an expensive
calculation.
Do you mean like a sliding windows ?
Otherwise if you just want a l
> On Feb 3, 2016, at 13:22, Yury Selivanov wrote:
>
>
> An ideal way would be to calculate a hit/miss ratio over time
> for each cached opcode, but that would be an expensive
> calculation.
Do you mean like a sliding windows ?
Otherwise if you just want a let's say 20% miss threshold, you incr
On 04.02.2016 14:25, Victor Stinner wrote:
> Thanks for your feedback, you are asking good questions :-)
>
> 2016-02-04 13:54 GMT+01:00 M.-A. Lemburg :
>>> There are 536 calls to the functions PyMem_Malloc(), PyMem_Realloc()
>>> and PyMem_Free().
>>>
>>> I would prefer to modify a single place hav
On 3 February 2016 at 15:15, Steve Dower wrote:
> Presented in PEP-like form here, but if feedback suggests
> just putting it in the docs I'm okay with that too.
We don't really have anywhere in the docs to track platform
integration topics like this, so an Informational PEP is your best
bet.
Ch
On 4 February 2016 at 16:48, Zachary Ware wrote:
> I'm happy to announce that speed.python.org is finally functional!
> There's not much there yet, as each benchmark builder has only sent
> one result so far (and one of those involved a bit of cheating on my
> part), but it's there.
>
> There are
On 4 February 2016 at 16:48, Zachary Ware wrote:
> I'm happy to announce that speed.python.org is finally functional!
> There's not much there yet, as each benchmark builder has only sent
> one result so far (and one of those involved a bit of cheating on my
> part), but it's there.
>
> There are
On 3 February 2016 at 06:49, Stephen J. Turnbull wrote:
> Yury Selivanov writes:
>
> > Not sure about that... PEPs take a LOT of time :(
>
> Informational PEPs need not take so much time, no more than you would
> spend on ceval.txt. I'm sure a PEP would get a lot more attention
> from reviewers,
Thanks for your feedback, you are asking good questions :-)
2016-02-04 13:54 GMT+01:00 M.-A. Lemburg :
>> There are 536 calls to the functions PyMem_Malloc(), PyMem_Realloc()
>> and PyMem_Free().
>>
>> I would prefer to modify a single place having to replace 536 calls :-/
>
> You have a point the
On 3 February 2016 at 03:52, Brett Cannon wrote:
> Fifth, if we manage to show that a C API can easily be added to CPython to
> make a JIT something that can simply be plugged in and be useful, then we
> will also have a basic JIT framework for people to use. As I said, our use
> of CoreCLR is jus
On 2 February 2016 at 06:39, Andrew Barnert via Python-Dev
wrote:
> On Feb 1, 2016, at 09:59, mike.romb...@comcast.net wrote:
>>
>> If the stdlib were to use implicit namespace packages
>> ( https://www.python.org/dev/peps/pep-0420/ ) and the various
>> loaders/importers as well, then python coul
On 2 February 2016 at 02:40, R. David Murray wrote:
> On the other hand, if the distros go the way Nick has (I think) been
> advocating, and have a separate 'system python for system scripts' that
> is independent of the one installed for user use, having the system-only
> python be frozen and sou
On 04.02.2016 13:29, Victor Stinner wrote:
> Hi,
>
> 2016-02-04 11:17 GMT+01:00 M.-A. Lemburg :
>>> Do you see any drawback of using pymalloc for PyMem_Malloc()?
>>
>> Yes: You cannot free memory allocated using pymalloc with the
>> standard C lib free().
>
> That's not completly new.
>
> If Pyt
Hi,
2016-02-04 11:17 GMT+01:00 M.-A. Lemburg :
>> Do you see any drawback of using pymalloc for PyMem_Malloc()?
>
> Yes: You cannot free memory allocated using pymalloc with the
> standard C lib free().
That's not completly new.
If Python is compiled in debug mode, you get a fatal error with a h
On 03.02.2016 22:03, Victor Stinner wrote:
> Hi,
>
> There is an old discussion about the performance of PyMem_Malloc()
> memory allocator. CPython is stressing a lot memory allocators. Last
> time I made statistics, it was for the PEP 454:
> "For example, the Python test suites calls malloc() , r
Great!
2016-02-04 7:48 GMT+01:00 Zachary Ware :
> I'm happy to announce that speed.python.org is finally functional!
> There's not much there yet, as each benchmark builder has only sent
> one result so far (and one of those involved a bit of cheating on my
> part), but it's there.
>
> There are l
21 matches
Mail list logo
