date:20110627


On 27/06/2011 09:24, Antoine Pitrou wrote:

Le Mon, 27 Jun 2011 11:32:32 +1000,
Nick Coghlan  a écrit :


On Mon, Jun 27, 2011 at 7:52 AM, Terry Reedy  wrote:

or the 'attribute' substitution everywhere makes sense?

No.

My strong history-based opinions ;-).

+1 to what Terry said.

"Members" is a historical relic that is best replaced by "attributes"
or "data attributes" if we want to explicitly exclude methods for some
reason. "Methods" is a subset of attributes that explicitly excludes
data attributes.

While I know it is technically right, I find it a bit strange to refer to
methods as "attributes". We're describing an API, not the inner working of
the object model. Also, people just discovering Python will probably be a
bit surprised if we start refer to methods as "attributes".

FWIW, I tend to understand "members" as "methods + attributes", which makes
it a nice term to use for that purpose.


That is my understanding / use of the terms as well.

Michael


Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Oleg Broytman

On Mon, Jun 27, 2011 at 10:24:28AM +0200, Antoine Pitrou wrote:
> FWIW, I tend to understand "members" as "methods + attributes", which makes
> it a nice term to use for that purpose.

   That's my feeling too.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Patching builtin_id to allow for C proxy objects?

2011-06-27 Thread Tom Whittock

Hi all.

I'm writing a module to proxy C++ objects into Python for a large C++
application. There are hundreds of thousands of C++ objects, some of
which are temporary while others are very long lived.

Currently every time one of these objects is accessed from Python, a
new "myproxy" instance is created. So if I were to access the same
field of an object twice, I would receive two python objects proxying
the same underlying C++ object. This messes up "id" and "is", and is
causing me issues when, for example, I run into circular references
when enoding json or otherwise attempt to determine whether two proxy
objects refer to the same C++ object.

I can't see how to cache the "myproxy" objects instead of returning
new instances - due to the architecture of the C++ application,
there's no weak reference support at all, and the number of objects is
very large.

My current plan would be for me to override the id builtin to return
the underlying C++ object instance pointer instead of the PyObject
instance pointer in the case of the "myproxy" object type, probably
using a new type method slot tp_id or similar. The old behaviour would
be unchanged for all other types, naturally. I'd also need to alter
ceval.c to use builtin_id instead of the raw pointer for comparison
when using PyCmp_IS and PyCmp_IS_NOT. I can see that there could very
well be many other sites throughout the C source where the pointer was
directly compared, and would cause interesting issues for me down the
line. I'm just not sure what else to try.

I'd like to know if I'm being laughably naive or not before I went
about this plan, and whether it'd be worthwhile contributing the patch
back, considering the number of potentially overridden-id-unaware
areas throught the rest of the python source base.

Thanks.
Tom.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patching builtin_id to allow for C proxy objects?

2011-06-27 Thread Stefan Behnel


Tom Whittock, 27.06.2011 12:48:

I'm writing a module to proxy C++ objects into Python for a large C++
application. There are hundreds of thousands of C++ objects, some of
which are temporary while others are very long lived.

Currently every time one of these objects is accessed from Python, a
new "myproxy" instance is created. So if I were to access the same
field of an object twice, I would receive two python objects proxying
the same underlying C++ object. This messes up "id" and "is"


Note that "is" actually compares the addresses, not the id().



and is
causing me issues when, for example, I run into circular references
when enoding json or otherwise attempt to determine whether two proxy
objects refer to the same C++ object.

I can't see how to cache the "myproxy" objects instead of returning
new instances - due to the architecture of the C++ application,
there's no weak reference support at all, and the number of objects is
very large.

My current plan would be for me to override the id builtin to return
the underlying C++ object instance pointer instead of the PyObject
instance pointer in the case of the "myproxy" object type


Where would you get the proxy object from anyway?

IMHO, there are two obvious way get what you want: map the C++ object 
address (integer!) to a proxy object using a dict, or use a backpointer 
from the C++ object to its proxy. The second is substantially faster, but 
may require changes to the C++ class struct.


I don't see how changes to CPython's core can help you here.

Stefan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patching builtin_id to allow for C proxy objects?

2011-06-27 Thread Greg Ewing


Tom Whittock wrote:


Currently every time one of these objects is accessed from Python, a
new "myproxy" instance is created. So if I were to access the same
field of an object twice, I would receive two python objects proxying
the same underlying C++ object.


Perhaps you could use a WeakValueDictionary to keep a mapping
from a C++ object address to its Python proxy. Then as long as
a proxy object is alive, accessing the same C++ object again
will get you the same proxy object. When there are no longer
any references to the proxy object from Python, it will go
away. The next time you access that C++ object you'll get a
new proxy, but that won't matter, because the original proxy
is no longer around to compare it with.

This depends on there being some way for the proxy object
to ensure that the C++ object remains alive as long as it
does.

It also won't solve the problem of keeping the id of the
proxy for longer than the proxy exists, but that's probably
not something you should be relying on anyway. The id of
*any* Python object is only valid while the object lives,
and if it's still alive you have a real reference somewhere
that you can use instead of the id for identity testing.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patching builtin_id to allow for C proxy objects?

2011-06-27 Thread Tom Whittock

Hi Greg thanks for your quick reply.

> Perhaps you could use a WeakValueDictionary to keep a mapping
> from a C++ object address to its Python proxy.

Thank you, I'll implement this and see whether it works out. I'll
certainly be better off if it does. I was avoiding holding weak
references due to perhaps unfounded concerns about increasing the
lifetime and speed/memory impact of certain temporary objects which
are created at very high frequency. I'll test it and see before diving
into messing with id. But now I'm thinking about it again, I can see a
plan for not needing to affect that pathway at all.

Seems I fell into the trap of making things too complicated for myself.

> It also won't solve the problem of keeping the id of the
> proxy for longer than the proxy exists, but that's probably
> not something you should be relying on anyway. The id of
> *any* Python object is only valid while the object lives,
> and if it's still alive you have a real reference somewhere
> that you can use instead of the id for identity testing.

Thanks, yes. I'm actually kind of concerned about the usage of id in
the markers set which the json library uses for circular referencing
checks for exactly this reason. It seems to assume that the objects
lifetime lasts for the duration of the encoding operation. I have no
idea if that's actually the case in my situation, where data members
are property getters producing probably very short lived proxies
generated from C++. I guess I'll find out :)

Thanks again,
Tom.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patching builtin_id to allow for C proxy objects?

2011-06-27 Thread Tom Whittock

Hi again.

Just to let you know that Greg's suggestion worked beautifully - I
guess my id idea was just me trying to make life hard for myself.

My concerns over the json modules usage of id seem unjustified, as
circular references are detected now that the weak reference
dictionary is in place.

Thanks for your help, and sorry for bothering dev with something which
was a regular python programming issue after all.

Tom.

On 27 June 2011 13:31, Tom Whittock  wrote:
> Hi Greg thanks for your quick reply.
>
>> Perhaps you could use a WeakValueDictionary to keep a mapping
>> from a C++ object address to its Python proxy.
>
> Thank you, I'll implement this and see whether it works out. I'll
> certainly be better off if it does. I was avoiding holding weak
> references due to perhaps unfounded concerns about increasing the
> lifetime and speed/memory impact of certain temporary objects which
> are created at very high frequency. I'll test it and see before diving
> into messing with id. But now I'm thinking about it again, I can see a
> plan for not needing to affect that pathway at all.
>
> Seems I fell into the trap of making things too complicated for myself.
>
>> It also won't solve the problem of keeping the id of the
>> proxy for longer than the proxy exists, but that's probably
>> not something you should be relying on anyway. The id of
>> *any* Python object is only valid while the object lives,
>> and if it's still alive you have a real reference somewhere
>> that you can use instead of the id for identity testing.
>
> Thanks, yes. I'm actually kind of concerned about the usage of id in
> the markers set which the json library uses for circular referencing
> checks for exactly this reason. It seems to assume that the objects
> lifetime lasts for the duration of the encoding operation. I have no
> idea if that's actually the case in my situation, where data members
> are property getters producing probably very short lived proxies
> generated from C++. I guess I'll find out :)
>
> Thanks again,
> Tom.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Mon, 27 Jun 2011 09:47:05 +0100, Paul Moore  wrote:
> On 27 June 2011 09:24, Antoine Pitrou  wrote:
> > While I know it is technically right, I find it a bit strange to refer to
> > methods as "attributes". We're describing an API, not the inner working of
> > the object model. Also, people just discovering Python will probably be a
> > bit surprised if we start refer to methods as "attributes".
> 
> +1
> 
> > FWIW, I tend to understand "members" as "methods + attributes", which makes
> > it a nice term to use for that purpose.
> 
> +1

Wow, all these people who like 'members', and I can't think of ever
using that term in a Python context.

While I agree that using 'attribute' when only methods are being discussed
would most likely be confusing, and that it can be tricky to clearly
word things when both are being discussed, the existence in the language
of getattr, setattr, and related methods argues against using the term
'members'.

'data attributes' can so easily become something else in Python...it
seems to me that the only real difference between 'data attributes' and
'method attributes' in Python is that the latter can be called and the
former can't.  But even that is not an accurate distinction, since a
'data attribute' could, in fact, return a callable.

I guess what I'm saying is that I am more comfortable calling them
all attributes than calling them all members.  The term 'members'
isn't used anywhere in the language itself, as far as I can recall,
whereas getattr and setattr are evidence that the language considers
them all attributes.  I think we do the documentation readers a
disservice by obscuring that fact by using other terminology.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Rob Cliffe


On 27/06/2011 15:08, R. David Murray wrote:

Wow, all these people who like 'members', and I can't think of ever
using that term in a Python context.

While I agree that using 'attribute' when only methods are being discussed
would most likely be confusing, and that it can be tricky to clearly
word things when both are being discussed, the existence in the language
of getattr, setattr, and related methods argues against using the term
'members'.

'data attributes' can so easily become something else in Python...it
seems to me that the only real difference between 'data attributes' and
'method attributes' in Python is that the latter can be called and the
former can't.  But even that is not an accurate distinction, since a
'data attribute' could, in fact, return a callable.

I guess what I'm saying is that I am more comfortable calling them
all attributes than calling them all members.  The term 'members'
isn't used anywhere in the language itself, as far as I can recall,
whereas getattr and setattr are evidence that the language considers
them all attributes.  I think we do the documentation readers a
disservice by obscuring that fact by using other terminology.


+1.

'function attributes' ?  'def attributes' ?  Or just stick with 'method 
attributes' ?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation


On 27/06/2011 15:08, R. David Murray wrote:

On Mon, 27 Jun 2011 09:47:05 +0100, Paul Moore  wrote:

On 27 June 2011 09:24, Antoine Pitrou  wrote:

While I know it is technically right, I find it a bit strange to refer to
methods as "attributes". We're describing an API, not the inner working of
the object model. Also, people just discovering Python will probably be a
bit surprised if we start refer to methods as "attributes".

+1


FWIW, I tend to understand "members" as "methods + attributes", which makes
it a nice term to use for that purpose.

+1

Wow, all these people who like 'members', and I can't think of ever
using that term in a Python context.

While I agree that using 'attribute' when only methods are being discussed
would most likely be confusing, and that it can be tricky to clearly
word things when both are being discussed, the existence in the language
of getattr, setattr, and related methods argues against using the term
'members'.

'data attributes' can so easily become something else in Python...it
seems to me that the only real difference between 'data attributes' and
'method attributes' in Python is that the latter can be called and the
former can't.  But even that is not an accurate distinction, since a
'data attribute' could, in fact, return a callable.

I guess what I'm saying is that I am more comfortable calling them
all attributes than calling them all members.  The term 'members'
isn't used anywhere in the language itself, as far as I can recall,
whereas getattr and setattr are evidence that the language considers
them all attributes.  I think we do the documentation readers a
disservice by obscuring that fact by using other terminology.



Well perhaps, but where does the language draw the distinction between 
attributes and "data attributes" as you all them (a term entirely new to 
me)? Only in the descriptor protocol and that term isn't used there 
(data-descriptors and non data-descriptors is terminology used in the 
documentation there).


If you're saying that data attributes isn't clear either (I couldn't 
quite tell from your email) then how *do* we draw a distinction. We 
could talk about instance attributes, non-descriptor class attributes 
and descriptors, but that terminology requires a reasonably advanced 
understanding of the Python data model.


I don't think that "all members, made up of attributes plus methods" is 
hard to understand. That's a great benefit. The fact that you can 
technically treat methods as attributes too is a minor detail.


All the best,

Michael Foord


--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Tue, Jun 28, 2011 at 12:08 AM, R. David Murray  wrote:
> While I agree that using 'attribute' when only methods are being discussed
> would most likely be confusing, and that it can be tricky to clearly
> word things when both are being discussed, the existence in the language
> of getattr, setattr, and related methods argues against using the term
> 'members'.

Yep, to me "attribute" just means "something that can be accessed
using attribute notation". What it actually *is* is completely up for
grabs at that point.

> 'data attributes' can so easily become something else in Python...it
> seems to me that the only real difference between 'data attributes' and
> 'method attributes' in Python is that the latter can be called and the
> former can't.  But even that is not an accurate distinction, since a
> 'data attribute' could, in fact, return a callable.
>
> I guess what I'm saying is that I am more comfortable calling them
> all attributes than calling them all members.  The term 'members'
> isn't used anywhere in the language itself, as far as I can recall,
> whereas getattr and setattr are evidence that the language considers
> them all attributes.  I think we do the documentation readers a
> disservice by obscuring that fact by using other terminology.

It's worse than that - the specific meaning of "members" in the
context of Python's history specifically *excludes* methods.

The superset is "attributes" - as noted, the names of the builtins and
magic methods make that terminology quite explicit.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Tue, Jun 28, 2011 at 12:27 AM, Michael Foord
 wrote:
> Well perhaps, but where does the language draw the distinction between
> attributes and "data attributes" as you all them (a term entirely new to
> me)? Only in the descriptor protocol and that term isn't used there
> (data-descriptors and non data-descriptors is terminology used in the
> documentation there).
>
> If you're saying that data attributes isn't clear either (I couldn't quite
> tell from your email) then how *do* we draw a distinction. We could talk
> about instance attributes, non-descriptor class attributes and descriptors,
> but that terminology requires a reasonably advanced understanding of the
> Python data model.
>
> I don't think that "all members, made up of attributes plus methods" is hard
> to understand. That's a great benefit. The fact that you can technically
> treat methods as attributes too is a minor detail.

It has almost no precedent in the Python context and what precedent it
does have is wrong (since it excluded methods).

And no, the fact that methods can be treated as attributes is not a
minor detail. It is *fundamental* to Python's object model that
*methods are not a special case of attribute access*. All attributes
work the same way, it is just the way functions implement the
descriptor protocol that makes instance methods behave the way they
do.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Happy Tau Day folks! :)

2011-06-27 Thread Benjamin Peterson

2011/6/27 nick.coghlan :
> http://hg.python.org/peps/rev/1e3d663c67ee
> changeset:   3892:1e3d663c67ee
> user:        Nick Coghlan 
> date:        Tue Jun 28 00:23:57 2011 +1000
> summary:
>  Happy Tau Day folks! :)
>
> files:
>  pep-0628.html |  149 ++

You're not going to give us the source?



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Happy Tau Day folks! :)

On Tue, Jun 28, 2011 at 12:38 AM, Benjamin Peterson  wrote:
> You're not going to give us the source?

Just a teensy error with hg add, tab completion and not checking the
diff before committing. Fixed now, though :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 380 acceptance (was Re: EuroPython Language Summit report)

2011-06-27 Thread renaud

Nick Coghlan  gmail.com> writes:

> I hit a snag with this. The real tests of the PEP 380 functionality
> aren't currently part of the patch - they're a big set of "golden
> output" tests in the zipfile hosted on Greg's site. Those need to be
> refactored into proper unittest or doctest based additions to the test
> suite and incorporated into the patch before I could commit this with
> a clear conscience. 

let me know if i can help.

> Renaud's patch mostly applies cleanly at the moment - the only change
> is that the "#endif" for the Py_LIMITED_API check needs to be moved in
> pyerrors.h so it also covers the new StopIteration struct definition.

if this helps, i've updated the patch to fix this.
https://bitbucket.org/rndblnch/cpython-pep380/changeset/6014d1720625

renaud


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Stephen J. Turnbull

Nick Coghlan writes:

 > And no, the fact that methods can be treated as attributes is not a
 > minor detail. It is *fundamental* to Python's object model that
 > *methods are not a special case of attribute access*.

That's ambiguous.  I assume you mean "just a case of attribute access,
and not special in any way"?

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

Nick Coghlan  wrote:

> And no, the fact that methods can be treated as attributes is not a
> minor detail. It is *fundamental* to Python's object model that
> *methods are not a special case of attribute access*. All attributes
> work the same way, it is just the way functions implement the
> descriptor protocol that makes instance methods behave the way they
> do.

Well put, Nick.  This paragraph is a good thing to read a couple of
times.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Mon, 27 Jun 2011 15:27:12 +0100, Michael Foord  
wrote:
> On 27/06/2011 15:08, R. David Murray wrote:
> > 'data attributes' can so easily become something else in Python...it
> > seems to me that the only real difference between 'data attributes' and
> > 'method attributes' in Python is that the latter can be called and the
> > former can't.  But even that is not an accurate distinction, since a
> > 'data attribute' could, in fact, return a callable.
> >
> > I guess what I'm saying is that I am more comfortable calling them
> > all attributes than calling them all members.  The term 'members'
> > isn't used anywhere in the language itself, as far as I can recall,
> > whereas getattr and setattr are evidence that the language considers
> > them all attributes.  I think we do the documentation readers a
> > disservice by obscuring that fact by using other terminology.
> 
> Well perhaps, but where does the language draw the distinction between 
> attributes and "data attributes" as you all them (a term entirely new to 

It doesn't, that's the point.  You'll note I put "data attributes"
in quotes :)

> me)? Only in the descriptor protocol and that term isn't used there 
> (data-descriptors and non data-descriptors is terminology used in the 
> documentation there).
> 
> If you're saying that data attributes isn't clear either (I couldn't 
> quite tell from your email) then how *do* we draw a distinction. We 
> could talk about instance attributes, non-descriptor class attributes 
> and descriptors, but that terminology requires a reasonably advanced 
> understanding of the Python data model.

That's why I said it could be difficult to find good wording when
discussing both methods and "other things".  Most people have a pretty
clear idea of what methods are, but the non-method stuff in Python does
not have any simple description that is also accurate.  Maybe 'non-method
attribute' is as close as we can get?

> I don't think that "all members, made up of attributes plus methods" is 
> hard to understand. That's a great benefit. The fact that you can 
> technically treat methods as attributes too is a minor detail.

Well, I would find that very hard to understand, since methods are
attributes, and as Nick said that is *fundamental* to the language,
not a minor detail.

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Snow Leopard buildbot failing again...

I see that parc-snowleopard-1 went down again.  I've done a software
update, rebooted, and installed the latest buildslave, 0.8.4.  I can
ping dinsdale.python.org successfully from the machine.  However, when I
start the buildslave, I get this:

$ buildslave start ~/buildarea/
/Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/internet/_sslverify.py:5:
 DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import itertools, md5
Following twistd.log until startup finished..
/Library/Python/2.6/site-packages/buildbot_slave-0.8.4-py2.6.egg/buildslave/scripts/logwatcher.py:67:
 PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not 
installed. This probably means you have not yet called reactor.run, or called 
reactor.run(installSignalHandler=0). You will probably never see this process 
finish, and it may become a zombie process.
  env=os.environ,
/Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/persisted/sob.py:12:
 DeprecationWarning: the md5 module is deprecated; use hashlib instead
  import os, md5, sys
/Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/python/filepath.py:12:
 DeprecationWarning: the sha module is deprecated; use the hashlib module 
instead
  import sha
2011-06-27 09:45:31-0700 [-] Log opened.
2011-06-27 09:45:31-0700 [-] twistd 8.2.0 (/usr/bin/python 2.6.1) starting up.
2011-06-27 09:45:31-0700 [-] reactor class: 
twisted.internet.selectreactor.SelectReactor.
2011-06-27 09:45:31-0700 [-] Starting BuildSlave -- version: 0.8.4
2011-06-27 09:45:31-0700 [-] recording hostname in twistd.hostname

The buildslave took more than 10 seconds to start, so we were unable to
confirm that it started correctly. Please 'tail twistd.log' and look for a
line that says 'configuration update complete' to verify correct startup.

$

Now, I thought of updating Twisted, but the Twisted downloads page says,

``Twisted is no longer making a .dmg for OS X because OS X versions 10.5
and greater ship with Twisted installed and the default Python path
configuration makes it impossible for a user to upgrade Twisted without
possibly breaking applications which depend on the system Twisted
installation.''

Anyone know just what those applications are?  All this machine is doing
is running the Python buildbot.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Fred Drake

Egads.

Back when I wrote

"Members and methods" should just be "attributes".

I used quotes to specifically indicate that this applied to the phrase
"members and methods", not their separate use.  I guess I wasn't obvious
enough.

The general & Python-historical uses of "members" is unfortunate.

My current position on this is that we should avoid the use of "members",
because either use will confuse a large set of readers.

As Nick points out, these are all attributes, regardless of their
implementation or type of the value.  "Methods" is a convenient and widely
understood term to refer to a general class of attributes, when that actually
matches the meaning.

For non-method or not-necessarily-a-method attributes, I'm inclined to just
stick with calling them attributes at this point.

Even more important, we need to decide what to call them, and add appropriate
words to the glossary.  And then make the documentation match that.


  -Fred

-- 
Fred L. Drake, Jr.    
"Give me the luxuries of life and I will willingly do without the necessities."
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Snow Leopard buildbot failing again...

On 27/06/2011 18:01, Bill Janssen wrote:

I see that parc-snowleopard-1 went down again. I've done a software
update, rebooted, and installed the latest buildslave, 0.8.4. I can
ping dinsdale.python.org successfully from the machine. However, when I
start the buildslave, I get this:

$ buildslave start ~/buildarea/
/Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/internet/_sslverify.py:5:
DeprecationWarning: the md5 module is deprecated; use hashlib instead
import itertools, md5
Following twistd.log until startup finished..
/Library/Python/2.6/site-packages/buildbot_slave-0.8.4-py2.6.egg/buildslave/scripts/logwatcher.py:67:
PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not
installed. This probably means you have not yet called reactor.run, or called
reactor.run(installSignalHandler=0). You will probably never see this process
finish, and it may become a zombie process.
env=os.environ,
/Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/persisted/sob.py:12:
DeprecationWarning: the md5 module is deprecated; use hashlib instead
import os, md5, sys
/Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/python/filepath.py:12:
DeprecationWarning: the sha module is deprecated; use the hashlib module
instead
import sha
2011-06-27 09:45:31-0700 [-] Log opened.
2011-06-27 09:45:31-0700 [-] twistd 8.2.0 (/usr/bin/python 2.6.1) starting up.
2011-06-27 09:45:31-0700 [-] reactor class:
twisted.internet.selectreactor.SelectReactor.
2011-06-27 09:45:31-0700 [-] Starting BuildSlave -- version: 0.8.4
2011-06-27 09:45:31-0700 [-] recording hostname in twistd.hostname

The buildslave took more than 10 seconds to start, so we were unable to
confirm that it started correctly. Please 'tail twistd.log' and look for a
line that says 'configuration update complete' to verify correct startup.

Now, I thought of updating Twisted, but the Twisted downloads page says,

``Twisted is no longer making a .dmg for OS X because OS X versions 10.5
and greater ship with Twisted installed and the default Python path
configuration makes it impossible for a user to upgrade Twisted without
possibly breaking applications which depend on the system Twisted
installation.''

Anyone know just what those applications are? All this machine is doing
is running the Python buildbot.

Well the calendar server (at least) uses the system twisted. It is best
to leave the system python alone and install / use a python.org python
install. Are the buildbot scripts hardcoded to use the system python on
Macs? If so you will have to stick with the system version of twisted,
which seems to be problematic.

All the best,

Michael

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Antoine Pitrou

Le Tue, 28 Jun 2011 00:36:20 +1000,
Nick Coghlan  a écrit :
> And no, the fact that methods can be treated as attributes is not a
> minor detail. It is *fundamental* to Python's object model that
> *methods are not a special case of attribute access*.

Uh, and so what?

Again, the stdlib docs are describing APIs from a high-level viewpoint, not
the Python object model. Just because a method is treated like other
attributes, or a function is treated like other callable objects, doesn't
mean we should replace "method" with "attribute", or "function" with
"callable object", or "class" with "instance of the type type".

I'm -1 on such a change anyway.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Snow Leopard buildbot failing again...

2011-06-27 Thread exarkun


On 05:01 pm, jans...@parc.com wrote:

I see that parc-snowleopard-1 went down again.  I've done a software
update, rebooted, and installed the latest buildslave, 0.8.4.  I can
ping dinsdale.python.org successfully from the machine.  However, when 
I

start the buildslave, I get this:

[snip]




The buildslave took more than 10 seconds to start, so we were unable to
confirm that it started correctly. Please 'tail twistd.log' and look 
for a
line that says 'configuration update complete' to verify correct 
startup.


Did you look at twistd.log?

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Terry Reedy


On 6/27/2011 4:24 AM, Antoine Pitrou wrote:

Le Mon, 27 Jun 2011 11:32:32 +1000,
Nick Coghlan  a écrit :




"Members" is a historical relic that is best replaced by "attributes"
or "data attributes" if we want to explicitly exclude methods for some
reason. "Methods" is a subset of attributes that explicitly excludes
data attributes.


While I know it is technically right, I find it a bit strange to refer to
methods as "attributes". We're describing an API, not the inner working of
the object model. Also, people just discovering Python will probably be a
bit surprised if we start refer to methods as "attributes".

FWIW, I tend to understand "members" as "methods + attributes", which makes
it a nice term to use for that purpose.


Let me repeat that that is historically wrong for Python, and illustrate 
why the term 'members' should not be used. From the 1.5 Language 
Reference, 3.2 Standard type hierarchy: "There are also some 'generic' 
special attributes, not listed with the individual objects: __methods__ 
is a list of the method names of a built-in object, if it has any; 
__members__ is a list of the data attribute names of a built-in object, 
if it has any."


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Snow Leopard buildbot failing again...

exar...@twistedmatrix.com wrote:

> On 05:01 pm, jans...@parc.com wrote:
> >I see that parc-snowleopard-1 went down again.  I've done a software
> >update, rebooted, and installed the latest buildslave, 0.8.4.  I can
> > ping dinsdale.python.org successfully from the machine.  However,
> > when I
> >start the buildslave, I get this:
> >
> >[snip]
> 
> >
> >The buildslave took more than 10 seconds to start, so we were unable to
> > confirm that it started correctly. Please 'tail twistd.log' and look
> > for a
> > line that says 'configuration update complete' to verify correct
> > startup.
> 
> Did you look at twistd.log?
> 
> Jean-Paul

Um... not to look for "configuration update complete", I'm afraid.
Isn't that a buildmaster-only thing?  Here's what was there.

2011-06-27 09:45:31-0700 [-] Log opened.
2011-06-27 09:45:31-0700 [-] twistd 8.2.0 (/usr/bin/python 2.6.1) starting up.
2011-06-27 09:45:31-0700 [-] reactor class: 
twisted.internet.selectreactor.SelectReactor.
2011-06-27 09:45:31-0700 [-] Starting BuildSlave -- version: 0.8.4
2011-06-27 09:45:31-0700 [-] recording hostname in twistd.hostname
2011-06-27 09:46:01-0700 [-] Starting factory 
2011-06-27 09:46:01-0700 [-] Connecting to dinsdale.python.org:9020
2011-06-27 09:46:02-0700 [Broker,client] message from master: attached
2011-06-27 09:46:02-0700 [Broker,client] I have a leftover directory 
'3.1.parc-snowleopard-1' that is not being used by the buildmaster: you can 
delete it now
2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow 
Leopard 2 custom): message from master: attached
2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow 
Leopard 2 2.7): message from master: attached
2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow 
Leopard 2 3.x): message from master: attached
2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow 
Leopard 2 3.2): message from master: attached
2011-06-27 09:46:05-0700 [Broker,client] Connected to dinsdale.python.org:9020; 
slave is ready
2011-06-27 09:46:05-0700 [Broker,client] sending application-level keepalives 
every 600 seconds

There is that 30-second lag between "recording hostname in
twistd.hostname" and "Starting factory", which is presumably what
triggers the warning from buildslave.  See
 and .

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Snow Leopard buildbot failing again...

I also find  interesting, because
it seems a good explanation of why the build slave might go into the
zombie state of attempting to reconnect to the master.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Mon, 27 Jun 2011 19:27:26 +0200, Antoine Pitrou  wrote:
> Le Tue, 28 Jun 2011 00:36:20 +1000,
> Nick Coghlan  a Ã©crit :
> > And no, the fact that methods can be treated as attributes is not a
> > minor detail. It is *fundamental* to Python's object model that
> > *methods are not a special case of attribute access*.
> 
> Uh, and so what?
> 
> Again, the stdlib docs are describing APIs from a high-level viewpoint, not
> the Python object model. Just because a method is treated like other
> attributes, or a function is treated like other callable objects, doesn't
> mean we should replace "method" with "attribute", or "function" with
> "callable object", or "class" with "instance of the type type".

I don't think there is any disagreement with regards to replacing
'methods' with 'attributes'.  This should not be done, in general, and
I don't think anybody involved in this particular discussion thinks it
should be.  The question is what to call non-method attributes, or how we
refer to a mix of method and non-method attributes.  In some cases just
saying 'attributes' may make sense for the latter, but in most cases it 
probably doesn't, because many people coming from other languages do
not expect methods to be first class objects.  So I'd like to be able
to say, in those cases, "attributes (XXXs and methods)".

The subject of this thread is the removal of the use of the term 'members'
for XXX, for the historical reasons cited.

IMO the goal should be to help the reader's mental model match what Python
actually does.  In that sense Python's object model *does* matter[*],
in that we shouldn't make it harder for the reader to figure out what is
"really" going on.  In the cases you cited, you are arguing that the
more specific term (method, function, class) should not be replaced
in the docs by the more generic term (attribute, callable object,
instance of type type).  I don't think anyone would argue with you
about that in general.  (In specific there might in fact be some
places in the docs where such a change would improve clarity!)

So, the correct generic term for something that can be accessed
via attribute notation is attribute.  The more specific term for an
attribute that is a method is method.  We don't currently have a more
specific collective term for attributes that aren't methods.  *That*
is the problem.

--
R. David Murray   http://www.bitdance.com

[*] it also seems to me that the object model is, in many ways, *part*
of the API, in the sense that the API is how you access the object model,
and so understanding the object model is, if not essentially, then at
least very helpful.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation


On 27/06/2011 20:22, R. David Murray wrote:

[snip...]
So, the correct generic term for something that can be accessed
via attribute notation is attribute.  The more specific term for an
attribute that is a method is method.  We don't currently have a more
specific collective term for attributes that aren't methods.  *That*
is the problem.


I think part of the problem is also that *some* people's usage of the 
term doesn't match the precise terminology.


It sounds like if I say "an object's attributes" some of us will expect 
that to include the methods and some of us not. I'd say anecdotally that 
when people talk about object attributes collectively they are *not* 
including methods. When they talk about attribute lookup that rightly 
includes everything.


We do have other terms: instance attributes (which do not include 
methods) and class attributes (which technically do - but is also used 
to indicate attributes set on the class rather than the instance but not 
including methods [1]).


A precise term to describe "attributes that are not methods" would still 
be helpful. I guess the closest we have is "non-descriptors", but that 
requires a knowledge of the descriptor protocol for it to be useful.


Making-things-worse-and-not-better'ly yours,

Michael

[1] I'm talking about *usage* of the term here... I guess usage is 
inconsistent anyway, sometimes people will mean to include methods and 
sometimes not.

--
R. David Murray   http://www.bitdance.com

[*] it also seems to me that the object model is, in many ways, *part*
of the API, in the sense that the API is how you access the object model,
and so understanding the object model is, if not essentially, then at
least very helpful.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Mon, 27 Jun 2011 20:30:12 +0100, Michael Foord  
wrote:
> On 27/06/2011 20:22, R. David Murray wrote:
> > [snip...]
> > So, the correct generic term for something that can be accessed
> > via attribute notation is attribute.  The more specific term for an
> > attribute that is a method is method.  We don't currently have a more
> > specific collective term for attributes that aren't methods.  *That*
> > is the problem.
> 
> I think part of the problem is also that *some* people's usage of the 
> term doesn't match the precise terminology.
> 
> It sounds like if I say "an object's attributes" some of us will expect 
> that to include the methods and some of us not. I'd say anecdotally that 
> when people talk about object attributes collectively they are *not* 
> including methods. When they talk about attribute lookup that rightly 
> includes everything.

Yes, I think that it is common to use 'attributes' to mean 'non-method
attributes', and often the context can make clear which usage is
intended.  What we should do in our own docs is a different question,
but we do have other cases where "it is clear from context" is
considered a valid argument for technically imprecise terminology.
And I think that's reasonable.

> A precise term to describe "attributes that are not methods" would still 
> be helpful. I guess the closest we have is "non-descriptors", but that 
> requires a knowledge of the descriptor protocol for it to be useful.

I'm not really as comfortable as I think I should be with the descriptor
stuff, but aren't properties descriptors in the sense you are using it
here?  Yet I don't think a property should be called a method, even though
it is implemented via a function(s) that looks a lot like a method.  This is
why talking about non-method attributes collectively is so fraught

--
R. David Murray   http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Terry Reedy


On 6/27/2011 5:42 AM, Michael Foord wrote:

On 27/06/2011 09:24, Antoine Pitrou wrote:



FWIW, I tend to understand "members" as "methods + attributes", which
makes
it a nice term to use for that purpose.


That is my understanding / use of the terms as well.


On 6/27/2011 5:45 AM, Oleg Broytman wrote:
> That's my feeling too.

Whereas the actual existing usage is that attributes = members + 
methods. 'Member' came from 'member of a data structure', as in complex 
numbers have real and imag members, whereas lists have methods but no 
(user visible) members.


The fact that so many people get the Python usage of 'member' so wrong 
is a good reason to retire it.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Terry Reedy


On 6/27/2011 2:33 PM, Terry Reedy wrote:


Let me repeat that that is historically wrong for Python, and illustrate
why the term 'members' should not be used. From the 1.5 Language
Reference, 3.2 Standard type hierarchy: "There are also some 'generic'
special attributes, not listed with the individual objects: __methods__
is a list of the method names of a built-in object, if it has any;
__members__ is a list of the data attribute names of a built-in object,
if it has any."


This sentence was left untouched until 2.2. What's new 2.2 has "In 
previous versions of Python, there was no consistent way to discover 
what attributes and methods were supported by an object. There were some 
informal conventions, such as defining __members__ and __methods__ 
attributes that were lists of names, but often the author of an 
extension type or a class wouldn't bother to define them."
This is a section on descriptors, but the real replacement is, I 
believe, dir().


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation


On 27/06/2011 23:18, Terry Reedy wrote:

On 6/27/2011 2:33 PM, Terry Reedy wrote:


Let me repeat that that is historically wrong for Python, and illustrate
why the term 'members' should not be used. From the 1.5 Language
Reference, 3.2 Standard type hierarchy: "There are also some 'generic'
special attributes, not listed with the individual objects: __methods__
is a list of the method names of a built-in object, if it has any;
__members__ is a list of the data attribute names of a built-in object,
if it has any."


This sentence was left untouched until 2.2. What's new 2.2 has "In 
previous versions of Python, there was no consistent way to discover 
what attributes and methods were supported by an object. There were 
some informal conventions, such as defining __members__ and 
__methods__ attributes that were lists of names, but often the author 
of an extension type or a class wouldn't bother to define them."
So the Python 2.2 what's new talks about attributes and methods as 
different things Of course the context makes it clear, but this 
mirrors how I use the terms in discussion and how I see others generally 
using them.


Great topic for bikeshedding. :-)

Michael

This is a section on descriptors, but the real replacement is, I 
believe, dir().





--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] pdb and generators

2011-06-27 Thread Guido van Rossum

When debugging generators (especially when using them as coroutines) I
often want 'next' to step over a yield statement/expression, instead
of the current behavior, which is to step out of the frame, since pdb
doesn't seem to see the difference between yield and return. Or I
could live with a separate command to step over the yield. Has anyone
looked into this yet? I found a question about this on
StackOverflow.com but the answers were particularly unhelpful, so I'm
guessing I'm not the first to want this but it hasn't been solved yet.
It might be a good project for someone looking into hacking pdb.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 380 acceptance (was Re: EuroPython Language Summit report)

On Tue, Jun 28, 2011 at 1:09 AM, renaud  wrote:
> Nick Coghlan  gmail.com> writes:
>
>> I hit a snag with this. The real tests of the PEP 380 functionality
>> aren't currently part of the patch - they're a big set of "golden
>> output" tests in the zipfile hosted on Greg's site. Those need to be
>> refactored into proper unittest or doctest based additions to the test
>> suite and incorporated into the patch before I could commit this with
>> a clear conscience.
>
> let me know if i can help.

It would be good if you could take a look at Greg's original test
suite, consider ways of bringing it into the main regression tests and
then update the patch queue on bitbucket accordingly.

My preference is for something unittest based, essentially taking the
"golden output" comparisons and turning them into appropriate
self.assert* invocations.

Given the number of tests Greg has, it will probably make more sense
to do it as a new test subdirectory rather than as a single test file
(although that depends on how many tests are in each file - if there
are only a few, or if they overlap a lot, then having them as separate
test cases within a single file may be a better choice).

>> Renaud's patch mostly applies cleanly at the moment - the only change
>> is that the "#endif" for the Py_LIMITED_API check needs to be moved in
>> pyerrors.h so it also covers the new StopIteration struct definition.
>
> if this helps, i've updated the patch to fix this.
> https://bitbucket.org/rndblnch/cpython-pep380/changeset/6014d1720625

Yep, that does help.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Steven D'Aprano


R. David Murray wrote:


So, the correct generic term for something that can be accessed
via attribute notation is attribute.  The more specific term for an
attribute that is a method is method.  We don't currently have a more
specific collective term for attributes that aren't methods.  *That*
is the problem.


"Attribute" also encompasses both instance attributes and class 
attributes. Rather than having two different words, we simply qualify 
the word when we need to distinguish them.


Likewise, in the cases where it is important to distinguish methods from 
other attributes, we should qualify the word: data attribute vs method 
attribute.


(I'm not suggesting that we should routinely refer to "method attribute" 
rather than simply method, but only when we wish to emphasize that 
methods are a kind of attribute and not a completely different kind of 
thing.)




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Tue, Jun 28, 2011 at 8:46 AM, Michael Foord
 wrote:
> So the Python 2.2 what's new talks about attributes and methods as different
> things Of course the context makes it clear, but this mirrors how I use
> the terms in discussion and how I see others generally using them.
>
> Great topic for bikeshedding. :-)

Yep, as David said, "attribute" is legitimately used to mean *both*
"all attributes (i.e. both data attributes and methods)" and "data
attributes (i.e. excluding methods)". In general, context makes it
clear which meaning is intended, and when that isn't the case, more
verbose phrasing such as that in the previous sentence can make it
explicit.

Rather than fighting that convention, we should probably just confront
the ambiguity head on and update
http://docs.python.org/dev/glossary.html#term-attribute to describe
both uses of the term (and add a separate entry for "data attribute",
with a definition which basically says "attributes which are not
methods").

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Ben Finney

Rob Cliffe  writes:

> On 27/06/2011 15:08, R. David Murray wrote:

> > I guess what I'm saying is that I am more comfortable calling them
> > all attributes than calling them all members. The term 'members'
> > isn't used anywhere in the language itself, as far as I can recall,
> > whereas getattr and setattr are evidence that the language considers
> > them all attributes. I think we do the documentation readers a
> > disservice by obscuring that fact by using other terminology.

+1

> 'function attributes' ?  'def attributes' ?

−1. They don't have to be functions, and hence don't have to be created
by ‘def’.

> Or just stick with method attributes' ?

“callable attributes” describes exactly what they are, in terms that
will remain useful to the person learning Python.

-- 
 \  “‘Did you sleep well?’ ‘No, I made a couple of mistakes.’” |
  `\—Steven Wright |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Eric Snow

On Mon, Jun 27, 2011 at 8:11 PM, Ben Finney  wrote:
> Rob Cliffe  writes:
>
>> 'function attributes' ?  'def attributes' ?
>
> -1. They don't have to be functions, and hence don't have to be created
> by 'def'.
>
>> Or just stick with method attributes' ?
>
> "callable attributes" describes exactly what they are, in terms that
> will remain useful to the person learning Python.
>

The usage of the object determines what we call it then, so what about
"state attributes" in the same vein as "callable attributes" (data vs.
method).  But it would be nice to have the names consistent across the
different contexts.

ABCMeta tests __isabstractmethod__ on each attribute of a class, not
just the methods, rather that __isabstractattribute__.  Perhaps
calling something a method attribute even when it isn't a function is
still okay.  Thus the pair could be "method and data attributes".
"method attribute" is a little redundant but calling it a "function
attribute" seems less consistent

-eric

> --
>  \  "'Did you sleep well?' 'No, I made a couple of mistakes.'" |
>  `\--Steven Wright |
> _o__)  |
> Ben Finney
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

2011-06-27 Thread Ben Finney

Eric Snow  writes:

> On Mon, Jun 27, 2011 at 8:11 PM, Ben Finney  
> wrote:
> > "callable attributes" describes exactly what they are, in terms that
> > will remain useful to the person learning Python.
>
> The usage of the object determines what we call it then

No, the capability of the attribute is what determines that difference,
not how it's used.

I still don't have a good term for “non-callable attribute”, though.

-- 
 \ “I'm not a bad guy! I work hard, and I love my kids. So why |
  `\  should I spend half my Sunday hearing about how I'm going to |
_o__)Hell?” —Homer Simpson |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Snow Leopard buildbot failing again...

2011-06-27 Thread Martin v. Löwis

Am 27.06.2011 21:05, schrieb Bill Janssen:
> I also find  interesting, because
> it seems a good explanation of why the build slave might go into the
> zombie state of attempting to reconnect to the master.

That wouldn't apply to our buildslaves, though, since we don't have
FileUpload build steps (except for a single builder run by David Bolen).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation