Mailing List Archive

Christian Tismer wrote:
>
>
> Skip Montanaro wrote:

> > (Trying to read Fredrik's mind...)
>
> takes too long since it isn't countable infinite...

Bounded, however. And therefore, um, dense <duck>...


- Gordon

>>>>> "SM" == Skip Montanaro <skip@mojam.com> writes:

BAW> Functions and methods are first class objects, and they
BAW> already have attributes, some of which are writable.

SM> (Trying to read Fredrik's mind...)

SM> By extension, we should allow writable attributes to work for
SM> other objects. To pollute this discussion with an example
SM> from another one:

| i = 3.1416
| i.__precision__ = 4

SM> I haven't actually got anything against adding attributes to
SM> functions (or numbers, if it's appropriate). Just wondering
SM> out loud and playing a bit of a devil's advocate.

Python 1.6a2 (#26, Apr 12 2000, 13:53:57) [GCC 2.8.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> i = 3.1416
>>> dir(i)
[]

Floats don't currently have attributes.

-Barry

>>>>> "MZ" == Moshe Zadka <moshez@math.huji.ac.il> writes:

>> so? you can use methods as keys today, you know...

MZ> Actually, I didn't know. What hapens if you use a method as a
MZ> key, and then change it's doc string?

Nothing.

Python 1.5.2 (#7, Apr 16 1999, 18:24:22) [GCC 2.8.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> def foo():
... 'a doc string'
...
>>> d = {}
>>> d[foo] = foo
>>> foo.__doc__ = 'norwegian blue'
>>> d[foo].__doc__
'norwegian blue'

The hash of a function object is hash(func_code) ^ id(func_globals):

Python 1.6a2 (#26, Apr 12 2000, 13:53:57) [GCC 2.8.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> def foo(): pass
...
>>> hash(foo)
557536160
>>> hash(foo.func_code)
557215928
>>> id(foo.func_globals)
860952
>>> hash(foo.func_code) ^ id(foo.func_globals)
557536160

So in the words of Mr. Praline: The plumage don't enter into it. :)

But you can still get quite evil:

Python 1.6a2 (#26, Apr 12 2000, 13:53:57) [GCC 2.8.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> def foo(): pass
...
>>> def bar(): print 1
...
>>> d = {}
>>> d[foo] = foo
>>> d[foo]
<function foo at dee08>
>>> foo.func_code = bar.func_code
>>> d[foo]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: <function foo at dee08>


Mwah, ha, ha!

Gimme-lists-as-keys-and-who-really-/does/-need-tuples-after-all?-ly y'rs,
-Barry

>>>>> "JH" == Jeremy Hylton <jeremy@cnri.reston.va.us> writes:

JH> Fred and I were just talking, and he observed that a variant
JH> of Python that included a syntactic mechanism to specify more
JH> than one attribute (effectively, a multiple doc string syntax)
JH> might be less objectionable than setting arbitrary attributes
JH> at runtime. Neither of us could imagine just what that syntax
JH> would be.

So it's the writability of the attributes that bothers you? Maybe we
need WORM-attrs? :)

-Barry

BAW> Functions and methods are first class objects, and they already
BAW> have attributes, some of which are writable.

SM> I haven't actually got anything against adding attributes to
SM> functions (or numbers, if it's appropriate). Just wondering out
SM> loud and playing a bit of a devil's advocate.

BAW> Python 1.6a2 (#26, Apr 12 2000, 13:53:57) [GCC 2.8.1] on sunos5
BAW> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>> i = 3.1416
>>>> dir(i)
BAW> []

BAW> Floats don't currently have attributes.

True enough, but why can't they? I see no reason that your writable
function attributes proposal requires that functions already have
attributes. Modifying my example, how about:

>>> l = [1,2,3]
>>> l.__type__ = "int"

Like functions, lists do have (readonly) attributes. Why not allow them to
have writable attributes as well?

Awhile ago, Paul Prescod proposed something I think he called a super tuple,
which allowed you to address tuple elements using attribute names:

>>> t = ("x": 1, "y": 2, "z": 3)
>>> print t.x
1
>>> print t[1]
2

(or something like that). I'm sure Paul or others will chime in if they
think it's relevant.

Your observation was that functions have a __doc__ attribute that is being
abused in multiple, conflicting ways because it's the only function
attribute people have to play with. I have absolutely no quibble with that.
See:

http://www.python.org/pipermail/doc-sig/1999-December/001671.html

(Note that it apparently fell on completely deaf ears... ;-) I like your
proposal. I was just wondering out loud if it should be more general.

Skip

>>>>> "SM" == Skip Montanaro <skip@mojam.com> writes:

BAW> Floats don't currently have attributes.

SM> True enough, but why can't they?

Skip, didn't you realize I was setting you up to ask that question? :)

I don't necessarily think other objects shouldn't have such
attributes, but I thought it might be easier to shove this one tiny
little pill down peoples' throats first. Once they realize it tastes
good, /they'll/ want more :)

SM> Awhile ago, Paul Prescod proposed something I think he called
SM> a super tuple, which allowed you to address tuple elements
SM> using attribute names:

>> t = ("x": 1, "y": 2, "z": 3) print t.x
| 1
| >>> print t[1]
| 2

SM> (or something like that). I'm sure Paul or others will chime
SM> in if they think it's relevant.

Might be. I thought that was a cool idea too at the time.

SM> Your observation was that functions have a __doc__ attribute
SM> that is being abused in multiple, conflicting ways because
SM> it's the only function attribute people have to play with. I
SM> have absolutely no quibble with that. See:

SM>
SM> http://www.python.org/pipermail/doc-sig/1999-December/001671.html

SM> (Note that it apparently fell on completely deaf ears... ;-) I
SM> like your proposal. I was just wondering out loud if it
SM> should be more general.

Perhaps so.
-Barry

Barry A. Warsaw wrote:
> Finally, think of this proposal as an evolutionary step toward
> enabling all kinds of future frameworks. /.../ With the addition
> of func/meth attrs now, we can start to play with prototypes
> of this system, define conventions and standards /.../

does this mean that this feature will be labelled as "experimental"
(and hopefully even "interpreter specific").

if so, +0.

</F>

>>>>> "FL" == Fredrik Lundh <effbot@telia.com> writes:

FL> does this mean that this feature will be labelled as
FL> "experimental" (and hopefully even "interpreter specific").

Do you mean "don't add it to JPython whenever I actually get around to
making it compatible with CPython 1.6"?

-Barry

bwarsaw@cnri.reston.va.us wrote:
>
> >>>>> "JH" == Jeremy Hylton <jeremy@cnri.reston.va.us> writes:
>
> JH> Fred and I were just talking, and he observed that a variant
> JH> of Python that included a syntactic mechanism to specify more
> JH> than one attribute (effectively, a multiple doc string syntax)
> JH> might be less objectionable than setting arbitrary attributes
> JH> at runtime. Neither of us could imagine just what that syntax
> JH> would be.
>
> So it's the writability of the attributes that bothers you? Maybe we
> need WORM-attrs? :)

Why don't you just use WORM programming style.

Write it once (into the CVS) and get many complaints :-)

chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com

On Wed, 12 Apr 2000, Skip Montanaro wrote:
> BAW> Functions and methods are first class objects, and they already
> BAW> have attributes, some of which are writable.
>
> (Trying to read Fredrik's mind...)
>
> By extension, we should allow writable attributes to work for other objects.
> To pollute this discussion with an example from another one:
>
> i = 3.1416
> i.__precision__ = 4
>
> I haven't actually got anything against adding attributes to functions (or
> numbers, if it's appropriate). Just wondering out loud and playing a bit of
> a devil's advocate.

Numbers have no attributes right now.

Functions have mutable attributes (__doc__). Barry is allowing them to be
annotated (without crushing the values into __doc__ in some nasty way).

Paul gave some great examples. IMO, the Zope "visibility by use of
__doc__" is the worst kind of hack :-) "Let me be a good person and doc
all my functions. Oh, crap! Somebody hacked my system!" And the COM thing
was great. Here is what we do today:

class MyCOMServer:
_public_methods_ = ['Hello']

def private_method(self, args):
...

def Hello(self, args)
...

The _public_methods_ thing is hacky. I'd rather see a "Hello.public = 1"
in there.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

On Wed, 12 Apr 2000, Skip Montanaro wrote:
>...
> BAW> Floats don't currently have attributes.
>
> True enough, but why can't they? I see no reason that your writable
> function attributes proposal requires that functions already have
> attributes. Modifying my example, how about:
>
> >>> l = [1,2,3]
> >>> l.__type__ = "int"
>
> Like functions, lists do have (readonly) attributes. Why not allow them to
> have writable attributes as well?

Lists, floats, etc are *data*. There is plenty of opportunity for creating
data structures that contain whatever you want, organized in any fashion.

Functions are (typically) not data. Applying these attributes is a way to
define program semantics, not record data.

There are two entirely separate worlds here. Adding attributes makes great
sense, as a way to enhance the definition of your program's semantics and
operation.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

On Wed, 12 Apr 2000, Jeremy Hylton wrote:
>...
> It would look really, really bad ;-). I couldn't think of a good
> example, so I guess this is a FUD argument. A rough sketch, though,
> would be a program that assigned attribute X to all functions that
> were to be used in a certain way. If the assignment is a runtime
> operation, rather than a syntactic construct that defines a static
> attribute, it would be possible to accidentally assign attribute X to
> a function that was not intended to be used that way. This connection
> between a group of functions and a particular behavior would depend
> entirely on some runtime magic with settable attributes.

This is a FUD argument also. I could just as easily mis-label a function
when using __doc__ strings, when using mappings in a class object, or
using some runtime structures to record the attribute.

Your "label" can be recorded in any number of ways. It can be made
incorrect in all of them. There is nothing intrinsic to function
attributes that makes them more prone to error.

Being able to place them into function attributes means that you have a
better *model* for how you record these values. Why place them into a
separate mapping if your intent is to enhance the semantics of a function?
If the semantics apply to a function, then bind it right there.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Greg Stein wrote:
...
> Being able to place them into function attributes means that you have a
> better *model* for how you record these values. Why place them into a
> separate mapping if your intent is to enhance the semantics of a function?
> If the semantics apply to a function, then bind it right there.

BTW., is then there also a way for the function *itself*
so look into its attributes? If it should be able to take
special care about its attributes, it would be not nice
if it had to know its own name for that?
Some self-like surrogate?

ciao - chris

--
Christian Tismer :^) <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com

me> >>> l = [1,2,3]
me> >>> l.__type__ = "int"

Greg> Lists, floats, etc are *data*. There is plenty of opportunity for
Greg> creating data structures that contain whatever you want, organized
Greg> in any fashion.

Yeah, but there's no reason you wouldn't want to reason about them. They
are, after all, first-class objects. If you consider these other attributes
as meta-data, allowing data attributes to hang off lists, tuples, ints or
regex objects makes perfect sense to me. I believe someone else during this
thread suggested that one use of function attributes might be to record the
function's return type. My example above is not really any different.
Simpleminded, yes. Part of the value of l, no.

Skip

Gordon McMillan:

> Jeremy Hylton wrote:

> > It prevents confusion and errors
> > that might result from unprincipled use of function attributes.
>
> While I'm sure I will be properly shocked and horrified when
> you come up with an example, in my naivety, I can't imagine
> what it will look like ;-).

I'm w/ Gordon & Barry on this one. I've wanted method and function
attributes in the past and had to rely on building completely new classes w/
__call__ methods just to 'fake it'. There's a performance cost to having to
do that, but most importantly there's a big increase in code complexity,
readability, maintanability, yaddability, etc.

I'm surprised that Jeremy sees it as such a problem area -- if I wanted to
play around with static typing, having a version of Python which let me
store method metadata cleanly would make me jump with joy.

FWIW, I'm perfectly willing to live in a world where 'unprincipled use of
method and function attributes' means that my code can't get optimized, just
like I don't expect my code which modifies __class__ to get optimized (as
long as someone defines what those principles are!).

--david

On Wed, 12 Apr 2000, Christian Tismer wrote:
> Greg Stein wrote:
> ...
> > Being able to place them into function attributes means that you have a
> > better *model* for how you record these values. Why place them into a
> > separate mapping if your intent is to enhance the semantics of a function?
> > If the semantics apply to a function, then bind it right there.
>
> BTW., is then there also a way for the function *itself*
> so look into its attributes? If it should be able to take
> special care about its attributes, it would be not nice
> if it had to know its own name for that?
> Some self-like surrogate?

Separate problem. Functions can't do that today with their own __doc__
attribute.

Feel free to solve this issue, but it is distinct from the
attributes-on-functions issue being discussed.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Lisp systems for 40+ years traditionally supported user-muckable "property
lists" on all symbols, which were basically arbitrary dicts w/ a clumsy
syntax. No disaster ensued; to the contrary, it was often handy.

So +0 from me on the add-attrs-to-funcs idea. The same idea applies to all
objects, of course, but attrs-on-funcs has some bang for the buck (adding a
dict to e.g. each int object would be a real new burden with little
payback).

-1 on any notion of restricting attr values to be immutable.

[Gordon]
> Having to be explicit about the method <-> regex / rule would
> severely damage SPARK's elegance.

That's why I'm only +0 instead of +1: SPARK won't switch to use the new
method anyway, because the beauty of abusing docstrings is that it's
syntactically *obvious*. There already exist any number of other ways to
associate arbitrary info with arbitrary objects, and it's no mystery why
SPARK and Zope avoided all of them in favor of docstring abuse.

> It would make Tim's doctest useless.

This one not so: doctest is *not* meant to warp docstrings toward testing
purposes; it's intended that docstrings remain wholly for human-friendly
documentation. What doctest does is give you a way to guarantee that the
elucidating examples good docstrings *should have anyway* work exactly as
advertised (btw, doctest examples found dozens of places in my modules that
needed to be fixed to recover from 1.6 alpha no longer sticking a trailing
"L" on str(long) -- if you're not using doctest every day, you're an idiot
<wink>).

If I could add an attr to funcs, though, *then* I'd think about changing
doctest to also run examples in any e.g. func.doctest attrs it could find,
and that *new* mechanism would be warped toward testing purposes. Indeed, I
think that would be an excellent use for the new facility.

namespaces-are-one-honking-great-etc-ly y'rs - tim