Help wanted for Python 3000 PEP

Hi,

Would you be interested in reviewing/contributing to a
Python Enhancement 
Proposal for Python-3000?  I am half-way through writing
this PEP on Type 
Expressions. There has been significant chat on the py3k
mailing list 
(http://
mail.python.org/pipermail/python-3000/) about optional
static type 
checking so a type system is needed to support this.

Any takers?

I'll buy the coffees!

Bill
-- 
http://billbirch.word
press.com/
_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

Hi,

I'll be pleased to comment. Incidentially I will arrive
back Melbourne 
later.
Please send me what you have so far.
Thanks
Maurice

Bill Birch wrote:

>Hi,
>
>Would you be interested in reviewing/contributing to a
Python Enhancement 
>Proposal for Python-3000?  I am half-way through writing
this PEP on Type 
>Expressions. There has been significant chat on the py3k
mailing list 
>(http://
mail.python.org/pipermail/python-3000/) about optional
static type 
>checking so a type system is needed to support this.
>
>Any takers?
>
>I'll buy the coffees!
>
>Bill
>  
>
_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

Bill Birch wrote:
> Hi,
>
> Would you be interested in reviewing/contributing to a
Python Enhancement 
> Proposal for Python-3000?  I am half-way through
writing this PEP on Type 
> Expressions. There has been significant chat on the
py3k mailing list 
> (http://
mail.python.org/pipermail/python-3000/) about optional
static type 
> checking so a type system is needed to support this.
>
> Any takers?
>
> I'll buy the coffees!
>
> Bill
>   
Sure, count me in for a discussion session or review or
whatever would 
be helpful. It's not my central area, but I'm happy to
provide what help 
I can. Let's see what you're talking about, and I'll let
you know if 
there's anything useful I can do.

Cheers,
-T
_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

Hi all,

I've been starting to adopt a new coding idiom, and I
thought I'd ask 
for comments.

I've been extending some code, which has involved
overriding many 
__doFoo() methods and accessing __myVariable variables. As I
understand 
it, this is stylistically bad, and __XXX is a way of
flagging that the 
thing is private-only. Keep Out Unless Absolutely Necessary.

I can see a middle ground between the public interface and
very private 
methods. Such a thing might be an element of processing
which is 
typically called privately, but wouldn't be unsafe to call
or override 
in appropriate circumstances.

For this reason I've been using .XXX for the public
interface, ._doFoo() 
for internal methods which are relatively safe, and
.__doFoo() for 
things intended to be very private.

Cheers,
-T
_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

On Fri, 2006-05-05 at 09:49 +1000, Tennessee Leeuwenburg
wrote:
> Hi all,
> 
> I've been starting to adopt a new coding idiom, and I
thought I'd ask 
> for comments.
> 
> I've been extending some code, which has involved
overriding many 
> __doFoo() methods and accessing __myVariable variables.
As I understand 
> it, this is stylistically bad, and __XXX is a way of
flagging that the 
> thing is private-only. Keep Out Unless Absolutely
Necessary.
> 
> I can see a middle ground between the public interface
and very private 
> methods. Such a thing might be an element of processing
which is 
> typically called privately, but wouldn't be unsafe to
call or override 
> in appropriate circumstances.
> 
> For this reason I've been using .XXX for the public
interface, ._doFoo() 
> for internal methods which are relatively safe, and
.__doFoo() for 
> things intended to be very private.

I concur. That's pretty much what I use as well. I also
tend to
use ._XXX() for things that I'm deprecating but don't want
to nuke the
code from the file just yet. This is mostly because I'm
slack with my
test code (ie: I don't have any) so I'm not sure what else
might be
using the method and may need to reinstate it. 

-- 
Justin Warren <daedaluseigenmagic.com>

_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

Hi,

Programmatically, Python does not have any means to
"hide" methods, all 
methods are public (in java's terms). There may be some
good reasons for 
doing so, at least it simplifies things. However, in a large
module 
(especially modules that we did not write ourselves),
changing a method 
can be scary because it may break other parts.

Personally, I think that using .XXX for public, ._XXX for
internal and 
.__XXX for private methods is more of a code documentation
thing, which 
is probably good if followed religiously. At least it does
put up a 
danger flag for yourself in future and prevent shooting
yourself in the 
foot.

I am just wondering how can this is better tied in with Bill
Birch's 
type proposal......

maurice

Tennessee Leeuwenburg wrote:

>Hi all,
>
>I've been starting to adopt a new coding idiom, and I
thought I'd ask 
>for comments.
>
>I've been extending some code, which has involved
overriding many 
>__doFoo() methods and accessing __myVariable variables.
As I understand 
>it, this is stylistically bad, and __XXX is a way of
flagging that the 
>thing is private-only. Keep Out Unless Absolutely
Necessary.
>
>I can see a middle ground between the public interface
and very private 
>methods. Such a thing might be an element of processing
which is 
>typically called privately, but wouldn't be unsafe to
call or override 
>in appropriate circumstances.
>
>For this reason I've been using .XXX for the public
interface, ._doFoo() 
>for internal methods which are relatively safe, and
.__doFoo() for 
>things intended to be very private.
>
>Cheers,
>-T
>_______________________________________________
>melbourne-pug mailing list
>melbourne-pugpython.org
>http://mail.python.org/mailman/listinfo/melbourne-pug
>
>  
>

_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

On Fri, 2006-05-05 at 10:31 +1000, Maurice Ling wrote:
> Hi,
> 
> Programmatically, Python does not have any means to
"hide" methods, all 
> methods are public (in java's terms). There may be
some good reasons for 
> doing so, at least it simplifies things. However, in a
large module 
> (especially modules that we did not write ourselves),
changing a method 
> can be scary because it may break other parts.
> 
> Personally, I think that using .XXX for public, ._XXX
for internal and 
> .__XXX for private methods is more of a code
documentation thing, which 
> is probably good if followed religiously. At least it
does put up a 
> danger flag for yourself in future and prevent shooting
yourself in the 
> foot.
> 
> I am just wondering how can this is better tied in with
Bill Birch's 
> type proposal......

I like that Python doesn't prevent you from using any
method. This means
that if I have a good reason for using a ._xx() or .__xx()
method, I can
use it without having to change the module to make the
method public or
shared (or whatever the C++ idiom is).

I've had to use an 'internal' method from a third party
module a couple
of times because the module in question didn't have the
interface or
functionality I needed and I didn't want to write a wrapper
module or
modify the library code. It encourages me to contact the
module
developer to request a feature enhancement.. or to submit a
patch.

-- 
Justin Warren <daedaluseigenmagic.com>

_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

I thought I remembered something special about
double-underscore 
attributes - http
://www.thescripts.com/forum/thread41364.html has more 
detail.  Basically, their name gets mangled to avoid
namespace 
collisions.  The upshot of this is, the classes you're
working with may 
not behave as you expect if you inherit from it for another
class (I'd 
guess that the potential for unexpected behaviour is low,
but it's there).

I, unlike you, don't see a middle ground between public and
private - 
either the variable is part of the documented API and safe
to use, or 
it's not.  So .XXX and ._XXX are sufficient in my mind, and
the only 
place I use double-underscores is for the standard __doc__,
__init__, 
etc. methods.

KevinL

Maurice Ling wrote:
> Hi,
>
> Programmatically, Python does not have any means to
"hide" methods, all 
> methods are public (in java's terms). There may be
some good reasons for 
> doing so, at least it simplifies things. However, in a
large module 
> (especially modules that we did not write ourselves),
changing a method 
> can be scary because it may break other parts.
>
> Personally, I think that using .XXX for public, ._XXX
for internal and 
> .__XXX for private methods is more of a code
documentation thing, which 
> is probably good if followed religiously. At least it
does put up a 
> danger flag for yourself in future and prevent shooting
yourself in the 
> foot.
>
> I am just wondering how can this is better tied in with
Bill Birch's 
> type proposal......
>
> maurice
>
> Tennessee Leeuwenburg wrote:
>
>   
>> Hi all,
>>
>> I've been starting to adopt a new coding idiom,
and I thought I'd ask 
>> for comments.
>>
>> I've been extending some code, which has involved
overriding many 
>> __doFoo() methods and accessing __myVariable
variables. As I understand 
>> it, this is stylistically bad, and __XXX is a way
of flagging that the 
>> thing is private-only. Keep Out Unless Absolutely
Necessary.
>>
>> I can see a middle ground between the public
interface and very private 
>> methods. Such a thing might be an element of
processing which is 
>> typically called privately, but wouldn't be unsafe
to call or override 
>> in appropriate circumstances.
>>
>> For this reason I've been using .XXX for the
public interface, ._doFoo() 
>> for internal methods which are relatively safe, and
.__doFoo() for 
>> things intended to be very private.
>>
>> Cheers,
>> -T
>> _______________________________________________
>> melbourne-pug mailing list
>> melbourne-pugpython.org
>> http://mail.python.org/mailman/listinfo/melbourne-pug
>>
>>  
>>
>>     
>
> _______________________________________________
> melbourne-pug mailing list
> melbourne-pugpython.org
> http://mail.python.org/mailman/listinfo/melbourne-pug
>   

_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug

Justin Warren wrote:

>On Fri, 2006-05-05 at 10:31 +1000, Maurice Ling wrote:
>  
>
>>Hi,
>>
>>Programmatically, Python does not have any means to
"hide" methods, all 
>>methods are public (in java's terms). There may be
some good reasons for 
>>doing so, at least it simplifies things. However, in
a large module 
>>(especially modules that we did not write
ourselves), changing a method 
>>can be scary because it may break other parts.
>>
>>Personally, I think that using .XXX for public,
._XXX for internal and 
>>.__XXX for private methods is more of a code
documentation thing, which 
>>is probably good if followed religiously. At least
it does put up a 
>>danger flag for yourself in future and prevent
shooting yourself in the 
>>foot.
>>
>>I am just wondering how can this is better tied in
with Bill Birch's 
>>type proposal......
>>    
>>
>
>I like that Python doesn't prevent you from using any
method. This means
>that if I have a good reason for using a ._xx() or
.__xx() method, I can
>use it without having to change the module to make the
method public or
>shared (or whatever the C++ idiom is).
>  
>
I understand your point on this. It does remove the constant
need to 
decide the "view" of a method as I code in
Python. My real concern with 
such idioms is this, it varies with developers. For example,
you 
(Justin) may use ._XX for depreciation of codes, Tennessee
uses ._XX for 
internal methods, we can appreciate the confusion of the 3rd
person 
using both of your codes (or even more) together.

So to an extend, when I look at unknown codes, .XX means
safe and any 
number of underscore prefixes to XX (ie, ._XX or .__XX)
means 
unquantified danger.

I am hoping that Bill's type system is able to strike a
middle ground on 
this, allowing developers to define their own coding
conventions which 
is mappable to a standard type system as metaknowledge, or
something 
like that.

maurice

>I've had to use an 'internal' method from a third
party module a couple
>of times because the module in question didn't have the
interface or
>functionality I needed and I didn't want to write a
wrapper module or
>modify the library code. It encourages me to contact the
module
>developer to request a feature enhancement.. or to
submit a patch.
>
>  
>

_______________________________________________
melbourne-pug mailing list
melbourne-pugpython.org
http://mail.python.org/mailman/listinfo/melbourne-pug