Parachuting into a random point in the thread...
Does this have any real bearing on 2.2.1? Should pymalloc have a mild
warning sticker applied to it for this release? Or is this just
another possible-to-exploit but basically impossible to run into by
accident hole in Python?
You'll excuse me if I don't want to backport recent pymalloc changes
to release22-maint...
Cheers,
M.
--
The gripping hand is really that there are morons everywhere, it's
just that the Americon morons are funnier than average.
-- Pim van Riezen, alt.sysadmin.recovery
Guido van Rossum <guido(a)python.org> writes:
> > On 30 Mar 2002, Michael Hudson wrote:
> > > Kevin Jacobs <jacobs(a)penguin.theopalgroup.com> writes:
> > > > Suppose I define:
> > > >
> > > > class Foo(object):
> > > > def __new__(cls):
> > > > return 1
> > > >
> > > > class Bar(object):
> > > > def __new__(cls):
> > > > return [1,2,3]
> > > >
> > > > Python 2.2 returns:
> > > > print Foo()
> > > > > 1
> > > > print Bar()
> > > > > []
> > > >
> > > > I would expect that Bar() should return [1,2,3]. Am I running into
> > > > some clever undocumented feature or a bug?
> > >
> > > Is tp_init being called on the returned list?
>
> Correct.
Goody. I always like it when my wild guesses turn out to be accurate :)
[...]
> Correct behavior is not to return a different type unless you know
> what its __init__ does.
>>> d = {1:1}
>>> d.__init__()
>>> d
{1: 1}
>>> l = [1]
>>> l.__init__()
>>> l
[]
This is at least a little odd, I'd have said. Is this just a fluke of
implementation?
It's not like I really care, though.
Cheers,
M.
--
In the 1950s and 60s there was a regular brain drain of young
Australians from the cities to London, but it was because of
money, culture and opportunity, not spiders.
-- Al Grant, ucam.chat, from Owen Dunn's review of the year
Kevin Jacobs <jacobs(a)penguin.theopalgroup.com> writes:
> Suppose I define:
>
> class Foo(object):
> def __new__(cls):
> return 1
>
> class Bar(object):
> def __new__(cls):
> return [1,2,3]
>
> Python 2.2 returns:
> print Foo()
> > 1
> print Bar()
> > []
>
> I would expect that Bar() should return [1,2,3]. Am I running into some
> clever undocumented feature or a bug?
Is tp_init being called on the returned list?
Cheers,
M.
--
But since I'm not trying to impress anybody in The Software Big
Top, I'd rather walk the wire using a big pole, a safety harness,
a net, and with the wire not more than 3 feet off the ground.
-- Grant Griffin, comp.lang.python
Suppose I define:
class Foo(object):
def __new__(cls):
return 1
class Bar(object):
def __new__(cls):
return [1,2,3]
Python 2.2 returns:
print Foo()
> 1
print Bar()
> []
I would expect that Bar() should return [1,2,3]. Am I running into some
clever undocumented feature or a bug?
Thanks,
-Kevin
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs(a)theopalgroup.com
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
Get a beautiful, 100%
Custom Web site
or redesign your
existing site.
Only $399!*
Call now and schedule a walk through
with a Web design specialist.
404-806-6124
Includes up to 7 pages (you can add more), plus a Guestbook and a Bulletin
Board. Java rollover buttons, Feedback forms, Pushbutton E-Commerce
Activation and more. It will be constructed to your taste and specifications in only
five days. We do not use templates, our sites are completely custom.
*Must host with us for $15.96 a month. You get: 200 Megs, 100 E-mail accounts,
Control Panel, Front Page, Graphical Statistics, more!
Act now and get one FREE .com domain name!
To discuss your Web site, call 404-806-6124
and schedule a call back now.
typeobject.c:PyType_GenericAlloc has this:
if (type->tp_flags & Py_TPFLAGS_HEAPTYPE)
Py_INCREF(type);
Where is the corresponding DECREF?
Regards,
Martin
The development version of the documentation has been updated:
http://python.sourceforge.net/devel-docs/
Started to update the Extending & Embedding manual with information on the
new support for types.
There's still a long way to go -- contributions welcome!
A long time ago I wrote to Guido suggesting that I might like to submit
some patches to improve the comprehensibility of the Python source. He
was receptive, so my first one is attached (I will also post to the SF
patch manager). I did this in an effort to stop replicating the effort
of understanding how the new descriptor mechanism works on types. I'm
also testing the waters a bit, here: I hope it looks like an improvement
to people, but please let me know if it does not.
Regards,
Dave
--- typeobject.c Mon Dec 17 12:14:22 2001
+++ typeobject.c.new Thu Mar 28 13:46:03 2002
@@ -1186,8 +1186,8 @@
type_getattro(PyTypeObject *type, PyObject *name)
{
PyTypeObject *metatype = type->ob_type;
- PyObject *descr, *res;
- descrgetfunc f;
+ PyObject *meta_attribute, *attribute;
+ descrgetfunc meta_get;
/* Initialize this type (we'll assume the metatype is initialized) */
if (type->tp_dict == NULL) {
@@ -1195,34 +1195,50 @@
return NULL;
}
- /* Get a descriptor from the metatype */
- descr = _PyType_Lookup(metatype, name);
- f = NULL;
- if (descr != NULL) {
- f = descr->ob_type->tp_descr_get;
- if (f != NULL && PyDescr_IsData(descr))
- return f(descr,
- (PyObject *)type, (PyObject *)metatype);
- }
+ /* No readable descriptor found yet */
+ meta_get = NULL;
+
+ /* Look for the attribute in the metatype */
+ meta_attribute = _PyType_Lookup(metatype, name);
- /* Look in tp_dict of this type and its bases */
- res = _PyType_Lookup(type, name);
- if (res != NULL) {
- f = res->ob_type->tp_descr_get;
- if (f != NULL)
- return f(res, (PyObject *)NULL, (PyObject *)type);
- Py_INCREF(res);
- return res;
+ if (meta_attribute != NULL) {
+ meta_get = meta_attribute->ob_type->tp_descr_get;
+
+ if (meta_get != NULL && PyDescr_IsData(meta_attribute)) {
+ /* Data descriptors implement tp_descr_set to intercept
+ * writes. Assume the attribute is not overridden in
+ * type's tp_dict (and bases): call the descriptor now.
+ */
+ return meta_get(meta_attribute,
+ (PyObject *)type, (PyObject *)metatype);
+ }
}
- /* Use the descriptor from the metatype */
- if (f != NULL) {
- res = f(descr, (PyObject *)type, (PyObject *)metatype);
- return res;
+ /* No data descriptor found on metatype. Look in tp_dict of this
+ * type and its bases */
+ attribute = _PyType_Lookup(type, name);
+ if (attribute != NULL) {
+ /* Implement descriptor functionality, if any */
+ descrgetfunc local_get = attribute->ob_type->tp_descr_get;
+ if (local_get != NULL) {
+ /* NULL 2nd argument indicates the descriptor was found on
+ * the target object itself (or a base) */
+ return local_get(attribute, (PyObject *)NULL, (PyObject *)type);
+ }
+
+ Py_INCREF(attribute);
+ return attribute;
}
- if (descr != NULL) {
- Py_INCREF(descr);
- return descr;
+
+ /* No attribute found in local __dict__ (or bases): use the
+ * descriptor from the metatype, if any */
+ if (meta_get != NULL)
+ return meta_get(meta_attribute, (PyObject *)type, (PyObject
*)metatype);
+
+ /* If an ordinary attribute was found on the metatype, return it
now. */
+ if (meta_attribute != NULL) {
+ Py_INCREF(meta_attribute);
+ return meta_attribute;
}
/* Give up */
+---------------------------------------------------------------+
David Abrahams
C++ Booster (http://www.boost.org) O__ ==
Pythonista (http://www.python.org) c/ /'_ ==
resume: http://users.rcn.com/abrahams/resume.html (*) \(*) ==
email: david.abrahams(a)rcn.com
+---------------------------------------------------------------+
It appears the following were missing
#ifdef __cplusplus
extern "C" {
#endif
some were also missing #include guards; I didn't check all headers for
missing #include guards, just the ones without extern "C" support.
CStringIO.h
descrobject.h
iterobject.h
I uploaded a patch to address the problem.
+---------------------------------------------------------------+
David Abrahams
C++ Booster (http://www.boost.org) O__ ==
Pythonista (http://www.python.org) c/ /'_ ==
resume: http://users.rcn.com/abrahams/resume.html (*) \(*) ==
email: david.abrahams(a)rcn.com
+---------------------------------------------------------------+
