> Thanks for the pointer. I noticed that subtype_dealloc is only called for
> types
> that are allocated using type_new(). Does this mean that it is not
> safe to create
> types in C using just PyType_Ready() and set Py_TPFLAGS_HEAPTYPE on
> them? The documentation is not clear on this point.
On behalf of the Python development team, I'm happy to announce the first bugfix
release of the Python 3.1 series, Python 3.1.1.
This bug fix release fixes many normal bugs and several critical ones including
potential data corruption in the io library.
Python 3.1 focuses on the stabilization and
Scott David Daniels wrote:
No, I don't really need MT. The others would be fine.
I'd love further details.
The one I've been working with is due to Pierre L'Ecuyer [1]
and is known as MRG32k3a. It's a combined multiple recursive
linear congruential generator with 6 words of state. The
formula
Benjamin Peterson wrote:
Why do you need to set Py_TPFLAGS_HEAPTYPE on your C type?
I think he *doesn't* want to set Py_TPFLAGS_HEAPTYPE, but
does want to create the type dynamically.
But I suspect this is actually FUD, and that letting
Py_TPFLAGS_HEAPTYPE be set wouldn't lead to anything
dis
2009/8/16 Joshua Haberman :
> On Sun, Aug 16, 2009 at 3:37 PM, "Martin v. Löwis" wrote:
>>> So where does the Py_DECREF() for the above Py_INCREF() live? I
>>> expected to find this code snippet somewhere, but couldn't:
>>>
>>> if (type->tp_flags & Py_TPFLAGS_HEAPTYPE)
>>> Py_DECREF(type);
>
Jason R. Coombs wrote:
I had a use case that was compelling enough that I thought there
> should be something in functools to do what I wanted.
I think this is one of those things that a small minority of
people would use frequently, but everyone else would use
very rarely or never. The decisi
> PEP 309 was written, discussed, approved, and implemented - that's how
> partial ended up in the stdlib.
Ok, I'm surprised that a single addition to a module needed a PEP in
order to be approved.
Interestingly, here's what the summary section in PEP 309 says:
« A standard library module funct
On Sun, Aug 16, 2009 at 3:37 PM, "Martin v. Löwis" wrote:
>> So where does the Py_DECREF() for the above Py_INCREF() live? I
>> expected to find this code snippet somewhere, but couldn't:
>>
>> if (type->tp_flags & Py_TPFLAGS_HEAPTYPE)
>> Py_DECREF(type);
>
> For a regular heaptype, it's in
> So where does the Py_DECREF() for the above Py_INCREF() live? I
> expected to find this code snippet somewhere, but couldn't:
>
> if (type->tp_flags & Py_TPFLAGS_HEAPTYPE)
> Py_DECREF(type);
For a regular heaptype, it's in subtype_dealloc:
/* Can't reference self beyond
Martin v. Löwis wrote:
>> The reason I came across the old patch was because I was searching
>> for something that did exactly what compose does. That is to say, I
>> had a use case that was compelling enough that I thought there should
>> be something in functools to do what I wanted. I've encoun
I wrote to this list a few weeks ago asking about Py_TPFLAGS_HEAPTYPE
(http://thread.gmane.org/gmane.comp.python.devel/105648). It occurred
to me today that I could probably make object instances INCREF and
DECREF my type appropriately, without setting Py_TPFLAGS_HEAPTYPE, by
writing my own tp_all
> Then I wonder how partial() ended up in the stdlib.
PEP 309 was written, discussed, approved, and implemented - that's how
partial ended up in the stdlib. The feature itself might be debatable,
that's what we have the PEP process for.
> Either we decide it is useful to have a set of basic "fun
> The reason I came across the old patch was because I was searching
> for something that did exactly what compose does. That is to say, I
> had a use case that was compelling enough that I thought there should
> be something in functools to do what I wanted. I've encountered this
> pattern often
Raymond Hettinger rcn.com> writes:
>
> IMO, its only virtue is that people coming from functional languages
> are used to having compose. Otherwise, it's a YAGNI.
Then I wonder how partial() ended up in the stdlib. It seems hardly more
useful than compose().
Either we decide it is useful to hav
Raymond Hettinger wrote:
[Scott David Daniels]
I find I have a need in randomized testing for a shorter version
of getstate, even if it _is_ slower to restore. [blah about big state]
Sounds like you could easily wrap the generator to get this.
It would slow you down but would give the informa
> Raymond Hettinger wrote:
> Sent: Sunday, 16 August, 2009 12:42
>
> [Antoine Pitrou]
> > I also think it would be a nice addition.
> > (but someone has to propose a patch :-))
The patch was proposed and rejected here: http://bugs.python.org/issue1660179;
my reason for mentioning it here is bec
[Antoine Pitrou]
I also think it would be a nice addition.
(but someone has to propose a patch :-))
I agree with Martin's reasons for rejecting the feature request
(see the bug report for his full explanation). IIRC, the compose()
idea had come-up and been rejected in previous discussions as
Jason R. Coombs jaraco.com> writes:
>
> I'm certain there are other, more obscure examples, but I feel these two use
cases demonstrate some fairly
> common potential use cases for something like a composition function.
I also think it would be a nice addition.
(but someone has to propose a patch
Steven D'Aprano wrote:
> Sent: Sunday, 16 August, 2009 08:15
>
> On Sat, 15 Aug 2009 04:39:03 am Jason R. Coombs wrote:
>
> >
> > def meta_decorator(data):
> > return compose(dec_register_function_for_x, dec_alter_docstring,
> > dec_inject_some_data(data))
>
> Surely that's better written a
On Sun, Aug 16, 2009 at 11:45 AM, Benjamin Peterson wrote:
> 2009/8/16 Frank Wierzbicki :
> Usually, unless the test is for a bug we are backporting, new tests
> only go in the trunk and py3k.
Thanks! I'll do that from now on.
-Frank
___
Python-Dev maili
2009/8/16 Frank Wierzbicki :
> I plan on updating the Python unit tests with tests from Jython that
> turn out to be generic Python tests. Should I be putting these tests
> into trunk and 3k or should I also put them into the 2.6 and 3.1
> maintenance branches as well?
Great!
Usually, unless the
I plan on updating the Python unit tests with tests from Jython that
turn out to be generic Python tests. Should I be putting these tests
into trunk and 3k or should I also put them into the 2.6 and 3.1
maintenance branches as well?
Regards,
-Frank
___
On Sat, 15 Aug 2009 04:39:03 am Jason R. Coombs wrote:
> I'd like to express additional interest in python patch 1660179,
> discussed here:
>
> http://mail.python.org/pipermail/patches/2007-February/021687.html
[...]
> But to me, a compose function is much easier to read and much more
> consistent
Antoine Pitrou:
> After a fair amount of discussion on Rietveld, I think you should post another
> patch without the deprecations.
> (since the discussion was fairly long, I won't repeat here the reasons I gave
> unless someone asks me to )
> Besides, it would be nice to have the additional tests y
24 matches
Mail list logo
