On Tue, Apr 16, 2019 at 2:11 AM Victor Stinner wrote:
> Hi Michael,
>
> Do you know the tracemalloc module? Did you try it? It works on a
> regular Python (compiled in debug mode).
>
> I would be curious to know if tracemalloc also allows you to track the
> memory leak.
>
> Playing around with it
On 16Apr2019 0532, Christian Heimes wrote:
Sorry, I forgot to reply.
Do you think it would make sense to split the PEP into two PEPs? The
auditing hook and import opener hook are related, but distinct
improvements. The auditing part looks solid and ready now. The import
opener may need some more
Le mar. 16 avr. 2019 à 17:46, Guido van Rossum a écrit :
> Consistency with C should not be the issue -- consistency between the time
> functions is important.
> (...)
> So let's drop the idea.
Ok, I'm fine with that. It was just an idea ;-) I closed the issue.
Victor
_
On 16.04.2019 17:24, Victor Stinner wrote:
Hi,
time.mktime() looks "inconsistent" to me and I would like to change
it, but I'm not sure how it impacts backward compatibility.
https://bugs.python.org/issue36558
time.mktime() returns a floating point number:
type(time.mktime(time.localtime()))
On Tue, Apr 16, 2019 at 8:19 AM Victor Stinner wrote:
> Le mar. 16 avr. 2019 à 16:44, Paul Ganssle a écrit :
> > 2. Mainly for Victor, but anyone can answer: I agree that the natural
> output of `mktime()` would be `int` if I were designing it today, but would
> there be any practical benefits f
Le mar. 16 avr. 2019 à 16:44, Paul Ganssle a écrit :
> 2. Mainly for Victor, but anyone can answer: I agree that the natural output
> of `mktime()` would be `int` if I were designing it today, but would there be
> any practical benefits for making this change?
It's just for the consistency of t
I would like to change mktime() return type to make the function more
consistent: all inputs are integers, it sounds wrong to me to return
float. The result should be integer as well.
In C, the signature of mktime is time_t mktime(struct tm *time);
from Wikipedia, the Unix time_t data type, on ma
I already chimed in on the issue, but for the list, I'll boil my
comments down to two questions:
1. For anyone who knows: when the documentation refers to "compatibility
with `.time`", is that just saying it was designed that way because
.time returns a float (i.e. for /consistency/ with `.time()`
Hi,
time.mktime() looks "inconsistent" to me and I would like to change
it, but I'm not sure how it impacts backward compatibility.
https://bugs.python.org/issue36558
time.mktime() returns a floating point number:
>>> type(time.mktime(time.localtime()))
The documentation says:
"It returns a f
On 16/04/2019 14.57, Victor Stinner wrote:
> Le mar. 16 avr. 2019 à 14:35, Christian Heimes a écrit
> :
>> * Linux: readlink("/proc/self/fd/%i")
>
> That doens't work if /proc is not mounted, which can occur in a
> container (where /proc is not mounted nor binded to host /proc).
No, it won't wo
Le mar. 16 avr. 2019 à 14:35, Christian Heimes a écrit :
> * Linux: readlink("/proc/self/fd/%i")
That doens't work if /proc is not mounted, which can occur in a
container (where /proc is not mounted nor binded to host /proc).
Victor
___
Python-Dev mail
Sorry, I forgot to reply.
Do you think it would make sense to split the PEP into two PEPs? The
auditing hook and import opener hook are related, but distinct
improvements. The auditing part looks solid and ready now. The import
opener may need some more refinement. I would also like to get feedbac
On 15/04/2019 23.17, Steve Dower wrote:
> On 15Apr2019 1344, Christian Heimes wrote:
>> Hi Steve,
>>
>> (memory dump before I go to bed)
>>
>> Steve Grubb from Red Hat security pointed me to some interesting things
>> [1]. For instance there is some work on a new O_MAYEXEC flag for open().
>> Steve
On 2019-04-03 07:33, Jeroen Demeyer wrote:
Access to the class isn't possible currently and also not with PEP 590.
But it's easy enough to fix that: PEP 573 adds a new METH_METHOD flag to
change the signature of the C function (not the vectorcall wrapper). PEP
580 supports this "out of the box" b
Since Python 3.6, you can use PYTHONMALLOC=malloc for Valgrind: it
avoids false alarms produced by the pymalloc allocator.
Victor
Le mar. 16 avr. 2019 à 12:09, Nathaniel Smith a écrit :
>
> On Mon, Apr 15, 2019 at 8:58 PM Michael Sullivan wrote:
> >
> > On Mon, Apr 15, 2019 at 4:06 PM Nathaniel
On Mon, Apr 15, 2019 at 8:58 PM Michael Sullivan wrote:
>
> On Mon, Apr 15, 2019 at 4:06 PM Nathaniel Smith wrote:
>>
>> On Mon, Apr 15, 2019, 15:27 Michael Sullivan wrote:
>>>
>>> > The main question is if anyone ever used Py_TRACE_REFS? Does someone
>>> > use sys.getobjects() or PYTHONDUMPREFS
Hi Michael,
Do you know the tracemalloc module? Did you try it? It works on a
regular Python (compiled in debug mode).
I would be curious to know if tracemalloc also allows you to track the
memory leak.
sys.getobjects() is just a list of objects. Do you have a tool written
on top of it to track
On Mon, Apr 15, 2019 at 8:12 PM Nathaniel Smith wrote:
> On Mon, Apr 15, 2019 at 5:00 PM Michael Sullivan wrote:
> >
> > I've submitted PEP 591 (Adding a final qualifier to typing) for
> discussion to typing-sig [1].
>
> I'm not on typing-sig [1] so I'm replying here.
>
> > Here's the abstract:
18 matches
Mail list logo
