From cmjohnson.mailinglist at gmail.com  Wed Sep  2 12:34:49 2009
From: cmjohnson.mailinglist at gmail.com (Carl Johnson)
Date: Wed, 2 Sep 2009 00:34:49 -1000
Subject: [Python-ideas] [Python-Dev] Decorator syntax
In-Reply-To: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>
Message-ID: <3bdda690909020334m4c81cecdm8f57dce54c2da398@mail.gmail.com>

Crossposting to Python-ideas,

I asked for the same change to the grammar a couple months back on
python-ideas.

See http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787

I'm all for it, but you'll have to convince Guido that this won't
result in confusing to read code. My own examples, unfortunately did
not advance your cause, as Guido explained, "My brain hurts trying to
understand all this. I don't think this bodes well as a use case for a
proposed feature." :-D The trouble is that I was using lambdas upon
lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come
up with some simple, clear use cases though, and I think he might
still be persuadable to make a simple change to the grammar.


? Carl Johnson

Rob Cliffe <rob.cliffe at btinternet.com> wrote:

> Hi All,
> This is my first post to python-dev so I will briefly introduce myself:? My
> name is Rob Cliffe and I am a commercial programmer living in London, UK.? I
> have some 30 years of programming experience but have only been using Python
> for a couple of years.
> First I want to say what a fantastic language Python is.? It is THE best
> language for development in my opinion, and a joy to use.
>
> My specific issue:
> I eventually got my head round decorator syntax and realised that what came
> after the '@' was (basically) a function that took a function as argument
> and returned a function as result.
> However it seems to me?unPythonesque (i.e. an exception to Python's normal
> consistency) that the syntax of what follows the '@' should be restricted to
> either a single (function) identifier or a single (function) identifier with
> an argument list.
> The example I tried, which seems not an unreasonable sort of thing to do,
> was along the lines of:
>
> def deco1(func):
> ??? <deco1-suite>
> def deco2(func):
> ??? <deco2-suite>
>
> DecoList = [deco1, deco2]
>
> @DecoList[0]??? # NO - CAUSES SYNTAX ERROR
> def foo():
> ??? pass
>
> I am sure other guys have their own examples.
>
> I am of course not the first person to raise this issue, and I see that
> Guido has a "gut feeling" against allowing a general expression after the
> '@'.
>
> BUT - a general expression can be "smuggled in" very easily as a function
> argument:
>
> def Identity(x): return x
>
> @Identity(DecoList[0])??? # THIS WORKS
> def foo():
> ??? pass
>
> So - the syntax restriction seems not only?inconsistent, but?pointless; it
> doesn't forbid anything, but merely means we have to do it in a slightly
> convoluted (unPythonesque) way.? So please, Guido, will you reconsider?
>
> Best wishes
> Rob Cliffe


From fuzzyman at gmail.com  Wed Sep  2 12:49:31 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Wed, 2 Sep 2009 11:49:31 +0100
Subject: [Python-ideas] [Python-Dev] Decorator syntax
In-Reply-To: <3bdda690909020334m4c81cecdm8f57dce54c2da398@mail.gmail.com>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>
	<3bdda690909020334m4c81cecdm8f57dce54c2da398@mail.gmail.com>
Message-ID: <6f4025010909020349h31573e63if2c112ba471b8872@mail.gmail.com>

I actually encountered this for the first time yesterday and didn't realise
that the decorator syntax was limited in this way (I was mentally preparing
a blog entry when these emails arrived).

What I needed to do was turn a Python function  into a .NET event handler in
IronPython. The simple case is this:

from System import EventHandler

@EventHandler
def on_event(sender, event):
    # do stuff...

This works fine of course, but then I needed to use the 'typed' form which
is like this:

@EventHandler[HtmlEventArgs]
def on_event(sender, event):
    # do stuff...

I didn't realise this was invalid syntax - nor the neat trick with the
identity function to bypass the limitation.

Michael

2009/9/2 Carl Johnson <cmjohnson.mailinglist at gmail.com>

> Crossposting to Python-ideas,
>
> I asked for the same change to the grammar a couple months back on
> python-ideas.
>
> See
> http://mail.python.org/pipermail/python-ideas/2009-February/thread.html#2787
>
> I'm all for it, but you'll have to convince Guido that this won't
> result in confusing to read code. My own examples, unfortunately did
> not advance your cause, as Guido explained, "My brain hurts trying to
> understand all this. I don't think this bodes well as a use case for a
> proposed feature." :-D The trouble is that I was using lambdas upon
> lambdas to do all kinds of Ruby block-esque tricks. OTOH, if you come
> up with some simple, clear use cases though, and I think he might
> still be persuadable to make a simple change to the grammar.
>
>
> ? Carl Johnson
>
> Rob Cliffe <rob.cliffe at btinternet.com> wrote:
>
> > Hi All,
> > This is my first post to python-dev so I will briefly introduce myself:
> My
> > name is Rob Cliffe and I am a commercial programmer living in London,
> UK.  I
> > have some 30 years of programming experience but have only been using
> Python
> > for a couple of years.
> > First I want to say what a fantastic language Python is.  It is THE best
> > language for development in my opinion, and a joy to use.
> >
> > My specific issue:
> > I eventually got my head round decorator syntax and realised that what
> came
> > after the '@' was (basically) a function that took a function as argument
> > and returned a function as result.
> > However it seems to me unPythonesque (i.e. an exception to Python's
> normal
> > consistency) that the syntax of what follows the '@' should be restricted
> to
> > either a single (function) identifier or a single (function) identifier
> with
> > an argument list.
> > The example I tried, which seems not an unreasonable sort of thing to do,
> > was along the lines of:
> >
> > def deco1(func):
> >     <deco1-suite>
> > def deco2(func):
> >     <deco2-suite>
> >
> > DecoList = [deco1, deco2]
> >
> > @DecoList[0]    # NO - CAUSES SYNTAX ERROR
> > def foo():
> >     pass
> >
> > I am sure other guys have their own examples.
> >
> > I am of course not the first person to raise this issue, and I see that
> > Guido has a "gut feeling" against allowing a general expression after the
> > '@'.
> >
> > BUT - a general expression can be "smuggled in" very easily as a function
> > argument:
> >
> > def Identity(x): return x
> >
> > @Identity(DecoList[0])    # THIS WORKS
> > def foo():
> >     pass
> >
> > So - the syntax restriction seems not only inconsistent, but pointless;
> it
> > doesn't forbid anything, but merely means we have to do it in a slightly
> > convoluted (unPythonesque) way.  So please, Guido, will you reconsider?
> >
> > Best wishes
> > Rob Cliffe
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090902/3a3f3350/attachment.html>

From ncoghlan at gmail.com  Wed Sep  2 13:18:57 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 02 Sep 2009 21:18:57 +1000
Subject: [Python-ideas] [Python-Dev] Decorator syntax
In-Reply-To: <126B4B7C-38AF-45DF-B5F2-DB146E7146C8@masklinn.net>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>
	<126B4B7C-38AF-45DF-B5F2-DB146E7146C8@masklinn.net>
Message-ID: <4A9E54A1.4060408@gmail.com>

Xavier Morel wrote:
> On 2 Sep 2009, at 12:15 , Rob Cliffe wrote:
>>
>> @Identity(DecoList[0])    # THIS WORKS
>> def foo():
>>    pass
> For what it's worth, you don't need an id function, you can simply write
> 
>     @itemgetter(0)(decorators)
>     def foo():
>         'whatever'
> or
> 
>     @decorators.__getitem__(0)
>     def foo():
>         'whatever'

To be honest, I'd forgotten the restriction was even there. So +0 on
removing it and relying on "consenting adults" and style guides to keep
people from getting to obscure with their decorators.

However, any such change should also be accompanied by an update to PEP
8 (recommending the current syntactic restrictions as style rules for
the standard library).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From guido at python.org  Wed Sep  2 16:15:22 2009
From: guido at python.org (Guido van Rossum)
Date: Wed, 2 Sep 2009 07:15:22 -0700
Subject: [Python-ideas] [Python-Dev] Decorator syntax
In-Reply-To: <4A9E54A1.4060408@gmail.com>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>
	<126B4B7C-38AF-45DF-B5F2-DB146E7146C8@masklinn.net> 
	<4A9E54A1.4060408@gmail.com>
Message-ID: <ca471dc20909020715y20a7daccua19dffde79fb6a74@mail.gmail.com>

On Wed, Sep 2, 2009 at 4:18 AM, Nick Coghlan<ncoghlan at gmail.com> wrote:
> Xavier Morel wrote:
>> On 2 Sep 2009, at 12:15 , Rob Cliffe wrote:
>>>
>>> @Identity(DecoList[0]) ? ?# THIS WORKS
>>> def foo():
>>> ? ?pass
>> For what it's worth, you don't need an id function, you can simply write
>>
>> ? ? @itemgetter(0)(decorators)
>> ? ? def foo():
>> ? ? ? ? 'whatever'
>> or
>>
>> ? ? @decorators.__getitem__(0)
>> ? ? def foo():
>> ? ? ? ? 'whatever'
>
> To be honest, I'd forgotten the restriction was even there. So +0 on
> removing it and relying on "consenting adults" and style guides to keep
> people from getting to obscure with their decorators.
>
> However, any such change should also be accompanied by an update to PEP
> 8 (recommending the current syntactic restrictions as style rules for
> the standard library).

To be honest, I'm still -0 on allowing full expression syntax, but I'm
fine allowing @foo[expr]. Decorators are syntactic sugar that make
existing functionality more readable. I don't think that allowing
complex expressions in the decorator furthers that goal.

After all the solution is always only one line away:

helper = <complicated expression>
@helper
def func(args):
  body

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From g.brandl at gmx.net  Thu Sep  3 01:09:33 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 02 Sep 2009 23:09:33 +0000
Subject: [Python-ideas] Decorator syntax
In-Reply-To: <4A9E9F26.8030608@mrabarnett.plus.com>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>	<E3E4B628-7F91-40C2-9036-16863D836BE7@fuhm.net>
	<4A9E9F26.8030608@mrabarnett.plus.com>
Message-ID: <h7mn1m$oel$1@ger.gmane.org>

MRAB schrieb:
> James Y Knight wrote:
>> On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
>> 
>>> So - the syntax restriction seems not only inconsistent, but 
>>> pointless; it doesn't forbid anything, but merely means we have to do 
>>> it in a slightly convoluted (unPythonesque) way.  So please, Guido, 
>>> will you reconsider?
>> 
>> Indeed, it's a silly inconsistent restriction. When it was first added I 
>> too suggested that any expression be allowed after the @, rather than 
>> having a uniquely special restricted syntax. I argued from consistency 
>> of grammar standpoint. But Guido was not persuaded. Good luck to you. :)
>> 
> [snip]
> I can see no syntactic reason to restrict what can appear after the @.
> If someone chooses to abuse it then that's unPythonic, but not illegal.

I do see a reason.  I have no problems with

   @foo.bar
   @foo.bar[baz]
   @foo.bar(baz)

But this is ugly to me:

   @a + b
   def foo(): pass

As is this:

   @a or (c and d)
   def foo(): pass

Having the decorator expression "opened" by @ but not "closed" feels bad.

However, this looks better to me:

   @(a + b)
   @(a or (c and d))

So, in terms of Grammar/Grammar, what about

   decorator: '@' atom trailer* NEWLINE


[x-post to ideas list]

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From python at mrabarnett.plus.com  Wed Sep  2 23:42:33 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Wed, 02 Sep 2009 22:42:33 +0100
Subject: [Python-ideas] Decorator syntax
In-Reply-To: <h7mn1m$oel$1@ger.gmane.org>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>	<E3E4B628-7F91-40C2-9036-16863D836BE7@fuhm.net>	<4A9E9F26.8030608@mrabarnett.plus.com>
	<h7mn1m$oel$1@ger.gmane.org>
Message-ID: <4A9EE6C9.4050808@mrabarnett.plus.com>

Georg Brandl wrote:
> MRAB schrieb:
>> James Y Knight wrote:
>>> On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
>>>
>>>> So - the syntax restriction seems not only inconsistent, but 
>>>> pointless; it doesn't forbid anything, but merely means we have to do 
>>>> it in a slightly convoluted (unPythonesque) way.  So please, Guido, 
>>>> will you reconsider?
>>> Indeed, it's a silly inconsistent restriction. When it was first added I 
>>> too suggested that any expression be allowed after the @, rather than 
>>> having a uniquely special restricted syntax. I argued from consistency 
>>> of grammar standpoint. But Guido was not persuaded. Good luck to you. :)
>>>
>> [snip]
>> I can see no syntactic reason to restrict what can appear after the @.
>> If someone chooses to abuse it then that's unPythonic, but not illegal.
> 
> I do see a reason.  I have no problems with
> 
>    @foo.bar
>    @foo.bar[baz]
>    @foo.bar(baz)
> 
> But this is ugly to me:
> 
>    @a + b
>    def foo(): pass
> 
Ugly, yes.

> As is this:
> 
>    @a or (c and d)
>    def foo(): pass
> 
Agreed.

> Having the decorator expression "opened" by @ but not "closed" feels bad.
> 
But:

     @foo

isn't "closed" either.

> However, this looks better to me:
> 
>    @(a + b)
>    @(a or (c and d))
> 
Conditions in 'if' and 'while' statements don't need parentheses, so why
do decorators?

> So, in terms of Grammar/Grammar, what about
> 
>    decorator: '@' atom trailer* NEWLINE
> 
I say "keep it clean", ie no parentheses except where operator priority 
or clarity require them.

IMHO, if a user writes something that's ugly then call it unPythonic;
consenting adults and all that. :-)


From ncoghlan at gmail.com  Thu Sep  3 00:22:46 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 03 Sep 2009 08:22:46 +1000
Subject: [Python-ideas] Decorator syntax
In-Reply-To: <4A9EE6C9.4050808@mrabarnett.plus.com>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>	<E3E4B628-7F91-40C2-9036-16863D836BE7@fuhm.net>	<4A9E9F26.8030608@mrabarnett.plus.com>	<h7mn1m$oel$1@ger.gmane.org>
	<4A9EE6C9.4050808@mrabarnett.plus.com>
Message-ID: <4A9EF036.1080404@gmail.com>

MRAB wrote:
>> However, this looks better to me:
>>
>>    @(a + b)
>>    @(a or (c and d))
>>
> Conditions in 'if' and 'while' statements don't need parentheses, so why
> do decorators?

Those are already closed by the colon so requiring parentheses would be
redundant:

 if a + b:
 while a + b:

The minimalist tweak would be to follow Guido's preference and just
accept subscripting in addition to calls.

>> So, in terms of Grammar/Grammar, what about
>>
>>    decorator: '@' atom trailer* NEWLINE
>>
> I say "keep it clean", ie no parentheses except where operator priority
> or clarity require them.

I actually agree with Georg that this is a case where clarity favours
enforced parentheses for expressions that are otherwise non-atomic.
Things like variable references, function calls and subscripting are
already atomic so the parentheses would be optional in those cases.

However, as long as Guido remains -0 extension to arbitrary expressions
isn't going to happen, parentheses or no parentheses.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From python at mrabarnett.plus.com  Thu Sep  3 00:36:11 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Wed, 02 Sep 2009 23:36:11 +0100
Subject: [Python-ideas] Decorator syntax
In-Reply-To: <4A9EF036.1080404@gmail.com>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>	<E3E4B628-7F91-40C2-9036-16863D836BE7@fuhm.net>	<4A9E9F26.8030608@mrabarnett.plus.com>	<h7mn1m$oel$1@ger.gmane.org>
	<4A9EE6C9.4050808@mrabarnett.plus.com> <4A9EF036.1080404@gmail.com>
Message-ID: <4A9EF35B.7040908@mrabarnett.plus.com>

Nick Coghlan wrote:
> MRAB wrote:
>>> However, this looks better to me:
>>>
>>>    @(a + b)
>>>    @(a or (c and d))
>>>
>> Conditions in 'if' and 'while' statements don't need parentheses, so why
>> do decorators?
> 
> Those are already closed by the colon so requiring parentheses would be
> redundant:
> 
>  if a + b:
>  while a + b:
> 
I forgot about 'return':

     return a + b

> The minimalist tweak would be to follow Guido's preference and just
> accept subscripting in addition to calls.
> 
>>> So, in terms of Grammar/Grammar, what about
>>>
>>>    decorator: '@' atom trailer* NEWLINE
>>>
>> I say "keep it clean", ie no parentheses except where operator priority
>> or clarity require them.
> 
> I actually agree with Georg that this is a case where clarity favours
> enforced parentheses for expressions that are otherwise non-atomic.
> Things like variable references, function calls and subscripting are
> already atomic so the parentheses would be optional in those cases.
> 
> However, as long as Guido remains -0 extension to arbitrary expressions
> isn't going to happen, parentheses or no parentheses.
> 


From tjreedy at udel.edu  Thu Sep  3 09:28:12 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 03 Sep 2009 03:28:12 -0400
Subject: [Python-ideas] Decorator syntax
In-Reply-To: <h7mn1m$oel$1@ger.gmane.org>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>	<E3E4B628-7F91-40C2-9036-16863D836BE7@fuhm.net>	<4A9E9F26.8030608@mrabarnett.plus.com>
	<h7mn1m$oel$1@ger.gmane.org>
Message-ID: <h7nr6b$el7$1@ger.gmane.org>

Georg Brandl wrote:

>    @foo.bar
>    @foo.bar[baz]

To me, this is easier to read (conceptualize), because it simply selects 
a metafunction, than the current

>    @foo.bar(baz)

, which calls a metafunction that creates and returns a metafunction.
So I hope it gets added if not too difficult.

I have some sympathy for Guido's position that anything more complicated 
should be split into two lines. That should be mentioned in the docs 
whether or not @f[i] is added.

tjr



From g.brandl at gmx.net  Thu Sep  3 13:27:05 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 03 Sep 2009 13:27:05 +0200
Subject: [Python-ideas] Decorator syntax
In-Reply-To: <4A9EE6C9.4050808@mrabarnett.plus.com>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>	<E3E4B628-7F91-40C2-9036-16863D836BE7@fuhm.net>	<4A9E9F26.8030608@mrabarnett.plus.com>	<h7mn1m$oel$1@ger.gmane.org>
	<4A9EE6C9.4050808@mrabarnett.plus.com>
Message-ID: <h7o28j$3fr$1@ger.gmane.org>

MRAB schrieb:

>> I do see a reason.  I have no problems with
>> 
>>    @foo.bar
>>    @foo.bar[baz]
>>    @foo.bar(baz)
>> 
>> But this is ugly to me:
>> 
>>    @a + b
>>    def foo(): pass
>> 
> Ugly, yes.
> 
>> As is this:
>> 
>>    @a or (c and d)
>>    def foo(): pass
>> 
> Agreed.

Good :)

>> Having the decorator expression "opened" by @ but not "closed" feels bad.
>> 
> But:
> 
>      @foo
> 
> isn't "closed" either.

Hmm, the above is probably a bad expression of my "feeling" :) but I think
you know what I mean.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From stefan_ml at behnel.de  Fri Sep  4 11:35:57 2009
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 04 Sep 2009 11:35:57 +0200
Subject: [Python-ideas] data structures should have an .any() method
Message-ID: <h7qn1t$njk$1@ger.gmane.org>

Hi,

I just had a discussion with a co-worker, and we noticed that there are use
cases where you just want the only element in a data structure, or just any
of the elements in a data structure because you know that they all contain
the same information (with respect to what you are looking for, at least).

If you want all items, you can iterate, but if you just want any item or
the only item, it's inefficient (and not very explicit code) to create an
iterator and take the element out. It's easy to do with ordered data
structures such as lists or tuples ("container[0]"), but it's not so
obvious for sets (or dicts), which means that you have to know what kind of
container you receive to handle it correctly. I know there's .pop() on
sets, but that modifies the data structure.

It would therefore be nice to have a common ".any()" method on data
structures that would just read an arbitrary item from a container.

Regarding the special (and probably minor use) case of dicts, I assume it
would return any key, so that you could get the value from the dict in a
second step if you want. Only returning the value would not easily get you
the key itself.

Stefan



From masklinn at masklinn.net  Fri Sep  4 11:48:43 2009
From: masklinn at masklinn.net (Masklinn)
Date: Fri, 4 Sep 2009 11:48:43 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7qn1t$njk$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
Message-ID: <9BE99220-8FEB-4314-B0C9-C49D1AA0D99D@masklinn.net>

On 4 Sep 2009, at 11:35 , Stefan Behnel wrote:
Hi,
>
> I just had a discussion with a co-worker, and we noticed that there  
> are use
> cases where you just want the only element in a data structure, or  
> just any
> of the elements in a data structure because you know that they all  
> contain
> the same information (with respect to what you are looking for, at  
> least).
>
> If you want all items, you can iterate, but if you just want any  
> item or
> the only item, it's inefficient (and not very explicit code) to  
> create an
> iterator and take the element out. It's easy to do with ordered data
> structures such as lists or tuples ("container[0]"), but it's not so
> obvious for sets (or dicts), which means that you have to know what  
> kind of
> container you receive to handle it correctly. I know there's .pop() on
> sets, but that modifies the data structure.
>
> It would therefore be nice to have a common ".any()" method on data
> structures that would just read an arbitrary item from a container.
>
> Regarding the special (and probably minor use) case of dicts, I  
> assume it
> would return any key, so that you could get the value from the dict  
> in a
> second step if you want. Only returning the value would not easily  
> get you
> the key itself.
Given the random value you want from the dict is a key, how about  
`random.choice(list(container))` (list is needed because choice works  
on sequences)?

 >>> l, s, d
([0, 1, 2, 3, 4], set([8, 9, 5, 6, 7]), {10: 15, 11: 16, 12: 17, 13:  
18, 14: 19})
 >>> choice(list(l))
4
 >>> choice(list(s))
8
 >>> choice(list(d))
14


From matteodellamico at gmail.com  Fri Sep  4 11:55:05 2009
From: matteodellamico at gmail.com (Matteo Dell'Amico)
Date: Fri, 04 Sep 2009 11:55:05 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7qn1t$njk$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
Message-ID: <4AA0E3F9.9010904@gmail.com>

Stefan Behnel ha scritto:
> Hi,
> 
> I just had a discussion with a co-worker, and we noticed that there are use
> cases where you just want the only element in a data structure, or just any
> of the elements in a data structure because you know that they all contain
> the same information (with respect to what you are looking for, at least).
> 
> If you want all items, you can iterate, but if you just want any item or
> the only item, it's inefficient (and not very explicit code) to create an
> iterator and take the element out. It's easy to do with ordered data
> structures such as lists or tuples ("container[0]"), but it's not so
> obvious for sets (or dicts), which means that you have to know what kind of
> container you receive to handle it correctly. I know there's .pop() on
> sets, but that modifies the data structure.

You can do next(iter(container)) (or iter(container).next() with python 
<= 2.5). This works fine with any iterable.

matteo


From ncoghlan at gmail.com  Fri Sep  4 12:03:21 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 04 Sep 2009 20:03:21 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7qn1t$njk$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
Message-ID: <4AA0E5E9.2050202@gmail.com>

Stefan Behnel wrote:
> It would therefore be nice to have a common ".any()" method on data
> structures that would just read an arbitrary item from a container.

I'd advise against bare name "any" for this, since we already have the
any() builtin with a completely different meaning. "getany" would
probably be OK though.

I'd also advise against using a method for this, since there is a
reasonable default implementation that can be employed:

def getany(container)
  if container:
    if isinstance(container, collections.Sequence):
      return container[0]
    else:
      for x in container:
        return x
  raise ValueError("No items in container")

Finally, I'd suggest that any such function would belong in the
collections module rather than being made a builtin.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From zuo at chopin.edu.pl  Fri Sep  4 12:32:05 2009
From: zuo at chopin.edu.pl (Jan Kaliszewski)
Date: Fri, 04 Sep 2009 12:32:05 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA0E5E9.2050202@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E5E9.2050202@gmail.com>
Message-ID: <op.uzp97rn5fvx12t@jerzozwiesz.home.aster.pl>

04-09-2009 Nick Coghlan <ncoghlan at gmail.com> wrote:

> def getany(container)
>   if container:
>     if isinstance(container, collections.Sequence):
>       return container[0]
>     else:
>       for x in container:
>         return x
>   raise ValueError("No items in container")

or simpler:

     def getany(container):
         try:
             return next(iter(container))
         except StopIteration
             raise ValueError("No items in container")

-- 
Jan Kaliszewski (zuo) <zuo at chopin.edu.pl>


From stefan_ml at behnel.de  Fri Sep  4 13:12:02 2009
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 04 Sep 2009 13:12:02 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <op.uzp97rn5fvx12t@jerzozwiesz.home.aster.pl>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E5E9.2050202@gmail.com>
	<op.uzp97rn5fvx12t@jerzozwiesz.home.aster.pl>
Message-ID: <h7qsm2$8p0$1@ger.gmane.org>

Jan Kaliszewski wrote:
> 04-09-2009 Nick Coghlan
> <ncoghlan at gmail.com> wrote:
> 
>> def getany(container)
>>   if container:
>>     if isinstance(container, collections.Sequence):
>>       return container[0]
>>     else:
>>       for x in container:
>>         return x
>>   raise ValueError("No items in container")
> 
> or simpler:
> 
>     def getany(container):
>         try:
>             return next(iter(container))
>         except StopIteration
>             raise ValueError("No items in container")

or:

     def getany(container):
         for x in container:
             return x
         raise ValueError("No items in container")

I actually like that, although I find this more readable:

     def getany(container):
         for x in container:
             return x
         else:
             raise ValueError("No items in container")

Stefan



From ncoghlan at gmail.com  Fri Sep  4 13:50:11 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 04 Sep 2009 21:50:11 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA0E3F9.9010904@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
Message-ID: <4AA0FEF3.2000607@gmail.com>

Matteo Dell'Amico wrote:
> You can do next(iter(container)) (or iter(container).next() with python
> <= 2.5). This works fine with any iterable.

This and other responses miss part of Stefan's complaint: that creating
an iterator (which isn't always cheap) only to throw it away almost
immediately may be a somewhat wasteful operation.

The shorthand expression above also suffers from the obscurity that
Stefan was complaining about - there is very little to hint that
"next(iter(obj))" means "get an arbitrary object out of a container".
The StopIteration exception this approach will throw for an empty
container is also rather unhelpful.

That said, I'm -0 on the idea overall. If someone actually needs it, it
isn't particularly hard for them to write their own getany() function.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From matteodellamico at gmail.com  Fri Sep  4 14:01:28 2009
From: matteodellamico at gmail.com (Matteo Dell'Amico)
Date: Fri, 04 Sep 2009 14:01:28 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA0FEF3.2000607@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com>
Message-ID: <4AA10198.8040401@gmail.com>

Nick Coghlan ha scritto:

> This and other responses miss part of Stefan's complaint: that creating
> an iterator (which isn't always cheap) only to throw it away almost
> immediately may be a somewhat wasteful operation.

It's not particularly wasteful for the built-in data structures, though.
It seems to me that the cases where the performance of next(iter(obj)) 
would be an actual issue are quite rare.

> The shorthand expression above also suffers from the obscurity that
> Stefan was complaining about - there is very little to hint that
> "next(iter(obj))" means "get an arbitrary object out of a container".
> The StopIteration exception this approach will throw for an empty
> container is also rather unhelpful.

Why? next(iter(obj)) means, pretty explicitly to me, "iterate on obj and 
give me one element".

matteo


From ncoghlan at gmail.com  Fri Sep  4 14:17:09 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 04 Sep 2009 22:17:09 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA10198.8040401@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com>
Message-ID: <4AA10545.30408@gmail.com>

Matteo Dell'Amico wrote:
>> The shorthand expression above also suffers from the obscurity that
>> Stefan was complaining about - there is very little to hint that
>> "next(iter(obj))" means "get an arbitrary object out of a container".
>> The StopIteration exception this approach will throw for an empty
>> container is also rather unhelpful.
> 
> Why? next(iter(obj)) means, pretty explicitly to me, "iterate on obj and
> give me one element".

Because it overspecifies the semantics of what you're trying to do. It
just happens that when the requirement is "get me any object in this
container" the design of Python means that the easiest implementation is
"get me the first object in this container".

The expression form then reflects the implementation rather than the
algorithmic intent.

That said, this concise way of implementing the desired feature is
certainly one of the reasons I am -0 on the idea of adding it to the
standard library.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From zuo at chopin.edu.pl  Fri Sep  4 15:01:02 2009
From: zuo at chopin.edu.pl (Jan Kaliszewski)
Date: Fri, 04 Sep 2009 15:01:02 +0200
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
Message-ID: <op.uzqg30bafvx12t@jerzozwiesz.home.aster.pl>

[originally from python-list at python.org,
  crossposted to python-ideas at python.org]

04-09-2009 o 00:46:01 Ken Newton <krnewton at gmail.com> wrote:

> I have created the following class definition with the idea of making
> a clean syntax for non-programmers to created structured data within a
> python environment.
>
> I would appreciate comments on this code. First, is something like
> this already done? Second, are there reasons for not doing this?  If
> this seems OK, how could I clean up the string conversion to have
> indented format.
>
> The expected use would have all items in the structure be simple
> python types or AttrClass types. Code written in python could walk the
> structure in a simple way to locate any desired values. Code in a
> C/C++ extension should also be able to walk the structure to use any
> value in the structure.
>
> class AttrClass(object):
>     """AttrClass lets you freely add attributes in nested manner"""
>
>     def __init__(self):
>         pass
>     def __setitem__(self, key, value):
>         return self.__dict__.__setitem__(key, value)
>     def __repr__(self):
>         return "%s(%s)" % (self.__class__.__name__,  
> self.__dict__.__repr__())
>     def __str__(self):
>         ll = ['{']
>         for k,v in self.__dict__.iteritems():
>             ll.append("%s : %s" % (k, str(v)))
>         return '\n'.join(ll) + '}'
[snip]

I find the idea interesting and close to my own needs in many
situations, if I could alter it a bit.

Of course, we always can use an empty class ('class MyStruct: pass')
or simply use a dict... But both methods are inconvinient in some
ways.

In the case of dict we are convicted -- even when we need static
access -- to mapping notation (obj['member']) which is less
convenient and (what's more important) more error-prone than
attribute dot-notation.

In the case of empty class/object we can use convenient attr
dot-notation but dynamic access is less natural...

IMHO there could be -- in collections module or even as a built-in
factory function -- something (somehow) similar to namedtuple, but
mutable and more dict-like. I'am less focused on nesting such
structures, and more on making it a namespace-like objects with
convenience-and-today-usage features. Please consider the code:


   class AttrDict(dict):  # (or maybe from OrderedDict)
       "It's only a model. (Shhh!)"

       def __getattr__(self, name):
           if name.startswith('_'):
               raise AttributeError("AttrDict's key can't "
                                    "start with underscore")
           else:
               return self[name]

       def __setattr__(self, name, value):
           self[name] = value

       def __delattr__(self, name):
           del self[name]

       def __repr__(self):
           return '{0}({1})'.format(self.__class__.__name__,
                                      dict.__repr__(self))
       def __str__(self):
           return self._as_str()

       def _gen_format(self, indwidth, indstate):
           indst = indstate * ' '
           ind = (indstate + indwidth) * ' '
           yield ('\n' + indst + '{' if indstate else '{')
           for key, val in self.items():
               valstr = (str(val) if not isinstance(val, AttrDict)
                         else val._as_str(indwidth, indstate + indwidth))
               yield '{ind}{key}: {valstr}'.format(ind=ind, key=key,
                                                   valstr=valstr)
           yield indst + '}'

       def _as_str(self, indwidth=4, indstate=0):
           return '\n'.join(self._gen_format(indwidth, indstate))

       def _as_dict(self):
           return dict.copy(self)


   # Test code:
   if __name__ == '__main__':
       struct = AttrDict()
       struct.first = 1
       struct.second = 2.0
       struct.third = '3rd'
       struct.fourth = [4]
       print(struct)
       # output:
       # {
       #     'second': 2.0
       #     'fourth': [4]
       #     'third': '3rd'
       #     'first': 1
       # }

       del struct.fourth

       print(repr(struct))
       # output:
       # AttrDict({'second': 2.0, 'third': '3rd', 'first': 1})

       print(struct.first)  # (static access)
       # output:
       # 1

       for x in ('first', 'second', 'third'):
           print(struct[x])  # (dynamic access)
       # output:
       # 1
       # 2.0
       # 3rd

       struct.sub = AttrDict(a=1, b=2, c=89)
       print(struct._as_dict())
       # output:
       # {'second': 2.0, 'sub': AttrDict({'a': 1, 'c': 89, 'b': 2}),\
       #                                  'third': '3rd', 'first': 1}

       print(struct._as_str(8))
       # output:
       # {
       #         second: 2.0
       #         sub:
       #         {
       #                 a: 1
       #                 c: 89
       #                 b: 2
       #         }
       #         third: 3rd
       #         first: 1
       # }


What do you think about it?

Cheers,
*j

-- 
Jan Kaliszewski (zuo) <zuo at chopin.edu.pl>


From ilya.nikokoshev at gmail.com  Fri Sep  4 15:29:30 2009
From: ilya.nikokoshev at gmail.com (ilya)
Date: Fri, 4 Sep 2009 17:29:30 +0400
Subject: [Python-ideas] Decorator syntax
In-Reply-To: <h7o28j$3fr$1@ger.gmane.org>
References: <A5DBADE2151C40D8BF1E590DF868DA8D@robslaptop>
	<E3E4B628-7F91-40C2-9036-16863D836BE7@fuhm.net>
	<4A9E9F26.8030608@mrabarnett.plus.com> <h7mn1m$oel$1@ger.gmane.org>
	<4A9EE6C9.4050808@mrabarnett.plus.com> <h7o28j$3fr$1@ger.gmane.org>
Message-ID: <d8cc6f9d0909040629s2c2996dcm656b3f28fa0574d2@mail.gmail.com>

I would say here are two more things to consider:

(1) How to colorize expression @a or b and c? My IDE colorizes only @a
as decorator

(2) How to search for all functions that have been applied decorator
`b` (*not* either `a` or `b`)?

(bonus) How to test expression of the above form? By definition, you
will have only *one* function decorated like that. To test it, you
should define it as a separate function anyway.

ilya.

On Thu, Sep 3, 2009 at 3:27 PM, Georg Brandl<g.brandl at gmx.net> wrote:
> MRAB schrieb:
>
>>> I do see a reason. ?I have no problems with
>>>
>>> ? ?@foo.bar
>>> ? ?@foo.bar[baz]
>>> ? ?@foo.bar(baz)
>>>
>>> But this is ugly to me:
>>>
>>> ? ?@a + b
>>> ? ?def foo(): pass
>>>
>> Ugly, yes.
>>
>>> As is this:
>>>
>>> ? ?@a or (c and d)
>>> ? ?def foo(): pass
>>>
>> Agreed.
>
> Good :)
>
>>> Having the decorator expression "opened" by @ but not "closed" feels bad.
>>>
>> But:
>>
>> ? ? ?@foo
>>
>> isn't "closed" either.
>
> Hmm, the above is probably a bad expression of my "feeling" :) but I think
> you know what I mean.
>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From ilya.nikokoshev at gmail.com  Fri Sep  4 15:35:47 2009
From: ilya.nikokoshev at gmail.com (ilya)
Date: Fri, 4 Sep 2009 17:35:47 +0400
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA10545.30408@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com>
	<4AA10545.30408@gmail.com>
Message-ID: <d8cc6f9d0909040635j6eb6ed21t3df14afba058d3d7@mail.gmail.com>

I think dict.popitem() does something close to what the original post wanted.

http://docs.python.org/3.1/library/stdtypes.html#dict.popitem

On Fri, Sep 4, 2009 at 4:17 PM, Nick Coghlan<ncoghlan at gmail.com> wrote:
> Matteo Dell'Amico wrote:
>>> The shorthand expression above also suffers from the obscurity that
>>> Stefan was complaining about - there is very little to hint that
>>> "next(iter(obj))" means "get an arbitrary object out of a container".
>>> The StopIteration exception this approach will throw for an empty
>>> container is also rather unhelpful.
>>
>> Why? next(iter(obj)) means, pretty explicitly to me, "iterate on obj and
>> give me one element".
>
> Because it overspecifies the semantics of what you're trying to do. It
> just happens that when the requirement is "get me any object in this
> container" the design of Python means that the easiest implementation is
> "get me the first object in this container".
>
> The expression form then reflects the implementation rather than the
> algorithmic intent.
>
> That said, this concise way of implementing the desired feature is
> certainly one of the reasons I am -0 on the idea of adding it to the
> standard library.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan ? | ? ncoghlan at gmail.com ? | ? Brisbane, Australia
> ---------------------------------------------------------------
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From gerald.britton at gmail.com  Fri Sep  4 15:47:54 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Fri, 4 Sep 2009 09:47:54 -0400
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <d8cc6f9d0909040635j6eb6ed21t3df14afba058d3d7@mail.gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com> 
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com> 
	<4AA10545.30408@gmail.com>
	<d8cc6f9d0909040635j6eb6ed21t3df14afba058d3d7@mail.gmail.com>
Message-ID: <5d1a32000909040647u20889e1do296d31d8c3f45ac4@mail.gmail.com>

Though IIRC the OP doesn't want to delete the item, so you would need
something like:

key, data = dict.popitem(); dict[key] = data


On Fri, Sep 4, 2009 at 9:35 AM, ilya<ilya.nikokoshev at gmail.com> wrote:
> I think dict.popitem() does something close to what the original post wanted.
>
> http://docs.python.org/3.1/library/stdtypes.html#dict.popitem
>
> On Fri, Sep 4, 2009 at 4:17 PM, Nick Coghlan<ncoghlan at gmail.com> wrote:
>> Matteo Dell'Amico wrote:
>>>> The shorthand expression above also suffers from the obscurity that
>>>> Stefan was complaining about - there is very little to hint that
>>>> "next(iter(obj))" means "get an arbitrary object out of a container".
>>>> The StopIteration exception this approach will throw for an empty
>>>> container is also rather unhelpful.
>>>
>>> Why? next(iter(obj)) means, pretty explicitly to me, "iterate on obj and
>>> give me one element".
>>
>> Because it overspecifies the semantics of what you're trying to do. It
>> just happens that when the requirement is "get me any object in this
>> container" the design of Python means that the easiest implementation is
>> "get me the first object in this container".
>>
>> The expression form then reflects the implementation rather than the
>> algorithmic intent.
>>
>> That said, this concise way of implementing the desired feature is
>> certainly one of the reasons I am -0 on the idea of adding it to the
>> standard library.
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan ? | ? ncoghlan at gmail.com ? | ? Brisbane, Australia
>> ---------------------------------------------------------------
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From ncoghlan at gmail.com  Fri Sep  4 16:59:32 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 05 Sep 2009 00:59:32 +1000
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <op.uzqg30bafvx12t@jerzozwiesz.home.aster.pl>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<op.uzqg30bafvx12t@jerzozwiesz.home.aster.pl>
Message-ID: <4AA12B54.3070604@gmail.com>

Jan Kaliszewski wrote:
> What do you think about it?

It reminds me a bit of the old (short-lived) namespaces module:

http://web.archive.org/web/20060216094030/http://namespace.python-hosting.com/

Steven's draft PEP on the topic is still available in the python-list
archives:

http://mail.python.org/pipermail/python-list/2005-February/307235.html

The problem we found with it was that the basic solutions (empty class
and now named_tuple) were good enough that it wasn't worth the hassle
involved in grabbing an extra library for it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From guido at python.org  Fri Sep  4 20:04:34 2009
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Sep 2009 11:04:34 -0700
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7qn1t$njk$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
Message-ID: <ca471dc20909041104t2f6d8776pefe680b8b2199ae0@mail.gmail.com>

On Fri, Sep 4, 2009 at 2:35 AM, Stefan Behnel<stefan_ml at behnel.de> wrote:
> I just had a discussion with a co-worker, and we noticed that there are use
> cases where you just want the only element in a data structure, or just any
> of the elements in a data structure because you know that they all contain
> the same information (with respect to what you are looking for, at least).
>
> If you want all items, you can iterate, but if you just want any item or
> the only item, it's inefficient (and not very explicit code) to create an
> iterator and take the element out.

I assure you it's not slow. next(iter(x)) is probably as good as it
gets -- I don't think we need another way to say that in fewer words.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From stefan_ml at behnel.de  Fri Sep  4 21:36:57 2009
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 04 Sep 2009 21:36:57 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <ca471dc20909041104t2f6d8776pefe680b8b2199ae0@mail.gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org>
	<ca471dc20909041104t2f6d8776pefe680b8b2199ae0@mail.gmail.com>
Message-ID: <h7rq8p$br8$1@ger.gmane.org>

Guido van Rossum wrote:
> On Fri, Sep 4, 2009 at 2:35 AM, Stefan Behnel wrote:
>> I just had a discussion with a co-worker, and we noticed that there are use
>> cases where you just want the only element in a data structure, or just any
>> of the elements in a data structure because you know that they all contain
>> the same information (with respect to what you are looking for, at least).
>>
>> If you want all items, you can iterate, but if you just want any item or
>> the only item, it's inefficient (and not very explicit code) to create an
>> iterator and take the element out.
> 
> I assure you it's not slow.

Not in absolute numbers, but certainly slower than necessary:

$ python2.6 -m timeit -s 'l=[1]' 'l[0]'
10000000 loops, best of 3: 0.0977 usec per loop

$ python2.6 -m timeit -s 'l=[1]' 'next(iter(l))'
1000000 loops, best of 3: 0.523 usec per loop


> next(iter(x)) is probably as good as it
> gets -- I don't think we need another way to say that in fewer words.

I'm fine with such a decision, given that it's trivial to wrap this into
your own function. That doesn't make it much faster:


$ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):'
                                 -s '  return l[0]'
                      'getany(l)'
1000000 loops, best of 3: 0.34 usec per loop

$ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
                                 -s '  for x in l:' \
                                 -s '    return x' \
                      'getany(l)'
1000000 loops, best of 3: 0.454 usec per loop

$ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
                                 -s '  return next(iter(l))' \
                      'getany(l)'
1000000 loops, best of 3: 0.743 usec per loop


but, admittedly, that's still not slow in absolute numbers.

Stefan



From gerald.britton at gmail.com  Fri Sep  4 21:56:19 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Fri, 4 Sep 2009 15:56:19 -0400
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7rq8p$br8$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
	<ca471dc20909041104t2f6d8776pefe680b8b2199ae0@mail.gmail.com> 
	<h7rq8p$br8$1@ger.gmane.org>
Message-ID: <5d1a32000909041256k6af5c87fv9a42e0655e7a4155@mail.gmail.com>

Interesting that your return(next()) example runs about 60% slower
than the "for x in l: return x" example.  Must be the function call
overhead.

On Fri, Sep 4, 2009 at 3:36 PM, Stefan Behnel<stefan_ml at behnel.de> wrote:
> Guido van Rossum wrote:
>> On Fri, Sep 4, 2009 at 2:35 AM, Stefan Behnel wrote:
>>> I just had a discussion with a co-worker, and we noticed that there are use
>>> cases where you just want the only element in a data structure, or just any
>>> of the elements in a data structure because you know that they all contain
>>> the same information (with respect to what you are looking for, at least).
>>>
>>> If you want all items, you can iterate, but if you just want any item or
>>> the only item, it's inefficient (and not very explicit code) to create an
>>> iterator and take the element out.
>>
>> I assure you it's not slow.
>
> Not in absolute numbers, but certainly slower than necessary:
>
> $ python2.6 -m timeit -s 'l=[1]' 'l[0]'
> 10000000 loops, best of 3: 0.0977 usec per loop
>
> $ python2.6 -m timeit -s 'l=[1]' 'next(iter(l))'
> 1000000 loops, best of 3: 0.523 usec per loop
>
>
>> next(iter(x)) is probably as good as it
>> gets -- I don't think we need another way to say that in fewer words.
>
> I'm fine with such a decision, given that it's trivial to wrap this into
> your own function. That doesn't make it much faster:
>
>
> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):'
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?return l[0]'
> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
> 1000000 loops, best of 3: 0.34 usec per loop
>
> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?for x in l:' \
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ? ?return x' \
> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
> 1000000 loops, best of 3: 0.454 usec per loop
>
> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?return next(iter(l))' \
> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
> 1000000 loops, best of 3: 0.743 usec per loop
>
>
> but, admittedly, that's still not slow in absolute numbers.
>
> Stefan
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From gerald.britton at gmail.com  Fri Sep  4 22:01:14 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Fri, 4 Sep 2009 16:01:14 -0400
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <5d1a32000909041256k6af5c87fv9a42e0655e7a4155@mail.gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org>
	<ca471dc20909041104t2f6d8776pefe680b8b2199ae0@mail.gmail.com> 
	<h7rq8p$br8$1@ger.gmane.org>
	<5d1a32000909041256k6af5c87fv9a42e0655e7a4155@mail.gmail.com>
Message-ID: <5d1a32000909041301h52dd7e17se53bb3da05376218@mail.gmail.com>

Also interesting that:

def getany(x):
  k,d = x.popitem()
  x[k] = d
  return k

outperforms the next(iter()) approach, though not by much (< 10% in my case)


On Fri, Sep 4, 2009 at 3:56 PM, Gerald Britton<gerald.britton at gmail.com> wrote:
> Interesting that your return(next()) example runs about 60% slower
> than the "for x in l: return x" example. ?Must be the function call
> overhead.
>
> On Fri, Sep 4, 2009 at 3:36 PM, Stefan Behnel<stefan_ml at behnel.de> wrote:
>> Guido van Rossum wrote:
>>> On Fri, Sep 4, 2009 at 2:35 AM, Stefan Behnel wrote:
>>>> I just had a discussion with a co-worker, and we noticed that there are use
>>>> cases where you just want the only element in a data structure, or just any
>>>> of the elements in a data structure because you know that they all contain
>>>> the same information (with respect to what you are looking for, at least).
>>>>
>>>> If you want all items, you can iterate, but if you just want any item or
>>>> the only item, it's inefficient (and not very explicit code) to create an
>>>> iterator and take the element out.
>>>
>>> I assure you it's not slow.
>>
>> Not in absolute numbers, but certainly slower than necessary:
>>
>> $ python2.6 -m timeit -s 'l=[1]' 'l[0]'
>> 10000000 loops, best of 3: 0.0977 usec per loop
>>
>> $ python2.6 -m timeit -s 'l=[1]' 'next(iter(l))'
>> 1000000 loops, best of 3: 0.523 usec per loop
>>
>>
>>> next(iter(x)) is probably as good as it
>>> gets -- I don't think we need another way to say that in fewer words.
>>
>> I'm fine with such a decision, given that it's trivial to wrap this into
>> your own function. That doesn't make it much faster:
>>
>>
>> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):'
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?return l[0]'
>> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
>> 1000000 loops, best of 3: 0.34 usec per loop
>>
>> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?for x in l:' \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ? ?return x' \
>> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
>> 1000000 loops, best of 3: 0.454 usec per loop
>>
>> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?return next(iter(l))' \
>> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
>> 1000000 loops, best of 3: 0.743 usec per loop
>>
>>
>> but, admittedly, that's still not slow in absolute numbers.
>>
>> Stefan
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>
>
>
> --
> Gerald Britton
>



-- 
Gerald Britton


From zuo at chopin.edu.pl  Fri Sep  4 22:37:15 2009
From: zuo at chopin.edu.pl (Jan Kaliszewski)
Date: Fri, 04 Sep 2009 22:37:15 +0200
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <8fd67d4b0909040955k590b8d6fv9012165d847b02d9@mail.gmail.com>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<op.uzqg30bafvx12t@jerzozwiesz.home.aster.pl>
	<8fd67d4b0909040955k590b8d6fv9012165d847b02d9@mail.gmail.com>
Message-ID: <op.uzq18d1nfvx12t@jerzozwiesz.home.aster.pl>

04-09-2009 Ken Newton <krnewton at gmail.com> wrote:

> I like this version very much. I'm ready to put this into practice to see
> how it works in practice.
[snip]

Not only you (Ken) and me. :-) It appears that the idea is quite old. Nick
Coghlan replied at python-ideas at python.org:

> Jan Kaliszewski wrote:
>> What do you think about it?
>
> It reminds me a bit of the old (short-lived) namespaces module:
>
> http://web.archive.org/web/20060216094030/http://namespace.python-hosting.com/
>
> Steven's draft PEP on the topic is still available in the python-list
> archives:
>
> http://mail.python.org/pipermail/python-list/2005-February/307235.html
>
> The problem we found with it was that the basic solutions (empty class
> and now named_tuple) were good enough that it wasn't worth the hassle
> involved in grabbing an extra library for it.

Named tuples (which indeed are really very nice) are read-only, but the
approach they represent could (and IMHO should) be extended to some kind
of mutable objects.

The old discussion, the above link points to, shows that such a
dot-accessible dict-like class is something that many people need and
repeatedly implemet it (more or less perfectly) for themselves.

Maybe that past proposition (to add a separate namespace module which
a number types for viewing, chaining and so on) was too sophisticated?

Most common use cases could be covered with one attr-dict-like type,
that could be placed in collections module (or even, in time, as
a built-in factory function, together with namedtuple?).


Cheers,
*j


From george.sakkis at gmail.com  Fri Sep  4 23:04:55 2009
From: george.sakkis at gmail.com (George Sakkis)
Date: Fri, 4 Sep 2009 17:04:55 -0400
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <op.uzq18d1nfvx12t@jerzozwiesz.home.aster.pl>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<op.uzqg30bafvx12t@jerzozwiesz.home.aster.pl>
	<8fd67d4b0909040955k590b8d6fv9012165d847b02d9@mail.gmail.com>
	<op.uzq18d1nfvx12t@jerzozwiesz.home.aster.pl>
Message-ID: <91ad5bf80909041404t486a69dejf75ffd73a4d4a3ea@mail.gmail.com>

On Fri, Sep 4, 2009 at 4:37 PM, Jan Kaliszewski<zuo at chopin.edu.pl> wrote:
> 04-09-2009 Ken Newton <krnewton at gmail.com> wrote:
>
>> I like this version very much. I'm ready to put this into practice to see
>> how it works in practice.
>
> [snip]
>
> Not only you (Ken) and me. :-) It appears that the idea is quite old. Nick
> Coghlan replied at python-ideas at python.org:
>
>> Jan Kaliszewski wrote:
>>>
>>> What do you think about it?
>>
>> It reminds me a bit of the old (short-lived) namespaces module:
>>
>>
>> http://web.archive.org/web/20060216094030/http://namespace.python-hosting.com/
>>
>> Steven's draft PEP on the topic is still available in the python-list
>> archives:
>>
>> http://mail.python.org/pipermail/python-list/2005-February/307235.html
>>
>> The problem we found with it was that the basic solutions (empty class
>> and now named_tuple) were good enough that it wasn't worth the hassle
>> involved in grabbing an extra library for it.
>
> Named tuples (which indeed are really very nice) are read-only, but the
> approach they represent could (and IMHO should) be extended to some kind
> of mutable objects.

Maybe something like http://code.activestate.com/recipes/576555/ ?

George


From guido at python.org  Fri Sep  4 23:08:03 2009
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Sep 2009 14:08:03 -0700
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <5d1a32000909041256k6af5c87fv9a42e0655e7a4155@mail.gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org>
	<ca471dc20909041104t2f6d8776pefe680b8b2199ae0@mail.gmail.com> 
	<h7rq8p$br8$1@ger.gmane.org>
	<5d1a32000909041256k6af5c87fv9a42e0655e7a4155@mail.gmail.com>
Message-ID: <ca471dc20909041408t78c1761al3c3e023c8360f33a@mail.gmail.com>

More likely the cost of the two dynamic lookups of builtin functions
is your cost.

On Fri, Sep 4, 2009 at 12:56 PM, Gerald Britton<gerald.britton at gmail.com> wrote:
> Interesting that your return(next()) example runs about 60% slower
> than the "for x in l: return x" example. ?Must be the function call
> overhead.
>
> On Fri, Sep 4, 2009 at 3:36 PM, Stefan Behnel<stefan_ml at behnel.de> wrote:
>> Guido van Rossum wrote:
>>> On Fri, Sep 4, 2009 at 2:35 AM, Stefan Behnel wrote:
>>>> I just had a discussion with a co-worker, and we noticed that there are use
>>>> cases where you just want the only element in a data structure, or just any
>>>> of the elements in a data structure because you know that they all contain
>>>> the same information (with respect to what you are looking for, at least).
>>>>
>>>> If you want all items, you can iterate, but if you just want any item or
>>>> the only item, it's inefficient (and not very explicit code) to create an
>>>> iterator and take the element out.
>>>
>>> I assure you it's not slow.
>>
>> Not in absolute numbers, but certainly slower than necessary:
>>
>> $ python2.6 -m timeit -s 'l=[1]' 'l[0]'
>> 10000000 loops, best of 3: 0.0977 usec per loop
>>
>> $ python2.6 -m timeit -s 'l=[1]' 'next(iter(l))'
>> 1000000 loops, best of 3: 0.523 usec per loop
>>
>>
>>> next(iter(x)) is probably as good as it
>>> gets -- I don't think we need another way to say that in fewer words.
>>
>> I'm fine with such a decision, given that it's trivial to wrap this into
>> your own function. That doesn't make it much faster:
>>
>>
>> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):'
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?return l[0]'
>> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
>> 1000000 loops, best of 3: 0.34 usec per loop
>>
>> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?for x in l:' \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ? ?return x' \
>> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
>> 1000000 loops, best of 3: 0.454 usec per loop
>>
>> $ python2.6 -m timeit -s 'l=[1]' -s 'def getany(l):' \
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -s ' ?return next(iter(l))' \
>> ? ? ? ? ? ? ? ? ? ? ?'getany(l)'
>> 1000000 loops, best of 3: 0.743 usec per loop
>>
>>
>> but, admittedly, that's still not slow in absolute numbers.
>>
>> Stefan
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>
>
>
> --
> Gerald Britton
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From solipsis at pitrou.net  Sat Sep  5 04:45:13 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 5 Sep 2009 02:45:13 +0000 (UTC)
Subject: [Python-ideas] data structures should have an .any() method
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com>
	<4AA10545.30408@gmail.com>
Message-ID: <loom.20090905T044141-177@post.gmane.org>

Nick Coghlan <ncoghlan at ...> writes:
> 
> Because it overspecifies the semantics of what you're trying to do. It
> just happens that when the requirement is "get me any object in this
> container" the design of Python means that the easiest implementation is
> "get me the first object in this container".

I don't agree.
Since iteration is such a frequent operation, any container which doesn't
provide cheap iteration could be considered badly designed and/or badly
implemented. Therefore it makes sense to rely on iteration when implementing
other primitives.

People worrying that it expresses implementation rather than intent can write
the trivial abstraction by themselves:

def any_item(x):
    return next(iter(x))

Regards

Antoine.




From steve at pearwood.info  Sat Sep  5 07:17:05 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 5 Sep 2009 15:17:05 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA0E5E9.2050202@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E5E9.2050202@gmail.com>
Message-ID: <200909051517.06511.steve@pearwood.info>

On Fri, 4 Sep 2009 08:03:21 pm Nick Coghlan wrote:
> Stefan Behnel wrote:
> > It would therefore be nice to have a common ".any()" method on data
> > structures that would just read an arbitrary item from a container.
>
> I'd advise against bare name "any" for this, since we already have
> the any() builtin with a completely different meaning. "getany" would
> probably be OK though.
>
> I'd also advise against using a method for this, since there is a
> reasonable default implementation that can be employed:
>
> def getany(container)
>   if container:
>     if isinstance(container, collections.Sequence):
>       return container[0]
>     else:
>       for x in container:
>         return x
>   raise ValueError("No items in container")
>
> Finally, I'd suggest that any such function would belong in the
> collections module rather than being made a builtin.

Given the above implementation, repeated calls to getany(sequence) will 
return the same item each time. Is that what people will expect by a 
function that claims to return "any" element of a collection? I suspect 
that users will be evenly divided into those who say Yes, those who say 
No, and those who say "It depends on what I'm trying to do".

Should it return an arbitrary item, or a random item? Is "the first 
item" arbitrary enough? It should be for dicts, which are unordered, 
but may not be for lists.

I think the answers to these questions are too application-specific for 
any solution or solutions to go into the standard library. It probably 
belongs in the cookbook as a handful of related recipes.



-- 
Steven D'Aprano


From steve at pearwood.info  Sat Sep  5 11:47:46 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 5 Sep 2009 19:47:46 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA10198.8040401@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0FEF3.2000607@gmail.com>
	<4AA10198.8040401@gmail.com>
Message-ID: <200909051947.48197.steve@pearwood.info>

On Fri, 4 Sep 2009 10:01:28 pm Matteo Dell'Amico wrote:

> Why? next(iter(obj)) means, pretty explicitly to me, "iterate on obj
> and give me one element".

To me, it says "give me the first element", not "give me any (an 
arbitrary) element" or "give me a random element".

Does anyone have a use-case for retrieving a single arbitrary element of 
an arbitrary sequence, without caring about any other elements? Is this 
really such a common operation that we need to consider it part of the 
interface for all collections? I doubt it.




-- 
Steven D'Aprano


From g.brandl at gmx.net  Sat Sep  5 12:53:11 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 05 Sep 2009 12:53:11 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <loom.20090905T044141-177@post.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
	<4AA0E3F9.9010904@gmail.com>	<4AA0FEF3.2000607@gmail.com>
	<4AA10198.8040401@gmail.com>	<4AA10545.30408@gmail.com>
	<loom.20090905T044141-177@post.gmane.org>
Message-ID: <h7tg23$vdj$1@ger.gmane.org>

Antoine Pitrou schrieb:
> Nick Coghlan <ncoghlan at ...> writes:
>> 
>> Because it overspecifies the semantics of what you're trying to do. It
>> just happens that when the requirement is "get me any object in this
>> container" the design of Python means that the easiest implementation is
>> "get me the first object in this container".
> 
> I don't agree.
> Since iteration is such a frequent operation, any container which doesn't
> provide cheap iteration could be considered badly designed and/or badly
> implemented. Therefore it makes sense to rely on iteration when implementing
> other primitives.
> 
> People worrying that it expresses implementation rather than intent can write
> the trivial abstraction by themselves:
> 
> def any_item(x):
>     return next(iter(x))

or

any_item = compose(next, iter)

;)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From p.f.moore at gmail.com  Sat Sep  5 14:02:18 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 5 Sep 2009 13:02:18 +0100
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <200909051947.48197.steve@pearwood.info>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0FEF3.2000607@gmail.com>
	<4AA10198.8040401@gmail.com> <200909051947.48197.steve@pearwood.info>
Message-ID: <79990c6b0909050502g55581ac1x5296b21593ae757f@mail.gmail.com>

2009/9/5 Steven D'Aprano <steve at pearwood.info>:
> On Fri, 4 Sep 2009 10:01:28 pm Matteo Dell'Amico wrote:
>
>> Why? next(iter(obj)) means, pretty explicitly to me, "iterate on obj
>> and give me one element".
>
> To me, it says "give me the first element", not "give me any (an
> arbitrary) element" or "give me a random element".

The original use as described was for picking an "arbitrary" element,
because all of the elements were effectively the same - "any of the
elements in a data structure because you know that they all contain
the same information". For a random element, use random.choice, for
the first, use next(iter()). Either option satisfies the original
requirement - but the first is bound to be faster, so it seems
appropriate.

> Does anyone have a use-case for retrieving a single arbitrary element of
> an arbitrary sequence, without caring about any other elements? Is this
> really such a common operation that we need to consider it part of the
> interface for all collections? I doubt it.

Agreed.

Paul.


From gerald.britton at gmail.com  Sat Sep  5 15:26:34 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Sat, 5 Sep 2009 09:26:34 -0400
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7tg23$vdj$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com> 
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com> 
	<4AA10545.30408@gmail.com> <loom.20090905T044141-177@post.gmane.org> 
	<h7tg23$vdj$1@ger.gmane.org>
Message-ID: <5d1a32000909050626i7de52eb1qc1503372643970c@mail.gmail.com>

compose?  Where'd you find that?

On Sat, Sep 5, 2009 at 6:53 AM, Georg Brandl<g.brandl at gmx.net> wrote:
> Antoine Pitrou schrieb:
>> Nick Coghlan <ncoghlan at ...> writes:
>>>
>>> Because it overspecifies the semantics of what you're trying to do. It
>>> just happens that when the requirement is "get me any object in this
>>> container" the design of Python means that the easiest implementation is
>>> "get me the first object in this container".
>>
>> I don't agree.
>> Since iteration is such a frequent operation, any container which doesn't
>> provide cheap iteration could be considered badly designed and/or badly
>> implemented. Therefore it makes sense to rely on iteration when implementing
>> other primitives.
>>
>> People worrying that it expresses implementation rather than intent can write
>> the trivial abstraction by themselves:
>>
>> def any_item(x):
>> ? ? return next(iter(x))
>
> or
>
> any_item = compose(next, iter)
>
> ;)
>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From g.brandl at gmx.net  Sat Sep  5 15:31:40 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 05 Sep 2009 15:31:40 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <5d1a32000909050626i7de52eb1qc1503372643970c@mail.gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com>
	<4AA10545.30408@gmail.com>
	<loom.20090905T044141-177@post.gmane.org>
	<h7tg23$vdj$1@ger.gmane.org>
	<5d1a32000909050626i7de52eb1qc1503372643970c@mail.gmail.com>
Message-ID: <h7tpb9$loc$1@ger.gmane.org>

Gerald Britton schrieb:
> compose?  Where'd you find that?

That was another recent discussion here.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From gerald.britton at gmail.com  Sat Sep  5 15:47:37 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Sat, 5 Sep 2009 09:47:37 -0400
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7tpb9$loc$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com> 
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com> 
	<4AA10545.30408@gmail.com> <loom.20090905T044141-177@post.gmane.org> 
	<h7tg23$vdj$1@ger.gmane.org>
	<5d1a32000909050626i7de52eb1qc1503372643970c@mail.gmail.com> 
	<h7tpb9$loc$1@ger.gmane.org>
Message-ID: <5d1a32000909050647j1d5d730q355f9715b48a32c5@mail.gmail.com>

Ah -- so not a real function then (yet)?  Though something we could
borrow from Haskell, I suppose, even though:

compose(foo,bar) == lambda x: foo(bar(x))

no?

On Sat, Sep 5, 2009 at 9:31 AM, Georg Brandl<g.brandl at gmx.net> wrote:
> Gerald Britton schrieb:
>> compose? ?Where'd you find that?
>
> That was another recent discussion here.
>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From masklinn at masklinn.net  Sat Sep  5 16:15:47 2009
From: masklinn at masklinn.net (Masklinn)
Date: Sat, 5 Sep 2009 16:15:47 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <5d1a32000909050647j1d5d730q355f9715b48a32c5@mail.gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com> <4AA10198.8040401@gmail.com>
	<4AA10545.30408@gmail.com>
	<loom.20090905T044141-177@post.gmane.org>
	<h7tg23$vdj$1@ger.gmane.org>
	<5d1a32000909050626i7de52eb1qc1503372643970c@mail.gmail.com>
	<h7tpb9$loc$1@ger.gmane.org>
	<5d1a32000909050647j1d5d730q355f9715b48a32c5@mail.gmail.com>
Message-ID: <6751FF3A-7DFE-4BB1-B391-2EE9A2DE04BA@masklinn.net>

On 5 Sep 2009, at 15:47 , Gerald Britton wrote:
Ah -- so not a real function then (yet)?  Though something we could
> borrow from Haskell, I suppose, even though:
>
> compose(foo,bar) == lambda x: foo(bar(x))
>
> no?
>

Yeah but you could leverage Python's *args to get a compositor of more  
than two functions e.g.

    def compose(*funcs):
        return reduce(lambda f1, f2:
                          lambda *args, **kwargs:
                              f1(f2(*args, **kwargs)),
                      funcs)


From masklinn at masklinn.net  Sat Sep  5 16:39:14 2009
From: masklinn at masklinn.net (Masklinn)
Date: Sat, 5 Sep 2009 16:39:14 +0200
Subject: [Python-ideas] Collect **kw arguments as an ordered dictionary
Message-ID: <6813C5F4-6B5B-413B-AEE4-17F050D38019@masklinn.net>

Response to a fairly old (April) thread, but there's another use case  
to **kwargs being collected in an ordered dictionary: interaction with  
Objective-C or Smalltalk (but mainly obj-c/Cocoa): since **kwargs is  
not an ordered dict, Python/Cocoa interop can't use them to emulate  
ObjC's compound message names (as order is significant), so PyObjC  
merges the message subparts into a single method and tacks the  
arguments at the end, transforming calls like

     [NSString stringWithContentsOfFile:@"/usr/share/dict/propernames"
                               encoding:NSASCIIStringEncoding
                                  error:&error];

into

     NSString.stringWithContentsOfFile_encoding_error_(
                 "/usr/share/dict/propernames",
                 NSASCIIStringEncoding)

while the verbosity is similar, the loss in readability is tremendous.  
With the availability of ordered **kwargs, the bridge could simply  
have a send method (akin to the ObjC performSelector:) taking a bunch  
of kwargs and sending the corresponding message to the underlying ObjC  
object:

     NSString.send(stringWithContentOfFile="/usr/share/dict/ 
propernames",
                   encoding=NSASCIIStringEncoding,
                   error=errors)

Or variable method names with a bit of massaging e.g. using the first  
message part as the method name ? la MacRuby:

     NSString.stringWithContentOfFile("/usr/share/dict/propernames",
                             encoding=NSASCIIStringEncoding,
                                error=errors)

or splitting that first part between the method name and the first  
kwarg:

     NSString.stringWith(ContentOfFile="/usr/share/dict/propernames",
                         encoding=NSASCIIStringEncoding,
                         error=errors)

From zuo at chopin.edu.pl  Sat Sep  5 18:20:44 2009
From: zuo at chopin.edu.pl (Jan Kaliszewski)
Date: Sat, 05 Sep 2009 18:20:44 +0200
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <02b225c8$0$17565$c3e8da3@news.astraweb.com>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<op.uzqg30bafvx12t@jerzozwiesz.home.aster.pl>
	<8fd67d4b0909040955k590b8d6fv9012165d847b02d9@mail.gmail.com>
	<mailman.983.1252096642.2854.python-list@python.org>
	<02b1dd77$0$17565$c3e8da3@news.astraweb.com>
	<8fd67d4b0909042247h167226edv6693c314ae5a16eb@mail.gmail.com>
	<mailman.997.1252129901.2854.python-list@python.org>
	<02b225c8$0$17565$c3e8da3@news.astraweb.com>
Message-ID: <op.uzsk0upxfvx12t@jerzozwiesz.home.aster.pl>

05-09-2009 Steven D'Aprano <steve at remove-this-cybersource.com.au> wrote:

> On Fri, 04 Sep 2009 22:37:15 +0200, Jan Kaliszewski wrote:
>
>> Named tuples (which indeed are really very nice) are read-only, but the
>> approach they represent could (and IMHO should) be extended to some kind
>> of mutable objects.
[snip]
> What sort of extensions did you have in mind?

Two useful (from my point of view) concepts have appeared (or been linked
to) in this thread -- on python-list and python-ideas:

* the namespace/AttrDict concept (see Ken Newton's, Nick Coghlan's and my
   posts).

* record concept (see George Sakkis post).

>> The old discussion, the above link points to, shows that such a
>> dot-accessible dict-like class is something that many people need and
>> repeatedly implemet it (more or less perfectly) for themselves.
>
> I think it's something which people copy from other languages because
> that's what they're used to, not because they need it.

I don't think so, especially if we say about the former. IMHO it is simply
useful in practice, especially for scripting (but not only) -- being more
convenient than using empty class.

It offers (in compact way, without additional efforts and verbose
syntax -- once you have got such a tool implemented) three things at
the same time, without necessity to choose between them: comfortable
static attribute access, flexible dict-like dynamic access when needed
and possibility of iteration.

> It's just a change in syntax. Whether you write x.key or x['key'] is a
> matter of convenience. Attribute access is optimized for when you know
> the key names at compile time, key access is optimized for when you don't
> know the names until runtime.

Exactly. It is a matter of *convenience* (as well as large areas of Python)
and that's the point. I suppose that that is the reason for people to
repeatedly implement it for themselves.

05-09-2009 Steven D'Aprano <steve at remove-this-cybersource.com.au> wrote:

> On Fri, 04 Sep 2009 22:51:39 -0700, Ken Newton wrote:
[snip]
>> I would think this is much more than just copy from other language
>> styles or 'just' a syntax change -- the apparent widespread use would
>> hint at a deeper need.
>
> "Apparent" is the key word there. There are lots of people who *say* this
> this useful functionality, but how many of them *actually* use it? And of
> those who do use it, how many of them know what they're doing? There are
> an awful lot of bad programmers out there.
>
> If you do need such functionality, it's easy to implement. Here's one:

Neither you nor me have hard evidence about popularity/unpopularity of the
idea (number of places where you can find similar, more or less successful,
attempts to implement it seems to testify in favour of the idea) -- nor
about how it is used or abused.

Obviously there are a lot of bad programmers who are able to use globals
instead of function arguments etc.... Thats the fate of every language
feature.

But it's not the reason to resign from a feature that has particular common
and proper use-cases. Even official Python tutorial mentions a case that is
typical for the matter:

http://docs.python.org/3.1/tutorial/classes.html#odds-and-ends

> As a
> general rule, if obj.x is an attribute, then every valid obj should have
> an attribute x. But if obj['x'] is a key/value, then it is data-specific:
> some instances will have an 'x' key, and some won't.

It's often true but not always (see e.g. the above example in docs).

Cheers,
*j

-- 
Jan Kaliszewski (zuo) <zuo at chopin.edu.pl>


From ubershmekel at gmail.com  Sat Sep  5 18:45:44 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Sat, 5 Sep 2009 19:45:44 +0300
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <6751FF3A-7DFE-4BB1-B391-2EE9A2DE04BA@masklinn.net>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0FEF3.2000607@gmail.com>
	<4AA10198.8040401@gmail.com> <4AA10545.30408@gmail.com>
	<loom.20090905T044141-177@post.gmane.org> <h7tg23$vdj$1@ger.gmane.org>
	<5d1a32000909050626i7de52eb1qc1503372643970c@mail.gmail.com>
	<h7tpb9$loc$1@ger.gmane.org>
	<5d1a32000909050647j1d5d730q355f9715b48a32c5@mail.gmail.com>
	<6751FF3A-7DFE-4BB1-B391-2EE9A2DE04BA@masklinn.net>
Message-ID: <9d153b7c0909050945p729bc82y27f5a52c66b637c6@mail.gmail.com>

I can't stand map/reduce/lambda... *instant readable makeover*def
minicomp(f1, f2):
    def comped(*args, **kwargs):
        return f1(f2(*args, **kwargs))
    return comped

def compose(*funcs):
    total = funcs[0]
    for f in funcs[1:]:
        total = minicomp(total, f)
    return total

On Sat, Sep 5, 2009 at 5:15 PM, Masklinn <masklinn at masklinn.net> wrote:

> On 5 Sep 2009, at 15:47 , Gerald Britton wrote:
> Ah -- so not a real function then (yet)?  Though something we could
>
>> borrow from Haskell, I suppose, even though:
>>
>> compose(foo,bar) == lambda x: foo(bar(x))
>>
>> no?
>>
>>
> Yeah but you could leverage Python's *args to get a compositor of more than
> two functions e.g.
>
>   def compose(*funcs):
>       return reduce(lambda f1, f2:
>                         lambda *args, **kwargs:
>                             f1(f2(*args, **kwargs)),
>                     funcs)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Yuv
hzk.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090905/589a2864/attachment.html>

From g.brandl at gmx.net  Sat Sep  5 18:53:07 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 05 Sep 2009 18:53:07 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <9d153b7c0909050945p729bc82y27f5a52c66b637c6@mail.gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org>
	<4AA0FEF3.2000607@gmail.com>	<4AA10198.8040401@gmail.com>
	<4AA10545.30408@gmail.com>	<loom.20090905T044141-177@post.gmane.org>
	<h7tg23$vdj$1@ger.gmane.org>	<5d1a32000909050626i7de52eb1qc1503372643970c@mail.gmail.com>	<h7tpb9$loc$1@ger.gmane.org>	<5d1a32000909050647j1d5d730q355f9715b48a32c5@mail.gmail.com>	<6751FF3A-7DFE-4BB1-B391-2EE9A2DE04BA@masklinn.net>
	<9d153b7c0909050945p729bc82y27f5a52c66b637c6@mail.gmail.com>
Message-ID: <h7u550$js2$1@ger.gmane.org>

Yuvgoog Greenle schrieb:
> I can't stand map/reduce/lambda... *instant readable makeover*
> def minicomp(f1, f2):
>     def comped(*args, **kwargs):
>         return f1(f2(*args, **kwargs))
>     return comped
> 
> def compose(*funcs):
>     total = funcs[0]
>     for f in funcs[1:]:
>         total = minicomp(total, f)
>     return total

Please, if this must be discussed again, do it in a new thread.

cheers,
Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From ubershmekel at gmail.com  Sun Sep  6 01:49:43 2009
From: ubershmekel at gmail.com (RunThePun)
Date: Sat, 5 Sep 2009 16:49:43 -0700 (PDT)
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
Message-ID: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>

I put some sweat into this one so I was hoping to see if you guys like
it or have any ideas for improvement.
http://code.google.com/p/pyopt/

Currently there are 2 modes of operation,
1. keyword command-line functions which create switches (-m, -r etc).
2. positional command-line functions which simply translate positional
arguments from the command-line to a function.
possibly in the future I'll implement a mixed keyword/positional
arguments behaviour.

At the moment annotations are mandatory for explicitness and here's an
example usage:

from pyopt import CmdPos
from pyopt import parse_cmds

@CmdPos
def possy(archer:str, boulder:float, magic:int=42):
    """Shows an example positional command-line function.
        archer - is a str
        boulder - should be a float
        magic - a number that is magical"""
    print(repr(archer), repr(boulder), repr(magic))

if __name__ == "__main__":
    parse_cmds()

Notice 4 things:
  * an import
  * a decorator
  * a parse_cmds()
  * type-annotations for casting
The following functionality is exposed:

C:\>example.py -h
Usage: example.py archer boulder [magic]
        Shows an example positional command-line function.
        archer - is a str
        boulder - should be a float
        magic - a number that is magical

C:\>example.py 1 2 3
'1' 2.0 3

C:\>example.py 1 2
'1' 2.0 42

C:\>example.py 13
2 arguments required, got only 1. Run with ? or -h for more help.


From ben+python at benfinney.id.au  Sun Sep  6 03:59:11 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 06 Sep 2009 11:59:11 +1000
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
Message-ID: <8763bw4yvk.fsf@benfinney.id.au>

RunThePun <ubershmekel at gmail.com> writes:

> I put some sweat into this one so I was hoping to see if you guys like
> it or have any ideas for improvement.
> http://code.google.com/p/pyopt/

Thanks for your work on this.

> from pyopt import CmdPos
> from pyopt import parse_cmds

My main complaint at this point is the chosen names.

Within Python code, I don't need to be reminded that I'm writing Python.
The module names should not be ?pyopt?; you should choose a namespace
that better describes what the module is for, without the ?py?.

Also, please name the classes and functions so they're not needlessly
CprsdWrds. Instead, choose names that contain whole words, or at least
very-commonly-used abbreviations with little ambiguity. That way the
names will be both more descriptive and easier to pronounce, and thus
easier to remember correctly.

-- 
 \      ?[I]t is impossible for anyone to begin to learn that which he |
  `\                thinks he already knows.? ?Epictetus, _Discourses_ |
_o__)                                                                  |
Ben Finney



From greg.ewing at canterbury.ac.nz  Sun Sep  6 07:45:34 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 06 Sep 2009 17:45:34 +1200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7qn1t$njk$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
Message-ID: <4AA34C7E.7030803@canterbury.ac.nz>

Stefan Behnel wrote:

> It would therefore be nice to have a common ".any()" method on data
> structures that would just read an arbitrary item from a container.

Rather than add a method to every container implementation,
it would be easier to provide a function:

    def first(obj):
      return iter(ob).next()

possibly with some embellishments to handle StopIteration,
allow for a default value, etc.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Sun Sep  6 07:51:43 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 06 Sep 2009 17:51:43 +1200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA0FEF3.2000607@gmail.com>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com>
Message-ID: <4AA34DEF.4070606@canterbury.ac.nz>

Nick Coghlan wrote:

> That said, I'm -0 on the idea overall. If someone actually needs it, it
> isn't particularly hard for them to write their own getany() function.

There's a situation where the need to do this kind of
thing actually arises fairly frequently -- retrieving
things from a relational database. Often you're
expecting exactly one result from a query, but the
API always gives you a sequence, which you then have
to get the first item from. Doing that over and
over again gets rather tedious.

-- 
Greg


From ubershmekel at gmail.com  Sun Sep  6 09:34:10 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Sun, 6 Sep 2009 10:34:10 +0300
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <8763bw4yvk.fsf@benfinney.id.au>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<8763bw4yvk.fsf@benfinney.id.au>
Message-ID: <9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>

How about these names for the module:1. optionparse
2. shlopt (for shell options, sounds kinda cute albeit less descriptive)
3. shelloptions
4. ?

And the decorator Names:
1. shell_expose_kwargs and shell_expose_args
2. expose_keywords and expose_arguments
3. expose and expose_keywords?
4. ?

On Sun, Sep 6, 2009 at 4:59 AM, Ben Finney
<ben+python at benfinney.id.au<ben%2Bpython at benfinney.id.au>
> wrote:

> RunThePun <ubershmekel at gmail.com> writes:
>
> > I put some sweat into this one so I was hoping to see if you guys like
> > it or have any ideas for improvement.
> > http://code.google.com/p/pyopt/
>
> Thanks for your work on this.
>
> > from pyopt import CmdPos
> > from pyopt import parse_cmds
>
> My main complaint at this point is the chosen names.
>
> Within Python code, I don't need to be reminded that I'm writing Python.
> The module names should not be ?pyopt?; you should choose a namespace
> that better describes what the module is for, without the ?py?.
>
> Also, please name the classes and functions so they're not needlessly
> CprsdWrds. Instead, choose names that contain whole words, or at least
> very-commonly-used abbreviations with little ambiguity. That way the
> names will be both more descriptive and easier to pronounce, and thus
> easier to remember correctly.
>
> --
>  \      ?[I]t is impossible for anyone to begin to learn that which he |
>  `\                thinks he already knows.? ?Epictetus, _Discourses_ |
> _o__)                                                                  |
> Ben Finney
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Yuv
hzk.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090906/1ccf0e18/attachment.html>

From jafo at tummy.com  Sun Sep  6 10:14:00 2009
From: jafo at tummy.com (Sean Reifschneider)
Date: Sun, 06 Sep 2009 02:14:00 -0600
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>	<8763bw4yvk.fsf@benfinney.id.au>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
Message-ID: <4AA36F48.5040109@tummy.com>

On 09/06/2009 01:34 AM, Yuvgoog Greenle wrote:
> How about these names for the module:
> 1. optionparse
> 2. shlopt (for shell options, sounds kinda cute albeit less descriptive)

It shouldn't really IMHO be called anything having to do with "opt" because
that typically means the "-" (or in Windows "/") options (as in "getopt"
and "optik" which is now "optparse").

Maybe "shellargs" or "argparse"?

I think this is a really good start, thanks.

Sean
-- 
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090906/c67a09ba/attachment.pgp>

From g.brandl at gmx.net  Sun Sep  6 10:18:53 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Sep 2009 10:18:53 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA34DEF.4070606@canterbury.ac.nz>
References: <h7qn1t$njk$1@ger.gmane.org>
	<4AA0E3F9.9010904@gmail.com>	<4AA0FEF3.2000607@gmail.com>
	<4AA34DEF.4070606@canterbury.ac.nz>
Message-ID: <h7vrcp$tnf$1@ger.gmane.org>

Greg Ewing schrieb:
> Nick Coghlan wrote:
> 
>> That said, I'm -0 on the idea overall. If someone actually needs it, it
>> isn't particularly hard for them to write their own getany() function.
> 
> There's a situation where the need to do this kind of
> thing actually arises fairly frequently -- retrieving
> things from a relational database. Often you're
> expecting exactly one result from a query, but the
> API always gives you a sequence, which you then have
> to get the first item from. Doing that over and
> over again gets rather tedious.

But if it's a sequence, you can simply do s[0], can't you?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From steve at pearwood.info  Sun Sep  6 10:21:30 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 6 Sep 2009 18:21:30 +1000
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <4AA36F48.5040109@tummy.com>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com>
Message-ID: <200909061821.32540.steve@pearwood.info>

On Sun, 6 Sep 2009 06:14:00 pm Sean Reifschneider wrote:
> On 09/06/2009 01:34 AM, Yuvgoog Greenle wrote:
> > How about these names for the module:
> > 1. optionparse
> > 2. shlopt (for shell options, sounds kinda cute albeit less
> > descriptive)
>
> It shouldn't really IMHO be called anything having to do with "opt"
> because that typically means the "-" (or in Windows "/") options (as
> in "getopt" and "optik" which is now "optparse").

But handling the dash command line options is exactly what the module is 
about.

Perhaps the author can explain why this module is better or more 
pythonic than the two existing solutions already in the standard 
library. More importantly, while I'm sure the author is excited by his 
project, why has it been announced on this list? It seems to be 
off-topic to my mind.



-- 
Steven D'Aprano


From steve at pearwood.info  Sun Sep  6 10:23:23 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 6 Sep 2009 18:23:23 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA34DEF.4070606@canterbury.ac.nz>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0FEF3.2000607@gmail.com>
	<4AA34DEF.4070606@canterbury.ac.nz>
Message-ID: <200909061823.23915.steve@pearwood.info>

On Sun, 6 Sep 2009 03:51:43 pm Greg Ewing wrote:
> Nick Coghlan wrote:
> > That said, I'm -0 on the idea overall. If someone actually needs
> > it, it isn't particularly hard for them to write their own getany()
> > function.
>
> There's a situation where the need to do this kind of
> thing actually arises fairly frequently -- retrieving
> things from a relational database. Often you're
> expecting exactly one result from a query, but the
> API always gives you a sequence, which you then have
> to get the first item from. Doing that over and
> over again gets rather tedious.

If you're expecting "exactly one result", then surely it should be an 
error to receive more than one result? Rather than ask for "any" result 
and ignoring any unexpected extra items, I think it would be better to 
have a helper function that verifies you have got exactly one result.



-- 
Steven D'Aprano


From rob.cliffe at btinternet.com  Sun Sep  6 18:41:33 2009
From: rob.cliffe at btinternet.com (Rob Cliffe)
Date: Sun, 6 Sep 2009 17:41:33 +0100
Subject: [Python-ideas] Decorator syntax restriction
Message-ID: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>

Can I make another plea for the syntax following '@' to be an unrestricted expression?  Guido has said he has a 'gut feeling' against this but has not as far as I know rationalised it.

1) It is inconsistent with Python in general (unPythonic) to impose arbitrary restrictions in one particular place, and hard to explain to someone learning the language.

2) The restriction is in any case more apparent than real,
as 
    @ <any-expression> # disallowed, SyntaxError
can be implemented, albeit in a more verbose aka less Pythonic was, as:

    AnyExpr = <any-expression>
    @AnyExpr

or as

    def Identity(x): return x
     ...
    @Identity( <any-expression> ) # smuggle in as func arg

3) I propose the following as plausible use cases (I know other people will have their own):

3.1)
    @DecoratorList[index]

3.2)
    @DecoratorDictionary[key]

3.3)
    @Decorator1 if <condition> else Decorator2
#   Special case of the last one:
    def Identity(x): return x
    @Decorator if __debug__ else Identity 

Xavier Morel has pointed out that 3.1) can be implemented now as
    @DecoratorList.__getitem__[index]
but this doesn't seem a good reason for forbidding the simpler syntax; after all Python allows the simpler syntax in other contexts.  Similarly 3.2) can be written as
    @DecoratorDictionary.get(key)

(As an aside, perhaps a decorator that evaluates to None could be treated at run-time the same as no decorator, i.e. equivalent to the Identity function in the above examples.  Currently it naturally raises TypeError: 'NoneType' object is not callable.  Just a thought.)

Finally, sorry if I have not sent this e-mail to the right place (I wanted to attach it to the 'allow lambdas as decorators' thread but don't yet know how to do this).  Also sorry that this partly duplicates a message I sent to python-dev.  I am still finding my way round the Python mailing lists.

Best wishes
Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090906/9ca88b09/attachment.html>

From fetchinson at googlemail.com  Sun Sep  6 21:30:34 2009
From: fetchinson at googlemail.com (Daniel Fetchinson)
Date: Sun, 6 Sep 2009 12:30:34 -0700
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
Message-ID: <fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>

> Can I make another plea for the syntax following '@' to be an unrestricted
> expression?  Guido has said he has a 'gut feeling' against this but has not
> as far as I know rationalised it.
>
> 1) It is inconsistent with Python in general (unPythonic) to impose
> arbitrary restrictions in one particular place, and hard to explain to
> someone learning the language.
>
> 2) The restriction is in any case more apparent than real,
> as
>     @ <any-expression> # disallowed, SyntaxError
> can be implemented, albeit in a more verbose aka less Pythonic was, as:

What makes you think that if something is 'more verbose' it is 'less
pythonic'? I actually like the fact that python doesn't try condensing
everything into one-liners and special symbols.

I never really understood this need for being not verbose, but it does
periodically come up on this list (and pretty much on every other
programming list). Your fingers get tired? It takes too long to read
an extra line? You are running out of space on your harddrive? It
takes too long to transfer the source file over the network because of
the extra line?

Honestly, why do some people set for themselves the goal of "let's
have as few characters in a source file as possible"?

Cheers,
Daniel


>     AnyExpr = <any-expression>
>     @AnyExpr
> or as
>
>     def Identity(x): return x
>      ...
>     @Identity( <any-expression> ) # smuggle in as func arg
>
> 3) I propose the following as plausible use cases (I know other people will
> have their own):
>
> 3.1)
>     @DecoratorList[index]
>
> 3.2)
>     @DecoratorDictionary[key]
>
> 3.3)
>     @Decorator1 if <condition> else Decorator2
> #   Special case of the last one:
>     def Identity(x): return x
>     @Decorator if __debug__ else Identity
>
> Xavier Morel has pointed out that 3.1) can be implemented now as
>     @DecoratorList.__getitem__[index]
> but this doesn't seem a good reason for forbidding the simpler syntax; after
> all Python allows the simpler syntax in other contexts.  Similarly 3.2) can
> be written as
>     @DecoratorDictionary.get(key)
>
> (As an aside, perhaps a decorator that evaluates to None could be treated at
> run-time the same as no decorator, i.e. equivalent to the Identity function
> in the above examples.  Currently it naturally raises TypeError: 'NoneType'
> object is not callable.  Just a thought.)
>
> Finally, sorry if I have not sent this e-mail to the right place (I wanted
> to attach it to the 'allow lambdas as decorators' thread but don't yet know
> how to do this).  Also sorry that this partly duplicates a message I sent to
> python-dev.  I am still finding my way round the Python mailing lists.
>
> Best wishes
> Rob Cliffe


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown


From jafo at tummy.com  Sun Sep  6 21:39:41 2009
From: jafo at tummy.com (Sean Reifschneider)
Date: Sun, 06 Sep 2009 13:39:41 -0600
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <200909061821.32540.steve@pearwood.info>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>	<4AA36F48.5040109@tummy.com>
	<200909061821.32540.steve@pearwood.info>
Message-ID: <4AA40FFD.1010601@tummy.com>

On 09/06/2009 02:21 AM, Steven D'Aprano wrote:
> But handling the dash command line options is exactly what the module is 
> about.

The example at the referenced page looks like it's all about handling
non-option arguments.  I must be missing something.

Sean
-- 
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090906/9dd37386/attachment.pgp>

From mwm-keyword-python.b4bdba at mired.org  Sun Sep  6 22:07:07 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Sun, 6 Sep 2009 16:07:07 -0400
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>
Message-ID: <20090906160707.7883dac5@bhuda.mired.org>

On Sun, 6 Sep 2009 12:30:34 -0700
Daniel Fetchinson <fetchinson at googlemail.com> wrote:
> What makes you think that if something is 'more verbose' it is 'less
> pythonic'? I actually like the fact that python doesn't try condensing
> everything into one-liners and special symbols.

Agreed. Readability, not succinctness, is what's pythonic. Being
succinct usually - but not always - improves readability.

> I never really understood this need for being not verbose, but it does
> periodically come up on this list (and pretty much on every other
> programming list). Your fingers get tired? It takes too long to read
> an extra line? You are running out of space on your harddrive? It
> takes too long to transfer the source file over the network because of
> the extra line?
> 
> Honestly, why do some people set for themselves the goal of "let's
> have as few characters in a source file as possible"?

Paul Graham (generally a very sharp guy) summarizes most of the
reasons in http://www.paulgraham.com/power.html. I provide my attempt
at a counterargument in
http://www.mired.org/home/mwm/papers/readability.html.

   <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From brett at python.org  Sun Sep  6 22:18:51 2009
From: brett at python.org (Brett Cannon)
Date: Sun, 6 Sep 2009 13:18:51 -0700
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
Message-ID: <bbaeab100909061318k2ce74059pdb0a388b51fe2bab@mail.gmail.com>

On Sun, Sep 6, 2009 at 09:41, Rob Cliffe<rob.cliffe at btinternet.com> wrote:
> Can I make another plea for the syntax following '@' to be an unrestricted
> expression?? Guido has said he has a 'gut feeling' against this but has not
> as far as I know rationalised it.
>

When it comes to Guido's gut, a rationalization isn't needed. Perk of
being BDFL. Plus his gut is right so often it tends to not be
questioned.

> 1) It is inconsistent with Python in general (unPythonic) to impose
> arbitrary restrictions in one particular place, and hard to explain to
> someone learning the language.
>

It's not difficult to explain; decorators can only be a dotted name w/
an optional method call and its corresponding arguments. It keeps the
syntax simple and clean, IMO. Decorators add a mental overhead of
having to think about what they will do to a function when reading the
code. If I then also have to figure out what an arbitrary expression
evaluates to in order to figure that out that is more mental effort
than needed. Yes, you can do whatever with the decorator you are
passing in, but hopefully you are not so evil/stupid as to make a
decorator that copmlicated. Give people the power of full expressions
and that will happen more often.

> 2) The restriction is in any case more apparent than real,
> as
> ??? @ <any-expression> # disallowed, SyntaxError
> can be implemented, albeit in a more verbose aka less Pythonic was, as:
>
> ??? AnyExpr = <any-expression>
> ??? @AnyExpr
>
> or as
>
> ??? def Identity(x): return x
> ???? ...
> ????@Identity( <any-expression> ) # smuggle in as func arg
>

And we almost ditched lambdas in Python 3 because you can implement
them in the same way. The only reason they got to stick around was
they were already in use and people threw a fit over them.

> 3) I propose the following as plausible use cases (I know other people will
> have their own):
>
> 3.1)
> ??? @DecoratorList[index]
>
> 3.2)
> ??? @DecoratorDictionary[key]
>
> 3.3)
> ??? @Decorator1 if?<condition> else Decorator2
> #?? Special case of?the last one:
> ??? def Identity(x): return x
> ??? @Decorator if __debug__ else Identity
>

Plausible does not equal useful. You need to show that this actually
comes up in normal coding for a decent amount of Python code to
warrant tweaking the language over.

> Xavier Morel has pointed out that 3.1) can be implemented now as
> ??? @DecoratorList.__getitem__[index]
> but this doesn't seem a good reason for forbidding the simpler syntax; after
> all Python allows the simpler syntax in other contexts.? Similarly 3.2) can
> be written as
> ??? @DecoratorDictionary.get(key)
>
> (As an aside, perhaps a decorator that evaluates to None could be treated at
> run-time the same as no decorator, i.e. equivalent to the Identity function
> in the above examples.? Currently?it naturally raises TypeError: 'NoneType'
> object is not callable.? Just a thought.)

That's not going to happen. =) Complicates the bytecode unnecessarily.
Once again, this needs to actually come up in regular usage to warrant
even considering the change.

>
> Finally, sorry if I have not sent this e-mail to the right place (I wanted
> to attach it to the 'allow lambdas as decorators' thread but don't yet know
> how to do this).? Also sorry that this partly duplicates a message I sent to
> python-dev.? I am still finding my way round the Python mailing lists.

No, this is the place to send thought out proposals for changing
Python before they get promoted to hitting python-dev.

-Brett


From ncoghlan at gmail.com  Sun Sep  6 22:44:42 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 07 Sep 2009 06:44:42 +1000
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <bbaeab100909061318k2ce74059pdb0a388b51fe2bab@mail.gmail.com>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<bbaeab100909061318k2ce74059pdb0a388b51fe2bab@mail.gmail.com>
Message-ID: <4AA41F3A.1070808@gmail.com>

Brett Cannon wrote:
> On Sun, Sep 6, 2009 at 09:41, Rob Cliffe<rob.cliffe at btinternet.com> wrote:
>> Can I make another plea for the syntax following '@' to be an unrestricted
>> expression?  Guido has said he has a 'gut feeling' against this but has not
>> as far as I know rationalised it.
>>
> 
> When it comes to Guido's gut, a rationalization isn't needed. Perk of
> being BDFL. Plus his gut is right so often it tends to not be
> questioned.
> 
>> 1) It is inconsistent with Python in general (unPythonic) to impose
>> arbitrary restrictions in one particular place, and hard to explain to
>> someone learning the language.
>>
> 
> It's not difficult to explain; decorators can only be a dotted name w/
> an optional method call and its corresponding arguments.

>From the last discussion, I believe Guido was actually amenable to the
idea of extending this to allow a subscript operation as well, so a
decorator could be pulled from a sequence or map of decorators without
requiring an otherwise unnecessary function call.

So what's needed at this point is for someone that is bothered by the
restriction to come up with a patch to loosen the restriction without
getting rid of it entirely.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From solipsis at pitrou.net  Sun Sep  6 23:45:49 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Sep 2009 21:45:49 +0000 (UTC)
Subject: [Python-ideas] data structures should have an .any() method
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0FEF3.2000607@gmail.com>
	<4AA34DEF.4070606@canterbury.ac.nz>
	<200909061823.23915.steve@pearwood.info>
Message-ID: <loom.20090906T234407-971@post.gmane.org>

Steven D'Aprano <steve at ...> writes:
> 
> If you're expecting "exactly one result", then surely it should be an 
> error to receive more than one result? Rather than ask for "any" result 
> and ignoring any unexpected extra items, I think it would be better to 
> have a helper function that verifies you have got exactly one result.

Why do you need a helper function?
Simply write:

    x, = db.query("SELECT blah...")

and you'll get a ValueError if there isn't exactly one item in the sequence.

Regards

Antoine.




From solipsis at pitrou.net  Sun Sep  6 23:46:53 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 6 Sep 2009 21:46:53 +0000 (UTC)
Subject: [Python-ideas] data structures should have an .any() method
References: <h7qn1t$njk$1@ger.gmane.org>
	<4AA0E3F9.9010904@gmail.com>	<4AA0FEF3.2000607@gmail.com>
	<4AA10198.8040401@gmail.com>	<4AA10545.30408@gmail.com>
	<loom.20090905T044141-177@post.gmane.org>
	<h7tg23$vdj$1@ger.gmane.org>
Message-ID: <loom.20090906T234636-337@post.gmane.org>

Georg Brandl <g.brandl at ...> writes:
> 
> or
> 
> any_item = compose(next, iter)

Endly, an use case for compose!




From zuo at chopin.edu.pl  Mon Sep  7 01:37:35 2009
From: zuo at chopin.edu.pl (Jan Kaliszewski)
Date: Mon, 07 Sep 2009 01:37:35 +0200
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <4AA3FD65.7000403@stoneleaf.us>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<op.uzqg30bafvx12t@jerzozwiesz.home.aster.pl>
	<8fd67d4b0909040955k590b8d6fv9012165d847b02d9@mail.gmail.com>
	<mailman.983.1252096642.2854.python-list@python.org>
	<02b1dd77$0$17565$c3e8da3@news.astraweb.com>
	<8fd67d4b0909042247h167226edv6693c314ae5a16eb@mail.gmail.com>
	<mailman.997.1252129901.2854.python-list@python.org>
	<02b225c8$0$17565$c3e8da3@news.astraweb.com>
	<4AA3FD65.7000403@stoneleaf.us>
Message-ID: <op.uzuzwxfjfvx12t@jerzozwiesz.localdomain>

06-09-2009 o 20:20:21 Ethan Furman <ethan at stoneleaf.us> wrote:

> In the dbf module I wrote, I use both the attribute access and the key  
> lookup.  The attribute access is great for interactive use, and for all  
> the routines that play with the tables we have at work, where all the  
> field names are indeed known at compile (aka coding) time.  On the other  
> hand, some routines don't know which fields they'll mucking about with,  
> and so the key access is vital for them.
>
> Of course, I could have done the whole thing using key access, and I did  
> have to impose some restrictions on method names so they wouldn't clash  
> with possible field names, but I love being able to type
>
>    current_record.full_name == last_record.full_name
>
> instead of
>
>    current_record['full_name'] == last_record['full_name']

Me too, and I suppose many people too...

The latter:

* makes your code less readable if there is high density of such
   expressions;

* makes typing much more strenuous/irritating -- what is not very
   important in case of advanced development (when time of typing is
   short in relation to time of thinking/reading/testing) but becomes
   quite important in case of scripting (which is still important area
   of Python usage).

-- 
Jan Kaliszewski (zuo) <zuo at chopin.edu.pl>


From greg.ewing at canterbury.ac.nz  Mon Sep  7 02:32:44 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 07 Sep 2009 12:32:44 +1200
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <4AA36F48.5040109@tummy.com>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<8763bw4yvk.fsf@benfinney.id.au>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com>
Message-ID: <4AA454AC.60709@canterbury.ac.nz>

Sean Reifschneider wrote:

> Maybe "shellargs" or "argparse"?

I don't think it should have "shell" in it, because the
module doesn't really have anything to do with the shell.
The shell is not the only way of launching a program and
passing args to it.

-- 
Greg


From ubershmekel at gmail.com  Mon Sep  7 02:34:52 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Mon, 7 Sep 2009 03:34:52 +0300
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <4AA40FFD.1010601@tummy.com>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com> <200909061821.32540.steve@pearwood.info>
	<4AA40FFD.1010601@tummy.com>
Message-ID: <9d153b7c0909061734x615a97fao6e974110744173ff@mail.gmail.com>

Currently the module handles positional arguments with one decorator and
keyword arguments (with '-' switches) using another decorator. Maybe I
should have linked to this more complete examples page:
http://code.google.com/p/pyopt/wiki/Examples

Steven: Forgive me, I am new to this list and now after checking I'm
guessing you mean "stdlib-sig" is more fitting. So I'll move this discussion
there.

Just to clarify why I feel getopt/optparse aren't as pythonic - to me they
feel clunky in that I need alot of ultra-explicit, extra-long lines to do
some very basic things. The python I'm used to allows me to use
open('filename').read() with reasonable default parameters. Now that I think
of it, actually wrapping optparse might have been an easier implementation
route for some of the functionality...

Yuv

On Sun, Sep 6, 2009 at 10:39 PM, Sean Reifschneider <jafo at tummy.com> wrote:

> On 09/06/2009 02:21 AM, Steven D'Aprano wrote:
> > But handling the dash command line options is exactly what the module is
> > about.
>
> The example at the referenced page looks like it's all about handling
> non-option arguments.  I must be missing something.
>
> Sean
> --
> Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High
> Availability
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>


-- 
Yuv
hzk.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090907/c2f1d953/attachment.html>

From greg.ewing at canterbury.ac.nz  Mon Sep  7 02:35:14 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 07 Sep 2009 12:35:14 +1200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h7vrcp$tnf$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0E3F9.9010904@gmail.com>
	<4AA0FEF3.2000607@gmail.com> <4AA34DEF.4070606@canterbury.ac.nz>
	<h7vrcp$tnf$1@ger.gmane.org>
Message-ID: <4AA45542.1080102@canterbury.ac.nz>

Georg Brandl wrote:

> But if it's a sequence, you can simply do s[0], can't you?

Not if it's an iterator, which it probably will be in
the case of a DB API.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Mon Sep  7 02:39:28 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 07 Sep 2009 12:39:28 +1200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <200909061823.23915.steve@pearwood.info>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA0FEF3.2000607@gmail.com>
	<4AA34DEF.4070606@canterbury.ac.nz>
	<200909061823.23915.steve@pearwood.info>
Message-ID: <4AA45640.4020605@canterbury.ac.nz>

Steven D'Aprano wrote:

> If you're expecting "exactly one result", then surely it should be an 
> error to receive more than one result? Rather than ask for "any" result 
> and ignoring any unexpected extra items, I think it would be better to 
> have a helper function that verifies you have got exactly one result.

Yes, that could be useful. Maybe call it "one"?

-- 
Greg


From fetchinson at googlemail.com  Mon Sep  7 02:48:21 2009
From: fetchinson at googlemail.com (Daniel Fetchinson)
Date: Sun, 6 Sep 2009 17:48:21 -0700
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <20090906160707.7883dac5@bhuda.mired.org>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>
	<20090906160707.7883dac5@bhuda.mired.org>
Message-ID: <fbe2e2100909061748u4510e568l60a1f601afa1383f@mail.gmail.com>

>> What makes you think that if something is 'more verbose' it is 'less
>> pythonic'? I actually like the fact that python doesn't try condensing
>> everything into one-liners and special symbols.
>
> Agreed. Readability, not succinctness, is what's pythonic. Being
> succinct usually - but not always - improves readability.
>
>> I never really understood this need for being not verbose, but it does
>> periodically come up on this list (and pretty much on every other
>> programming list). Your fingers get tired? It takes too long to read
>> an extra line? You are running out of space on your harddrive? It
>> takes too long to transfer the source file over the network because of
>> the extra line?
>>
>> Honestly, why do some people set for themselves the goal of "let's
>> have as few characters in a source file as possible"?
>
> Paul Graham (generally a very sharp guy) summarizes most of the
> reasons in http://www.paulgraham.com/power.html.

Thanks, this answers my question why people think this way. Although
I'm still totally convinced that guys like Paul Graham, or anybody
else who believes in shorter code, are misguided.

> I provide my attempt at a counterargument in
> http://www.mired.org/home/mwm/papers/readability.html.

Yep, I more-or-less agree with you.

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown


From ubershmekel at gmail.com  Mon Sep  7 03:07:34 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Mon, 7 Sep 2009 04:07:34 +0300
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <4AA454AC.60709@canterbury.ac.nz>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<8763bw4yvk.fsf@benfinney.id.au>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com> <4AA454AC.60709@canterbury.ac.nz>
Message-ID: <9d153b7c0909061807g19016cfcmd96f1ce93a7dbf54@mail.gmail.com>

What do you think of the name "optionize" for the module then?
@optionize.positional
@optionize.keyword

or maybe
@optionize.args
@optionize.kwargs

On Mon, Sep 7, 2009 at 3:32 AM, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> Sean Reifschneider wrote:
>
>  Maybe "shellargs" or "argparse"?
>>
>
> I don't think it should have "shell" in it, because the
> module doesn't really have anything to do with the shell.
> The shell is not the only way of launching a program and
> passing args to it.
>
> --
> Greg
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Yuv
hzk.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090907/707b932f/attachment.html>

From greg.ewing at canterbury.ac.nz  Mon Sep  7 03:52:50 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 07 Sep 2009 13:52:50 +1200
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <9d153b7c0909061807g19016cfcmd96f1ce93a7dbf54@mail.gmail.com>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<8763bw4yvk.fsf@benfinney.id.au>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com> <4AA454AC.60709@canterbury.ac.nz>
	<9d153b7c0909061807g19016cfcmd96f1ce93a7dbf54@mail.gmail.com>
Message-ID: <4AA46772.5050405@canterbury.ac.nz>

Yuvgoog Greenle wrote:
> What do you think of the name "optionize" for the module then?

-1, too clever and not informative enough.

-- 
Greg



From tleeuwenburg at gmail.com  Mon Sep  7 03:54:59 2009
From: tleeuwenburg at gmail.com (Tennessee Leeuwenburg)
Date: Mon, 7 Sep 2009 11:54:59 +1000
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <4AA46772.5050405@canterbury.ac.nz>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<8763bw4yvk.fsf@benfinney.id.au>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com> <4AA454AC.60709@canterbury.ac.nz>
	<9d153b7c0909061807g19016cfcmd96f1ce93a7dbf54@mail.gmail.com>
	<4AA46772.5050405@canterbury.ac.nz>
Message-ID: <43c8685c0909061854t40ca8467j39a37f5a2827826c@mail.gmail.com>

Maybe opthandler? optparse2?

Of course, not worth letting naming get in the way of progress...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090907/a72b3f87/attachment.html>

From eric at trueblade.com  Mon Sep  7 03:29:24 2009
From: eric at trueblade.com (Eric Smith)
Date: Sun, 06 Sep 2009 21:29:24 -0400
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <4AA454AC.60709@canterbury.ac.nz>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>	<8763bw4yvk.fsf@benfinney.id.au>	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>	<4AA36F48.5040109@tummy.com>
	<4AA454AC.60709@canterbury.ac.nz>
Message-ID: <4AA461F4.8010804@trueblade.com>

Greg Ewing wrote:
> Sean Reifschneider wrote:
> 
>> Maybe "shellargs" or "argparse"?
> 
> I don't think it should have "shell" in it, because the
> module doesn't really have anything to do with the shell.
> The shell is not the only way of launching a program and
> passing args to it.

And the name "argparse" is already used by a popular package: 
http://code.google.com/p/argparse/




From stephen at xemacs.org  Mon Sep  7 04:13:09 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 07 Sep 2009 11:13:09 +0900
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <fbe2e2100909061748u4510e568l60a1f601afa1383f@mail.gmail.com>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>
	<20090906160707.7883dac5@bhuda.mired.org>
	<fbe2e2100909061748u4510e568l60a1f601afa1383f@mail.gmail.com>
Message-ID: <87k50b8pu2.fsf@uwakimon.sk.tsukuba.ac.jp>

Daniel Fetchinson writes:

 > >> What makes you think that if something is 'more verbose' it is 'less
 > >> pythonic'? I actually like the fact that python doesn't try condensing
 > >> everything into one-liners and special symbols.

Yes.

 > > Agreed. Readability, not succinctness, is what's pythonic. Being
 > > succinct usually - but not always - improves readability.

Yes.

 > >> I never really understood this need for being not verbose, but it does
 > >> periodically come up on this list (and pretty much on every other
 > >> programming list).
 > >> Your fingers get tired?

Yes.  See Jan Kaliszewski's post in the "possible attribute-oriented
class" thread.  His reasoning is valid, though I don't sympathize with
it personally.

 > >> It takes too long to read an extra line?

Yes, when "too long" has the semantics "I read this repeatedly in a
short space and don't need to see the whole thing over and over
again.  In fact, it gets in my way when reading an 'array' of the sme
idiom."

This is what Paul Graham means by (expressive) power, I believe.  He
mentions metrics like number of characters or lines, but he says what
he really wants is something like the number of leaves in the AST.

If the "this" is something local, then you use a function (or
sometimes a macro if available) at that level of locality.  But if the
idiom appears across many programs, then it may be a good idea to turn
it into a standard builtin, or even syntax.  I believe this is the
gist of Graham's argument, and it's very close to the criteria for
adding syntax in the Zen (actually, the apocrypha, stuff like "not
every three-line function needs to be a builtin" aren't canonized).

 > >> You are running out of space on your harddrive?
 > >> It takes too long to transfer the source file over the network
 > >> because of the extra line?

Both of those are silly.  If you use compression, it will work out
about the same anyway.<wink>

 > >> Honestly, why do some people set for themselves the goal of "let's
 > >> have as few characters in a source file as possible"?

Mostly the ones who show up on Python lists don't have such a goal.
They just want the ache in their hands and arms to go away, one
unnecessary character at a time.

 > > Paul Graham (generally a very sharp guy) summarizes most of the
 > > reasons in http://www.paulgraham.com/power.html.
 > 
 > Thanks, this answers my question why people think this way. Although
 > I'm still totally convinced that guys like Paul Graham, or anybody
 > else who believes in shorter code, are misguided.
 > 
 > > I provide my attempt at a counterargument in
 > > http://www.mired.org/home/mwm/papers/readability.html.
 > 
 > Yep, I more-or-less agree with you.

But Paul Graham does, too, AFAICS.

ISTM that what Paul G. doesn't get is that Paul P.'s epigram is more
along the lines of Emerson's epigram.  To put it in the same style, "A
bogus succinctness is the hobgoblin of L2-cache-deprived minds (and
RSI-hobbled wrists)."  To me, the argument on "mired" seems quite
complementary to the argument Graham makes, in that it shows how
Python actually is succinct in the sense that Graham proposes, despite
not minimizing character, token, or line counts.


From fetchinson at googlemail.com  Mon Sep  7 04:53:55 2009
From: fetchinson at googlemail.com (Daniel Fetchinson)
Date: Sun, 6 Sep 2009 19:53:55 -0700
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <2DBF7599EA49409F938951A0D3953635@robslaptop>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>
	<2DBF7599EA49409F938951A0D3953635@robslaptop>
Message-ID: <fbe2e2100909061953i73e7f753v4bd64e8eb9ac63c@mail.gmail.com>

> I happen to think that the longer forms in all the relevant examples that I
> gave are harder to understand, because they introduce an extra step that is
> not relevant to the job to be done; rather, it is a distraction that adds an
> extra 'kink' in the flow of thought.

I actually agree with you, in the case of decorators, and for some of
the cases you discussed (for example allowing @decorator[5] syntax),
it is true that the short forms are readable and I don't see any
problem with them.

My only concern was the general statement 'more verbose = unpythonic'.

> You may disagree - fine - but it should be up to the judgement of the
> programmer, within reason, how concise or how verbose to be.

I don't fully agree. Some obfuscated, hard-to-read, etc forms should I
think be explicitly forbidden. Luckily, python does forbid lots of
constructs which would be very hard to follow.


> In this case,
> the language should not force me to go the extra mile with an arbitrary
> restriction, when there is no reason to (no difficulty of implementation, as
> I understand it).

Yes, again, I fully agree with you on this particular case.

Cheers,
Daniel


>
>>> Can I make another plea for the syntax following '@' to be an
>>> unrestricted
>>> expression?  Guido has said he has a 'gut feeling' against this but has
>>> not
>>> as far as I know rationalised it.
>>>
>>> 1) It is inconsistent with Python in general (unPythonic) to impose
>>> arbitrary restrictions in one particular place, and hard to explain to
>>> someone learning the language.
>>>
>>> 2) The restriction is in any case more apparent than real,
>>> as
>>>     @ <any-expression> # disallowed, SyntaxError
>>> can be implemented, albeit in a more verbose aka less Pythonic was, as:
>>
>> What makes you think that if something is 'more verbose' it is 'less
>> pythonic'? I actually like the fact that python doesn't try condensing
>> everything into one-liners and special symbols.
>>
>> I never really understood this need for being not verbose, but it does
>> periodically come up on this list (and pretty much on every other
>> programming list). Your fingers get tired? It takes too long to read
>> an extra line? You are running out of space on your harddrive? It
>> takes too long to transfer the source file over the network because of
>> the extra line?
>>
>> Honestly, why do some people set for themselves the goal of "let's
>> have as few characters in a source file as possible"?
>>
>> Cheers,
>> Daniel
>>
>>
>>>     AnyExpr = <any-expression>
>>>     @AnyExpr
>>> or as
>>>
>>>     def Identity(x): return x
>>>      ...
>>>     @Identity( <any-expression> ) # smuggle in as func arg
>>>
>>> 3) I propose the following as plausible use cases (I know other people
>>> will
>>> have their own):
>>>
>>> 3.1)
>>>     @DecoratorList[index]
>>>
>>> 3.2)
>>>     @DecoratorDictionary[key]
>>>
>>> 3.3)
>>>     @Decorator1 if <condition> else Decorator2
>>> #   Special case of the last one:
>>>     def Identity(x): return x
>>>     @Decorator if __debug__ else Identity
>>>
>>> Xavier Morel has pointed out that 3.1) can be implemented now as
>>>     @DecoratorList.__getitem__[index]
>>> but this doesn't seem a good reason for forbidding the simpler syntax;
>>> after
>>> all Python allows the simpler syntax in other contexts.  Similarly 3.2)
>>> can
>>> be written as
>>>     @DecoratorDictionary.get(key)
>>>
>>> (As an aside, perhaps a decorator that evaluates to None could be treated
>>>
>>> at
>>> run-time the same as no decorator, i.e. equivalent to the Identity
>>> function
>>> in the above examples.  Currently it naturally raises TypeError:
>>> 'NoneType'
>>> object is not callable.  Just a thought.)
>>>
>>> Finally, sorry if I have not sent this e-mail to the right place (I
>>> wanted
>>> to attach it to the 'allow lambdas as decorators' thread but don't yet
>>> know
>>> how to do this).  Also sorry that this partly duplicates a message I sent
>>>
>>> to
>>> python-dev.  I am still finding my way round the Python mailing lists.
>>>
>>> Best wishes
>>> Rob Cliffe
>>
>>
>> --
>> Psss, psss, put it down! - http://www.cafepress.com/putitdown
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>
>
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown


From ben+python at benfinney.id.au  Mon Sep  7 05:05:59 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 07 Sep 2009 13:05:59 +1000
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<8763bw4yvk.fsf@benfinney.id.au>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com> <4AA454AC.60709@canterbury.ac.nz>
	<4AA461F4.8010804@trueblade.com>
Message-ID: <87k50b3148.fsf@benfinney.id.au>

Eric Smith <eric at trueblade.com> writes:

> And the name "argparse" is already used by a popular package:
> http://code.google.com/p/argparse/

Which raises the question: Would the original poster do the free
software community a service by, instead of writing a new library from
scratch, try improving to the existing libraries that are already in
use?

-- 
 \     ?As we enjoy great advantages from the inventions of others, we |
  `\      should be glad to serve others by any invention of ours; and |
_o__)     this we should do freely and generously.? ?Benjamin Franklin |
Ben Finney



From mwm-keyword-python.b4bdba at mired.org  Mon Sep  7 09:05:32 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Mon, 7 Sep 2009 03:05:32 -0400
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <87k50b8pu2.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>
	<20090906160707.7883dac5@bhuda.mired.org>
	<fbe2e2100909061748u4510e568l60a1f601afa1383f@mail.gmail.com>
	<87k50b8pu2.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20090907030532.56270cee@bhuda.mired.org>

This appears to be veering way off topic...

Except we're looking at what makes an idea "good" in python terms,
vs. what makes them "not good". Basically, trying to define
"pythonic". I don't know that that can be done, but there seem to be
some broad points that can be agreed on....

>  > >> Honestly, why do some people set for themselves the goal of "let's
>  > >> have as few characters in a source file as possible"?
> Mostly the ones who show up on Python lists don't have such a goal.
> They just want the ache in their hands and arms to go away, one
> unnecessary character at a time.
> 
>  > > Paul Graham (generally a very sharp guy) summarizes most of the
>  > > reasons in http://www.paulgraham.com/power.html.
>  > 
>  > Thanks, this answers my question why people think this way. Although
>  > I'm still totally convinced that guys like Paul Graham, or anybody
>  > else who believes in shorter code, are misguided.
>  > 
>  > > I provide my attempt at a counterargument in
>  > > http://www.mired.org/home/mwm/papers/readability.html.

I think my choice of "counterargument" here is a bit off. It's not all
that argumentative.

>  > Yep, I more-or-less agree with you.
> But Paul Graham does, too, AFAICS.
> 
> ISTM that what Paul G. doesn't get is that Paul P.'s epigram is more
> along the lines of Emerson's epigram.  To put it in the same style, "A
> bogus succinctness is the hobgoblin of L2-cache-deprived minds (and
> RSI-hobbled wrists)."  To me, the argument on "mired" seems quite
> complementary to the argument Graham makes, in that it shows how
> Python actually is succinct in the sense that Graham proposes, despite
> not minimizing character, token, or line counts.

What I was attempting to do was point out that succinctness for the
sake of succinctness isn't necessarily a good thing. Python indeed
tries to be succinct, but balances that against the need for the
results to still be readable. I'd say that the mired.org document
supplements what Paul G. had to say rather than complements it, as the
mired.org document discusses areas where readability matters, which
Paul G. ignored.

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From stefan_ml at behnel.de  Mon Sep  7 09:22:58 2009
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 07 Sep 2009 09:22:58 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA45640.4020605@canterbury.ac.nz>
References: <h7qn1t$njk$1@ger.gmane.org>
	<4AA0FEF3.2000607@gmail.com>	<4AA34DEF.4070606@canterbury.ac.nz>	<200909061823.23915.steve@pearwood.info>
	<4AA45640.4020605@canterbury.ac.nz>
Message-ID: <h82ccj$jpd$1@ger.gmane.org>

Greg Ewing wrote:
> Steven D'Aprano wrote:
> 
>> If you're expecting "exactly one result", then surely it should be an
>> error to receive more than one result? Rather than ask for "any"
>> result and ignoring any unexpected extra items, I think it would be
>> better to have a helper function that verifies you have got exactly
>> one result.
> 
> Yes, that could be useful. Maybe call it "one"?

I think "one" fits two of the proposed three use cases pretty nicely. The
only remaining use case is where you actually have more than one item but
only want any one out of them. But I think in that case you can actually
roll your own anyway, as there may be other constrains on exactly how
'equal' all the items are.

Stefan



From ubershmekel at gmail.com  Mon Sep  7 10:51:07 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Mon, 7 Sep 2009 11:51:07 +0300
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <87k50b3148.fsf@benfinney.id.au>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
	<8763bw4yvk.fsf@benfinney.id.au>
	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>
	<4AA36F48.5040109@tummy.com> <4AA454AC.60709@canterbury.ac.nz>
	<4AA461F4.8010804@trueblade.com> <87k50b3148.fsf@benfinney.id.au>
Message-ID: <9d153b7c0909070151i183f9b9bh84f4a3c31aa9f1c5@mail.gmail.com>

To me the most awesome goal for this project would be to make it into the
standard library. The concept is to allow a minimal-syntax decorator to
expose regular functions as opposed to building an entire function just for
parsing all the options. I don't mind where I implement this.

=D

On Mon, Sep 7, 2009 at 6:05 AM, Ben Finney
<ben+python at benfinney.id.au<ben%2Bpython at benfinney.id.au>
> wrote:

> Eric Smith <eric at trueblade.com> writes:
>
> > And the name "argparse" is already used by a popular package:
> > http://code.google.com/p/argparse/
>
> Which raises the question: Would the original poster do the free
> software community a service by, instead of writing a new library from
> scratch, try improving to the existing libraries that are already in
> use?
>
> --
>  \     ?As we enjoy great advantages from the inventions of others, we |
>  `\      should be glad to serve others by any invention of ours; and |
> _o__)     this we should do freely and generously.? ?Benjamin Franklin |
> Ben Finney
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Yuv
hzk.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090907/29dae010/attachment.html>

From ncoghlan at gmail.com  Mon Sep  7 13:29:52 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 07 Sep 2009 21:29:52 +1000
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
In-Reply-To: <9d153b7c0909061734x615a97fao6e974110744173ff@mail.gmail.com>
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>	<9d153b7c0909060034s4de0fd4an526cc6aae9157a31@mail.gmail.com>	<4AA36F48.5040109@tummy.com>
	<200909061821.32540.steve@pearwood.info>	<4AA40FFD.1010601@tummy.com>
	<9d153b7c0909061734x615a97fao6e974110744173ff@mail.gmail.com>
Message-ID: <4AA4EEB0.6080608@gmail.com>

Yuvgoog Greenle wrote:
> Just to clarify why I feel getopt/optparse aren't as pythonic - to me
> they feel clunky in that I need alot of ultra-explicit, extra-long lines
> to do some very basic things. The python I'm used to allows me to use
> open('filename').read() with reasonable default parameters. Now that I
> think of it, actually wrapping optparse might have been an easier
> implementation route for some of the functionality...

Something to think about is the possibility of redesigning your API
proposal to function as a convenience wrapper around the existing
optparse implementation. Convenience wrappers have a much lower hurdle
to clear than complete alternative APIs (since the full power of the
original API remains available by dropping back to the lower level).
It's still no guarantee of course - there still needs to be a
python-ideas (and then python-dev) consensus that the proposed wrappers
actually are an improvement.

There are definitely some things about the basic concepts behind your
API that bother me as it currently stands:

1. One of the major features of optparse is that it encourages a data
driven approach to option definition. Going back to a largely procedural
approach as in your examples is not a step forward.

2. The use of a single global parser is a fairly questionable feature.

3. Losing the options object makes it more difficult to pass options
around to code that may only care about some of the options


A potentially valuable addition to optparse might just focus on your
"CmdPos" idea and add the ability to add commands to the option parser:

import optparse

parser = optparse.parser()

@parser.add_command
def main(options, *args):
  """Command line help info goes here"""
  # Main body goes here

# Adding more than one command would result in the first argument
# being used to select between them by name as with CmdPos

if __name__ == "__main__":
  parser.run_command()

The other thing I find somewhat tedious with optparse is having to do
lots of procedural checking of option constraints in order to provide
helpful error messages. Being able to add independent constraint checks
would help a great deal with that:

@parser.add_constraint
def check_args(parser, options, *args):
  if len(args) != 2:
    parser.error("Exactly 2 arguments required")

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From solipsis at pitrou.net  Mon Sep  7 13:48:48 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 7 Sep 2009 11:48:48 +0000 (UTC)
Subject: [Python-ideas] Pyopt - an attempt at a pythonic optparse
References: <123377d1-0b16-4deb-b540-ca9cee02e216@s39g2000yqj.googlegroups.com>
Message-ID: <loom.20090907T134826-752@post.gmane.org>

RunThePun <ubershmekel at ...> writes:
> 
> possibly in the future I'll implement a mixed keyword/positional
> arguments behaviour.

It is certainly necessary if you want it to be useful.

Regards

Antoine.




From steve at pearwood.info  Tue Sep  8 02:15:10 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 8 Sep 2009 10:15:10 +1000
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <op.uzuzwxfjfvx12t@jerzozwiesz.localdomain>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<4AA3FD65.7000403@stoneleaf.us>
	<op.uzuzwxfjfvx12t@jerzozwiesz.localdomain>
Message-ID: <200909081015.10767.steve@pearwood.info>

On Mon, 7 Sep 2009 09:37:35 am Jan Kaliszewski wrote:
> 06-09-2009 o 20:20:21 Ethan Furman <ethan at stoneleaf.us> wrote:

> > ... I love being able to type
> >
> >    current_record.full_name == last_record.full_name
> >
> > instead of
> >
> >    current_record['full_name'] == last_record['full_name']
>
> Me too, and I suppose many people too...
>
> The latter:
>
> * makes your code less readable if there is high density of such
>    expressions;
>
> * makes typing much more strenuous/irritating -- what is not very
>    important in case of advanced development (when time of typing is
>    short in relation to time of thinking/reading/testing) but becomes
>    quite important in case of scripting (which is still important
> area of Python usage).

If you have a large number of such expressions, what's wrong with this?


FNAME = "full_name"  # Define the string in one place only.
current_record[FNAME] == last_record[FNAME]  # Use it in many places.


Not only is it shorter to use, but it's easy to change the 
key "full_name" to (say) "complete_name" or "volledige_naam" with one 
edit, and without mistakenly changing some other string which just 
happens to match the key. (I don't know about others, but when I'm 
first working on a piece of code, and before I settle on an API or 
database schema, I often change field names two or three times before I 
settle in on the final version.)

In any case, while I accept that this is sometimes useful, I also think 
that it's a something which is simple enough to add to your classes 
when necessary with just a few lines -- all you really need are the 
__*attr__ methods, everything else is superfluous. If you're doing this 
a lot, avoid boilerplate with a class decorator. Here's an untested 
minimalistic version which probably does everything necessary:

def add_attr(cls):
    """Class decorator which adds attribute access to mappings."""
    def __getattr__(self, name):
        return self[name]
    def __setattr__(self, name, value):
        self[name] = value
    def __delattr__(self, name):
        del self[name]
    for func in (__getattr__, __setattr__, __delattr__):
        setattr(cls, func.__name__, func)
    return cls



Fields of an object (attributes) and keys of a mapping are generally for 
different purposes, and I'm not sure we should encourage people to 
conflate the two. I think this belongs in the cookbook, not the 
standard library.



-- 
Steven D'Aprano


From zuo at chopin.edu.pl  Tue Sep  8 03:02:25 2009
From: zuo at chopin.edu.pl (Jan Kaliszewski)
Date: Tue, 08 Sep 2009 03:02:25 +0200
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <200909081015.10767.steve@pearwood.info>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<4AA3FD65.7000403@stoneleaf.us>
	<op.uzuzwxfjfvx12t@jerzozwiesz.localdomain>
	<200909081015.10767.steve@pearwood.info>
Message-ID: <op.uzwyibn8fvx12t@jerzozwiesz.localdomain>

08-09-2009 o 02:15:10 Steven D'Aprano <steve at pearwood.info> wrote:

> On Mon, 7 Sep 2009 09:37:35 am Jan Kaliszewski wrote:
>> 06-09-2009 o 20:20:21 Ethan Furman <ethan at stoneleaf.us> wrote:
>
>> > ... I love being able to type
>> >
>> >    current_record.full_name == last_record.full_name
>> >
>> > instead of
>> >
>> >    current_record['full_name'] == last_record['full_name']
>>
>> Me too, and I suppose many people too...
>>
>> The latter:
>>
>> * makes your code less readable if there is high density of such
>>    expressions;
>>
>> * makes typing much more strenuous/irritating -- what is not very
>>    important in case of advanced development (when time of typing is
>>    short in relation to time of thinking/reading/testing) but becomes
>>    quite important in case of scripting (which is still important
>> area of Python usage).
>
> If you have a large number of such expressions, what's wrong with this?

a['xyz'] = something['blablabla'] + somethingelse['foobar']
b['ababababa'] += afun(bobo['dodo']['kookoo'] * pofopofo['gh'][0]['a'])
cupu['abc'] = (kukumunu['bo'], kukumunu['kuu'].mbmbmb['lalala'])

a.xyz = something.blablabla + somethingelse.foobar
b.ababababa += afun(bobo.dodo.kookoo * pofopofo.gh[0].a)
cupu.abc = (kukumunu.bo, kukumunu.kuu.mbmbmb.lalala)

For me the latter is definitely easier to read and understand.

> FNAME = "full_name"  # Define the string in one place only.
> current_record[FNAME] == last_record[FNAME]  # Use it in many places.
>
> Not only is it shorter to use, but it's easy to change the
> key "full_name" to (say) "complete_name" or "volledige_naam" with one
> edit, and without mistakenly changing some other string which just
> happens to match the key.

You are right, but it's a bit different story... I don't say that attr
access is always better than key access -- but only that sometimes it is.

> (I don't know about others, but when I'm
> first working on a piece of code, and before I settle on an API or
> database schema, I often change field names two or three times before I
> settle in on the final version.)

Me too! :)

> In any case, while I accept that this is sometimes useful, I also think
> that it's a something which is simple enough to add to your classes
> when necessary with just a few lines -- all you really need are the
> __*attr__ methods, everything else is superfluous. If you're doing this
> a lot, avoid boilerplate with a class decorator. Here's an untested
> minimalistic version which probably does everything necessary:
>
> def add_attr(cls):
>     """Class decorator which adds attribute access to mappings."""
>     def __getattr__(self, name):
>         return self[name]
>     def __setattr__(self, name, value):
>         self[name] = value
>     def __delattr__(self, name):
>         del self[name]
>     for func in (__getattr__, __setattr__, __delattr__):
>         setattr(cls, func.__name__, func)
>     return cls

I'd add to it also dict-like iteration (__iter__(), _keys(), _values(),
_items()) and __str__ adjusted to nice nested representation (like in
some posts in this thread, e.g. my proposition).

> Fields of an object (attributes) and keys of a mapping are generally for
> different purposes, and I'm not sure we should encourage people to
> conflate the two. I think this belongs in the cookbook, not the
> standard library.

I think it depends how often people need to implement such boiler-plate
code for themselves. Now I see that this thread is not very popular, so
indeed maybe you are right... Though it'd be nice to have OOTB such
a factory in `collections` module...

Cheers,
*j

-- 
Jan Kaliszewski (zuo) <zuo at chopin.edu.pl>


From stephen at xemacs.org  Tue Sep  8 05:06:51 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 08 Sep 2009 12:06:51 +0900
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <200909081015.10767.steve@pearwood.info>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com>
	<4AA3FD65.7000403@stoneleaf.us>
	<op.uzuzwxfjfvx12t@jerzozwiesz.localdomain>
	<200909081015.10767.steve@pearwood.info>
Message-ID: <877hwannhw.fsf@uwakimon.sk.tsukuba.ac.jp>

Steven D'Aprano writes:

 > Fields of an object (attributes) and keys of a mapping are generally for 
 > different purposes, and I'm not sure we should encourage people to 
 > conflate the two.

+1 on discouraging conflation.



From jimjjewett at gmail.com  Tue Sep  8 16:53:57 2009
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 8 Sep 2009 10:53:57 -0400
Subject: [Python-ideas] possible attribute-oriented class
In-Reply-To: <op.uzwyibn8fvx12t@jerzozwiesz.localdomain>
References: <8fd67d4b0909031546o423cf066wf7096651bbc46ee0@mail.gmail.com> 
	<4AA3FD65.7000403@stoneleaf.us>
	<op.uzuzwxfjfvx12t@jerzozwiesz.localdomain> 
	<200909081015.10767.steve@pearwood.info>
	<op.uzwyibn8fvx12t@jerzozwiesz.localdomain>
Message-ID: <fb6fbf560909080753i483e3879g4d0e9f17aabfd839@mail.gmail.com>

On Mon, Sep 7, 2009 at 9:02 PM, Jan Kaliszewski<zuo at chopin.edu.pl> wrote:
> 08-09-2009 o 02:15:10 Steven D'Aprano <steve at pearwood.info> wrote:

>> ... what's wrong with this?

> a['xyz'] = something['blablabla'] + somethingelse['foobar']
> b['ababababa'] += afun(bobo['dodo']['kookoo'] * pofopofo['gh'][0]['a'])
> cupu['abc'] = (kukumunu['bo'], kukumunu['kuu'].mbmbmb['lalala'])

> a.xyz = something.blablabla + somethingelse.foobar
> b.ababababa += afun(bobo.dodo.kookoo * pofopofo.gh[0].a)
> cupu.abc = (kukumunu.bo, kukumunu.kuu.mbmbmb.lalala)

> For me the latter is definitely easier to read and understand.

I would describe it as "less difficult" rather than "easier".  My
biggest problem is that at that stage, I'm still typing raw, and
inclined to make typos.

The difference between fname and fnam won't be caught either way, but
field access at least keeps me from forgetting quotes, or forgetting
them at one end.

>> ... I often change field names two or three times
>> before I settle in on the final version.

And often because of an ambiguity with another field that I hadn't
originally thought to name.  Neither solution fixes this, but
attribute access is slightly easier to change.

>> [recipe to simplify attr-access]

> I think it depends how often people need to
> implement such boiler-plate code for themselves.

Attribute access is clearly better -- except for one thing.

While I'm doing this, I'm still in exploratory mode, and I *will* need
to clean up the API if I ever want better than quick-and-dirty.  If
the quick-and-dirty is already using attribute access, that makes the
transition a bit trickier.  If the quick-and-dirty is using dict
access, at least I have a clear marker.

-jJ


From lie.1296 at gmail.com  Tue Sep  8 16:56:26 2009
From: lie.1296 at gmail.com (Lie Ryan)
Date: Wed, 09 Sep 2009 00:56:26 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <4AA34C7E.7030803@canterbury.ac.nz>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA34C7E.7030803@canterbury.ac.nz>
Message-ID: <h85rbe$pde$1@ger.gmane.org>

Greg Ewing wrote:
> Stefan Behnel wrote:
> 
>> It would therefore be nice to have a common ".any()" method on data
>> structures that would just read an arbitrary item from a container.
> 
> Rather than add a method to every container implementation,
> it would be easier to provide a function:
> 
>    def first(obj):
>      return iter(ob).next()
> 
> possibly with some embellishments to handle StopIteration,
> allow for a default value, etc.
> 

Which would imply a request for last().



From Scott.Daniels at Acm.Org  Tue Sep  8 23:05:05 2009
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Tue, 08 Sep 2009 14:05:05 -0700
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <200909061823.23915.steve@pearwood.info>
References: <h7qn1t$njk$1@ger.gmane.org>
	<4AA0FEF3.2000607@gmail.com>	<4AA34DEF.4070606@canterbury.ac.nz>
	<200909061823.23915.steve@pearwood.info>
Message-ID: <h86gc6$f4u$1@ger.gmane.org>

Steven D'Aprano wrote:
> On Sun, 6 Sep 2009 03:51:43 pm Greg Ewing wrote:
>> Nick Coghlan wrote:
>>> That said, I'm -0 on the idea overall. If someone actually needs
>>> it, it isn't particularly hard for them to write their own getany()
>>> function.
>> There's a situation where the need to do this kind of
>> thing actually arises fairly frequently -- retrieving
>> things from a relational database. Often you're
>> expecting exactly one result from a query, but the
>> API always gives you a sequence, which you then have
>> to get the first item from. Doing that over and
>> over again gets rather tedious.
> 
> If you're expecting "exactly one result", then surely it should be an 
> error to receive more than one result? Rather than ask for "any" result 
> and ignoring any unexpected extra items, I think it would be better to 
> have a helper function that verifies you have got exactly one result.

Well, some queries return results without duplicate elimination, even
though they are defined to return sets.  If you really want to limit
things in databases queries, the "LIMIT 1" clause is your friend, as
the query optimizer knows it can stop as soon as its found something.
Of course I don't know which query optimizers around now _use_ that
knowledge to pick a query plan, but that leaves the info there if
the next rev becomes limit-capable.

Often when I just want to pick a single value from a column I use MIN
or MAX (and fairly often when I need two distinct values I use both MIN 
and MAX).

One trick to seeing a column is exactly a singleton is:
     SELECT MIN(something)
     FROM ...
     WHERE MIN(something) = MAX(something)

--Scott David Daniels
Scott.Daniels at Acm.Org



From Scott.Daniels at Acm.Org  Tue Sep  8 23:46:09 2009
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Tue, 08 Sep 2009 14:46:09 -0700
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <20090907030532.56270cee@bhuda.mired.org>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>	<fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com>	<20090906160707.7883dac5@bhuda.mired.org>	<fbe2e2100909061748u4510e568l60a1f601afa1383f@mail.gmail.com>	<87k50b8pu2.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20090907030532.56270cee@bhuda.mired.org>
Message-ID: <h86ip7$mvk$1@ger.gmane.org>

Mike Meyer wrote:
...
> What I was attempting to do was point out that succinctness for the
> sake of succinctness isn't necessarily a good thing. Python indeed
> tries to be succinct, but balances that against the need for the
> results to still be readable. 

I'm quite interested in this as well.  I think that a Pythonic
succinctness is very DRY (don't repeat yourself), rather than
short.  What I want when I read code is to be reading ideas, not
typing or pasting.  In Python, when I find I'm doing something
several times I look for ways to combine tables and code, so what
varies shows up clearly, and what is in common shows in the loop.

APL was one language that battered me over the head with the
proof that shorter was not necessarily clearer.

--Scott David Daniels
Scott.Daniels at Acm.Org



From anfedorov at gmail.com  Wed Sep  9 03:07:53 2009
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Tue, 8 Sep 2009 21:07:53 -0400
Subject: [Python-ideas] Function to apply superset of arguments to a function
Message-ID: <7659cab30909081807v6f59aed3p5e2b30a3a4d343d0@mail.gmail.com>

Hi all,

I've written a function [1] called apply_some which takes a set of keywords
arguments, filters only those a function is expecting, and calls the
function with only those arguments. This is meant to suppress TypeErrors - a
way to abstract the logic which checks what arguments a passed-in function
accepts.

For example:

def foo(x=1, y=2):
    return (x,y)

apply_some(foo, y=0, z="hi") // calls foo(y=0)
-> (1,0)

I'd like to expand this to fill undefined arguments with None, but before I
do, does anyone know of any packages/libraries which either do something
similar or would make this code cleaner?

Cheers,
Andrey

1. http://gist.github.com/183375
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090908/3bbdc02e/attachment.html>

From cmjohnson.mailinglist at gmail.com  Wed Sep  9 12:52:52 2009
From: cmjohnson.mailinglist at gmail.com (Carl Johnson)
Date: Wed, 9 Sep 2009 00:52:52 -1000
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <h86ip7$mvk$1@ger.gmane.org>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<fbe2e2100909061230x1939212av176f89b1baf97c5b@mail.gmail.com> 
	<20090906160707.7883dac5@bhuda.mired.org>
	<fbe2e2100909061748u4510e568l60a1f601afa1383f@mail.gmail.com> 
	<87k50b8pu2.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20090907030532.56270cee@bhuda.mired.org> 
	<h86ip7$mvk$1@ger.gmane.org>
Message-ID: <3bdda690909090352v4668bd47g1bb7cde924c0d986@mail.gmail.com>

On 2009/9/8 Scott David Daniels wrote:

> APL was one language that battered me over the head with the
> proof that shorter was not necessarily clearer.

Ah yes, more proof of the adage: "if you can't be a good example, be a
terrible warning." :-D

? Carl Johnson


From steve at pearwood.info  Wed Sep  9 13:26:36 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 9 Sep 2009 21:26:36 +1000
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <h86ip7$mvk$1@ger.gmane.org>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<20090907030532.56270cee@bhuda.mired.org>
	<h86ip7$mvk$1@ger.gmane.org>
Message-ID: <200909092126.37270.steve@pearwood.info>

On Wed, 9 Sep 2009 07:46:09 am Scott David Daniels wrote:
> APL was one language that battered me over the head with the
> proof that shorter was not necessarily clearer.

Conway's Game of Life in one line:

http://www.catpad.net/michael/apl/



-- 
Steven D'Aprano


From ncoghlan at gmail.com  Wed Sep  9 14:36:42 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 09 Sep 2009 22:36:42 +1000
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <h85rbe$pde$1@ger.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org> <4AA34C7E.7030803@canterbury.ac.nz>
	<h85rbe$pde$1@ger.gmane.org>
Message-ID: <4AA7A15A.8090202@gmail.com>

Lie Ryan wrote:
> Greg Ewing wrote:
>> Stefan Behnel wrote:
>>
>>> It would therefore be nice to have a common ".any()" method on data
>>> structures that would just read an arbitrary item from a container.
>>
>> Rather than add a method to every container implementation,
>> it would be easier to provide a function:
>>
>>    def first(obj):
>>      return iter(ob).next()
>>
>> possibly with some embellishments to handle StopIteration,
>> allow for a default value, etc.
>>
> 
> Which would imply a request for last().

Not really - every iterator in Python is guaranteed to either have a
first value or throw an exception when you try to retrieve it via next().

There's no such guarantee that every iterator will terminate and hence
have a "last" value (cf. itertools.count).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From lie.1296 at gmail.com  Wed Sep  9 16:50:18 2009
From: lie.1296 at gmail.com (Lie Ryan)
Date: Thu, 10 Sep 2009 00:50:18 +1000
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <200909092126.37270.steve@pearwood.info>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>	<20090907030532.56270cee@bhuda.mired.org>	<h86ip7$mvk$1@ger.gmane.org>
	<200909092126.37270.steve@pearwood.info>
Message-ID: <h88fba$l96$1@ger.gmane.org>

Steven D'Aprano wrote:
> On Wed, 9 Sep 2009 07:46:09 am Scott David Daniels wrote:
>> APL was one language that battered me over the head with the
>> proof that shorter was not necessarily clearer.
> 
> Conway's Game of Life in one line:
> 
> http://www.catpad.net/michael/apl/


Here is a hypothesis:
"The length of a code is inversely proportional to the length of 
documentation required to explain the code"

The APL Conway's Game of Life requires a full page of documentation to 
explain how it works. Most implementations of the same game have much 
less documentation and much longer code.

Prove or disprove the hypothesis.

If proven true, the hypothesis may lead to:
The net worth of having a short, succinct code may be outweighed by the 
amount of documentation needed to explain the code.



From george.sakkis at gmail.com  Wed Sep  9 17:23:57 2009
From: george.sakkis at gmail.com (George Sakkis)
Date: Wed, 9 Sep 2009 11:23:57 -0400
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <h88fba$l96$1@ger.gmane.org>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<20090907030532.56270cee@bhuda.mired.org> <h86ip7$mvk$1@ger.gmane.org>
	<200909092126.37270.steve@pearwood.info> <h88fba$l96$1@ger.gmane.org>
Message-ID: <91ad5bf80909090823t52d50a03la941bb22b554e571@mail.gmail.com>

On Wed, Sep 9, 2009 at 10:50 AM, Lie Ryan<lie.1296 at gmail.com> wrote:
> Steven D'Aprano wrote:
>>
>> On Wed, 9 Sep 2009 07:46:09 am Scott David Daniels wrote:
>>>
>>> APL was one language that battered me over the head with the
>>> proof that shorter was not necessarily clearer.
>>
>> Conway's Game of Life in one line:
>>
>> http://www.catpad.net/michael/apl/
>
>
> Here is a hypothesis:
> "The length of a code is inversely proportional to the length of
> documentation required to explain the code"
>
> The APL Conway's Game of Life requires a full page of documentation to
> explain how it works. Most implementations of the same game have much less
> documentation and much longer code.
>
> Prove or disprove the hypothesis.
>
> If proven true, the hypothesis may lead to:
> The net worth of having a short, succinct code may be outweighed by the
> amount of documentation needed to explain the code.

Any such proof or even discussion should take into account what the
primitives (atoms and allowed operations) are. If not, here is a
solution that is short both in code and documentation:

     game_of_life().solve()

;-)

George


From g.brandl at gmx.net  Wed Sep  9 18:03:44 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 09 Sep 2009 18:03:44 +0200
Subject: [Python-ideas] data structures should have an .any() method
In-Reply-To: <loom.20090906T234407-971@post.gmane.org>
References: <h7qn1t$njk$1@ger.gmane.org>
	<4AA0FEF3.2000607@gmail.com>	<4AA34DEF.4070606@canterbury.ac.nz>	<200909061823.23915.steve@pearwood.info>
	<loom.20090906T234407-971@post.gmane.org>
Message-ID: <h88joj$6ks$1@ger.gmane.org>

Antoine Pitrou schrieb:
> Steven D'Aprano <steve at ...> writes:
>> 
>> If you're expecting "exactly one result", then surely it should be an 
>> error to receive more than one result? Rather than ask for "any" result 
>> and ignoring any unexpected extra items, I think it would be better to 
>> have a helper function that verifies you have got exactly one result.
> 
> Why do you need a helper function?
> Simply write:
> 
>     x, = db.query("SELECT blah...")
> 
> and you'll get a ValueError if there isn't exactly one item in the sequence.

Amen!

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From brett at python.org  Wed Sep  9 18:19:50 2009
From: brett at python.org (Brett Cannon)
Date: Wed, 9 Sep 2009 09:19:50 -0700
Subject: [Python-ideas] Function to apply superset of arguments to a
	function
In-Reply-To: <7659cab30909081807v6f59aed3p5e2b30a3a4d343d0@mail.gmail.com>
References: <7659cab30909081807v6f59aed3p5e2b30a3a4d343d0@mail.gmail.com>
Message-ID: <bbaeab100909090919k2fddb1bfw913218b72de61d45@mail.gmail.com>

This is the wrong list to ask for help with something like this.
comp.lang.python/python-list is the proper place to try to get help.

On Tue, Sep 8, 2009 at 18:07, Andrey Fedorov <anfedorov at gmail.com> wrote:
> Hi all,
>
> I've written a function [1] called apply_some which takes a set of keywords
> arguments, filters only those a function is expecting, and calls the
> function with only those arguments. This is meant to suppress TypeErrors - a
> way to abstract the logic which checks what arguments a passed-in function
> accepts.
>
> For example:
>
> def foo(x=1, y=2):
> ??? return (x,y)
>
> apply_some(foo, y=0, z="hi") // calls foo(y=0)
> -> (1,0)
>
> I'd like to expand this to fill undefined arguments with None, but before I
> do, does anyone know of any packages/libraries which either do something
> similar or would make this code cleaner?
>
> Cheers,
> Andrey
>
> 1. http://gist.github.com/183375
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>


From gerald.britton at gmail.com  Wed Sep  9 13:45:00 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Wed, 9 Sep 2009 07:45:00 -0400
Subject: [Python-ideas] Function to apply superset of arguments to a
	function
In-Reply-To: <7659cab30909081807v6f59aed3p5e2b30a3a4d343d0@mail.gmail.com>
References: <7659cab30909081807v6f59aed3p5e2b30a3a4d343d0@mail.gmail.com>
Message-ID: <5d1a32000909090445r37c40a24v949823d2bd2e98ac@mail.gmail.com>

functools.partial

On Tue, Sep 8, 2009 at 9:07 PM, Andrey Fedorov<anfedorov at gmail.com> wrote:
> Hi all,
>
> I've written a function [1] called apply_some which takes a set of keywords
> arguments, filters only those a function is expecting, and calls the
> function with only those arguments. This is meant to suppress TypeErrors - a
> way to abstract the logic which checks what arguments a passed-in function
> accepts.
>
> For example:
>
> def foo(x=1, y=2):
> ??? return (x,y)
>
> apply_some(foo, y=0, z="hi") // calls foo(y=0)
> -> (1,0)
>
> I'd like to expand this to fill undefined arguments with None, but before I
> do, does anyone know of any packages/libraries which either do something
> similar or would make this code cleaner?
>
> Cheers,
> Andrey
>
> 1. http://gist.github.com/183375
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>



-- 
Gerald Britton


From greg.ewing at canterbury.ac.nz  Thu Sep 10 02:52:44 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 10 Sep 2009 12:52:44 +1200
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <91ad5bf80909090823t52d50a03la941bb22b554e571@mail.gmail.com>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<20090907030532.56270cee@bhuda.mired.org> <h86ip7$mvk$1@ger.gmane.org>
	<200909092126.37270.steve@pearwood.info> <h88fba$l96$1@ger.gmane.org>
	<91ad5bf80909090823t52d50a03la941bb22b554e571@mail.gmail.com>
Message-ID: <4AA84DDC.6070102@canterbury.ac.nz>

George Sakkis wrote:

> Any such proof or even discussion should take into account what the
> primitives (atoms and allowed operations) are.

Probably you should include the size of the documentation
of the primitives used in your programming language
manual, any other well-known literature they implicitly
refer to, etc.

> If not, here is a
> solution that is short both in code and documentation:
> 
>      game_of_life().solve()

But then you need to go and find a paper describing
the game of life and the algorithm being used to
solve it and include its length!

-- 
Greg


From ubershmekel at gmail.com  Thu Sep 10 03:40:58 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Thu, 10 Sep 2009 04:40:58 +0300
Subject: [Python-ideas] Decorator syntax restriction
In-Reply-To: <4AA84DDC.6070102@canterbury.ac.nz>
References: <4E8F67D5F8CC4562A71B1516F7957D7A@robslaptop>
	<20090907030532.56270cee@bhuda.mired.org> <h86ip7$mvk$1@ger.gmane.org>
	<200909092126.37270.steve@pearwood.info> <h88fba$l96$1@ger.gmane.org>
	<91ad5bf80909090823t52d50a03la941bb22b554e571@mail.gmail.com>
	<4AA84DDC.6070102@canterbury.ac.nz>
Message-ID: <9d153b7c0909091840k2133ce11l7b258fbfaae0759a@mail.gmail.com>

You can drop the game of life manual, it would be needed in any
implementation so it doesn't help in describing the function
documentation_length(code_length)... Aside from a constant value.
d - documentatin_length the amount of words or symbols.
c - code_length in words or symbols.

d = K*c + A

Lets approximate:
brainfuck K = 30
APL K = 20
perl K = 2
python K = 0.5

K is the obfuscation factor (anti-readability).

The constant A is needed because if you didn't write any code you're still
gonna have some explaining to do.

For a given algorithm with a complexity of L logical nodes, here's the
inverse relation Ryan was talking about.:
L = d * c * Rd * Rc

As you can see for a given algorithm with a constant L, as d grows, c
shrinks. R is the richness of the language, if we have more words in our
language, less words are needed to describe things. Rd is the richness of
the documentation language (english) and Rc is the richness of the
code-language. I think there might be some unit problems so I'm gonna let
someone else clean up and complete the equations. Good night.

On Thu, Sep 10, 2009 at 3:52 AM, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> George Sakkis wrote:
>
>  Any such proof or even discussion should take into account what the
>> primitives (atoms and allowed operations) are.
>>
>
> Probably you should include the size of the documentation
> of the primitives used in your programming language
> manual, any other well-known literature they implicitly
> refer to, etc.
>
>  If not, here is a
>> solution that is short both in code and documentation:
>>
>>     game_of_life().solve()
>>
>
> But then you need to go and find a paper describing
> the game of life and the algorithm being used to
> solve it and include its length!
>
> --
> Greg
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Yuv
hzk.co.il
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090910/4e8bf27e/attachment.html>

From anfedorov at gmail.com  Thu Sep 10 21:50:18 2009
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Thu, 10 Sep 2009 15:50:18 -0400
Subject: [Python-ideas] Options parsing in the Tornado Web Server
Message-ID: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com>

I remember seeing a bit of discussion about improving Python's default
options parsing... Tornado's seems very impressive [1]:

> from tornado.options import define, options
>
> define("port", default=8888, help="run on the given port", type=int)
>
> print options.port
>
> What does everyone think?

- Andrey

1.
http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e49fe1b98f8f/demos/chat/chatdemo.py
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090910/920d048c/attachment.html>

From guido at python.org  Thu Sep 10 22:44:09 2009
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Sep 2009 13:44:09 -0700
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com>
Message-ID: <ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>

That's not particularly more expressive than what optparse gives you
today, except for the use of a function with a side effect on a magic
global (how the heck did options.port suddenly get a value?!) and the
potential for confusing tornado.options with tornado.options.options.

On Thu, Sep 10, 2009 at 12:50 PM, Andrey Fedorov <anfedorov at gmail.com> wrote:
> I remember seeing a bit of discussion about improving Python's default
> options parsing... Tornado's seems very impressive [1]:
>>
>> from tornado.options import define, options
>>
>> define("port", default=8888, help="run on the given port", type=int)
>>
>> print options.port
>
> What does everyone think?
>
> - Andrey
>
> 1.
> http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e49fe1b98f8f/demos/chat/chatdemo.py

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From anfedorov at gmail.com  Thu Sep 10 22:52:24 2009
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Thu, 10 Sep 2009 16:52:24 -0400
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com> 
	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
Message-ID: <7659cab30909101352u14554ca1i1a64dd07ccb8c29b@mail.gmail.com>

Well, options.*port* corresponds to define("*port*", ...). Is it considered
unPythonic to equate variable names and strings? I didn't think it was,
since scopes are dictionaries...

Good point about options.options.

- Andrey

On Thu, Sep 10, 2009 at 4:44 PM, Guido van Rossum <guido at python.org> wrote:

> That's not particularly more expressive than what optparse gives you
> today, except for the use of a function with a side effect on a magic
> global (how the heck did options.port suddenly get a value?!) and the
> potential for confusing tornado.options with tornado.options.options.
>
> On Thu, Sep 10, 2009 at 12:50 PM, Andrey Fedorov <anfedorov at gmail.com>
> wrote:
> > I remember seeing a bit of discussion about improving Python's default
> > options parsing... Tornado's seems very impressive [1]:
> >>
> >> from tornado.options import define, options
> >>
> >> define("port", default=8888, help="run on the given port", type=int)
> >>
> >> print options.port
> >
> > What does everyone think?
> >
> > - Andrey
> >
> > 1.
> >
> http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e49fe1b98f8f/demos/chat/chatdemo.py
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090910/1b744244/attachment.html>

From ncoghlan at gmail.com  Thu Sep 10 23:11:54 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Sep 2009 07:11:54 +1000
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <7659cab30909101352u14554ca1i1a64dd07ccb8c29b@mail.gmail.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com>
	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
	<7659cab30909101352u14554ca1i1a64dd07ccb8c29b@mail.gmail.com>
Message-ID: <4AA96B9A.6020505@gmail.com>

Andrey Fedorov wrote:
> Well, options._port_ corresponds to define("_port_", ...). Is it
> considered unPythonic to equate variable names and strings? I didn't
> think it was, since scopes are dictionaries...

It's the fact that there is an options global in the module at all which
can be surprising.

Application global objects like that aren't necessarily bad, but they
aren't necessarily good either. optparse uses independent parsers by
default, leaving applications free to put the options information
wherever they want (e.g. merging it with settings coming from system and
per-user configuration files and storing the results in a myapp.settings
module)

An approach like the tornado example that provides its own global parser
better also have its own mechanism for producing additional independent
parsers if it ever hopes to match the features of optparse.

Aside from the presence of that global parser, I'm not seeing a lot
difference between options.define and parser.add_option though.

Anyone wanting to replace/compete with optparse (particularly with goals
for latter standard library inclusion) would do well to better
articulate what they don't like about optparse though. I acknowledge
that using optparse the first couple of times can have something of a
learning curve, but that's because it is rather powerful.

And if there are features that appear to be missing, then why not
suggest those as optparse enhancements rather than trying to replace the
module wholesale?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From brett at python.org  Thu Sep 10 23:16:17 2009
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Sep 2009 14:16:17 -0700
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com> 
	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
Message-ID: <bbaeab100909101416r38f1f2f7pb3f7695bd9d5ddee@mail.gmail.com>

Just so people know, we started discussing over on the stdlib-sig the
idea of trying to convince Steven Bethard to contribute argparse to
the standard library as a way to improve the argument parsing
situation in the standard library.

On Thu, Sep 10, 2009 at 13:44, Guido van Rossum <guido at python.org> wrote:
> That's not particularly more expressive than what optparse gives you
> today, except for the use of a function with a side effect on a magic
> global (how the heck did options.port suddenly get a value?!) and the
> potential for confusing tornado.options with tornado.options.options.
>
> On Thu, Sep 10, 2009 at 12:50 PM, Andrey Fedorov <anfedorov at gmail.com> wrote:
>> I remember seeing a bit of discussion about improving Python's default
>> options parsing... Tornado's seems very impressive [1]:
>>>
>>> from tornado.options import define, options
>>>
>>> define("port", default=8888, help="run on the given port", type=int)
>>>
>>> print options.port
>>
>> What does everyone think?
>>
>> - Andrey
>>
>> 1.
>> http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e49fe1b98f8f/demos/chat/chatdemo.py
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From btaylor at gmail.com  Thu Sep 10 23:29:38 2009
From: btaylor at gmail.com (Bret Taylor)
Date: Thu, 10 Sep 2009 14:29:38 -0700 (PDT)
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com> 
	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
Message-ID: <69f2d5df-bb82-4dad-a43a-0f886df4b965@m7g2000prd.googlegroups.com>

I am Bret from FriendFeed, author of a lot of Tornado.

We modeled it after the Google option parsing (http://code.google.com/
p/google-gflags/). The main distinction is that every module declares
its own options, so your main() function doesn't need to be aware of
all of the options used by the transitive
closure of modules in your server. As anyone who has worked on large
systems knows, passing around options and defaults becomes a big pain
after your number of modules increases above 100 or so.

That said, I think our options parsing works well for individual
projects, but you would get lots of naming conflicts if it were
adopted in any official capacity by Python given the options all have
global scope, so I agree with Guido that optparse is probably better
as an official module. It certainly was much more useful to us than
optparse from an operational standpoint, though.

Bret

On Sep 10, 1:44?pm, Guido van Rossum <gu... at python.org> wrote:
> That's not particularly more expressive than what optparse gives you
> today, except for the use of a function with a side effect on a magic
> global (how the heck did options.port suddenly get a value?!) and the
> potential for confusing tornado.options with tornado.options.options.
>
>
>
> On Thu, Sep 10, 2009 at 12:50 PM, Andrey Fedorov <anfedo... at gmail.com> wrote:
> > I remember seeing a bit of discussion about improving Python's default
> > options parsing... Tornado's seems very impressive [1]:
>
> >> from tornado.options import define, options
>
> >> define("port", default=8888, help="run on the given port", type=int)
>
> >> print options.port
>
> > What does everyone think?
>
> > - Andrey
>
> > 1.
> >http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e...
>
> --
> --Guido van Rossum (home page:http://www.python.org/~guido/)
> _______________________________________________
> Python-ideas mailing list
> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas


From guido at python.org  Thu Sep 10 23:42:21 2009
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Sep 2009 14:42:21 -0700
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <69f2d5df-bb82-4dad-a43a-0f886df4b965@m7g2000prd.googlegroups.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com> 
	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com> 
	<69f2d5df-bb82-4dad-a43a-0f886df4b965@m7g2000prd.googlegroups.com>
Message-ID: <ca471dc20909101442m2d3cefcdr373f92911fa165bf@mail.gmail.com>

Hey Bret!

I still see your name in our code base a lot... :-)

The Google flags code has a fundamentally different use case than the
typical argument parsing -- thanks for pointing this out. In fact, the
two use cases are so different that there is barely any overlap. (What
Google does with flags is more typically done with environment
variables, although I totally understand that that didn't work for
you.) Maybe the discussion about flags parsing (which is apparently
happening on a list I'm not on :-) is helped by clearly distinguishing
the two styles.

--Guido

On Thu, Sep 10, 2009 at 2:29 PM, Bret Taylor <btaylor at gmail.com> wrote:
> I am Bret from FriendFeed, author of a lot of Tornado.
>
> We modeled it after the Google option parsing (http://code.google.com/
> p/google-gflags/). The main distinction is that every module declares
> its own options, so your main() function doesn't need to be aware of
> all of the options used by the transitive
> closure of modules in your server. As anyone who has worked on large
> systems knows, passing around options and defaults becomes a big pain
> after your number of modules increases above 100 or so.
>
> That said, I think our options parsing works well for individual
> projects, but you would get lots of naming conflicts if it were
> adopted in any official capacity by Python given the options all have
> global scope, so I agree with Guido that optparse is probably better
> as an official module. It certainly was much more useful to us than
> optparse from an operational standpoint, though.
>
> Bret
>
> On Sep 10, 1:44?pm, Guido van Rossum <gu... at python.org> wrote:
>> That's not particularly more expressive than what optparse gives you
>> today, except for the use of a function with a side effect on a magic
>> global (how the heck did options.port suddenly get a value?!) and the
>> potential for confusing tornado.options with tornado.options.options.
>>
>>
>>
>> On Thu, Sep 10, 2009 at 12:50 PM, Andrey Fedorov <anfedo... at gmail.com> wrote:
>> > I remember seeing a bit of discussion about improving Python's default
>> > options parsing... Tornado's seems very impressive [1]:
>>
>> >> from tornado.options import define, options
>>
>> >> define("port", default=8888, help="run on the given port", type=int)
>>
>> >> print options.port
>>
>> > What does everyone think?
>>
>> > - Andrey
>>
>> > 1.
>> >http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e...
>>
>> --
>> --Guido van Rossum (home page:http://www.python.org/~guido/)
>> _______________________________________________
>> Python-ideas mailing list
>> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From collinw at gmail.com  Thu Sep 10 23:58:35 2009
From: collinw at gmail.com (Collin Winter)
Date: Thu, 10 Sep 2009 18:58:35 -0300
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <ca471dc20909101442m2d3cefcdr373f92911fa165bf@mail.gmail.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com>
	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>
	<69f2d5df-bb82-4dad-a43a-0f886df4b965@m7g2000prd.googlegroups.com>
	<ca471dc20909101442m2d3cefcdr373f92911fa165bf@mail.gmail.com>
Message-ID: <43aa6ff70909101458k4ece6909hf2cf411de8926f88@mail.gmail.com>

On Thu, Sep 10, 2009 at 6:42 PM, Guido van Rossum <guido at python.org> wrote:
> Hey Bret!
>
> I still see your name in our code base a lot... :-)
>
> The Google flags code has a fundamentally different use case than the
> typical argument parsing -- thanks for pointing this out. In fact, the
> two use cases are so different that there is barely any overlap. (What
> Google does with flags is more typically done with environment
> variables, although I totally understand that that didn't work for
> you.)

Other useful notes about the Google flag systems (most of which sounds
like it applies to Tornado's system as well), for those who haven't
used it:
- Google's flag system is used primarily for configuring binaries,
rather than command-line option parsing; it just happens to take the
form of command-line options.
- Accordingly, having a single global options dict is useful for
configuring all the different libraries that get linked into a single
binary. Most of the flags a given binary exposes come from these
libraries, or libraries used by other libraries, etc.
- When defining flags in libraries, you have to manually namespace
them (mylibrary_rpc_deadline_secs, yourlibrary_rpc_deadline_secs, etc)
to avoid collisions.
- The flags system is designed to operate across languages: a Python
application can define some flags, and that application may use a C++
extension module which defines more flags, and both are configured in
the same place.

Based on that, I'm not sure that a gflags-like system would be a good
replacement for command-line parsing. In fact, gflags sometimes
requires unexpected/unusual command-line ordering if you try to use it
like a general option parser.

Other people who've used gflags may have a different perspective.

Collin Winter


From eric at trueblade.com  Fri Sep 11 10:59:26 2009
From: eric at trueblade.com (Eric Smith)
Date: Fri, 11 Sep 2009 04:59:26 -0400
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <4AA96B9A.6020505@gmail.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com>	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>	<7659cab30909101352u14554ca1i1a64dd07ccb8c29b@mail.gmail.com>
	<4AA96B9A.6020505@gmail.com>
Message-ID: <4AAA116E.9080504@trueblade.com>

Nick Coghlan wrote:
> Anyone wanting to replace/compete with optparse (particularly with goals
> for latter standard library inclusion) would do well to better
> articulate what they don't like about optparse though. I acknowledge
> that using optparse the first couple of times can have something of a
> learning curve, but that's because it is rather powerful.

Note that argparse does provide that justification:
http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html

In particular:
http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html#upgrading-optparse-code
has a short blurb on why Steven didn't just extend optparse. He tried 
to, but decided it was easier if he didn't.

Eric.



From eric at trueblade.com  Fri Sep 11 11:10:22 2009
From: eric at trueblade.com (Eric Smith)
Date: Fri, 11 Sep 2009 05:10:22 -0400
Subject: [Python-ideas] Options parsing in the Tornado Web Server
In-Reply-To: <4AAA116E.9080504@trueblade.com>
References: <7659cab30909101250h46ee269ch28c5b21e9fa9c9d5@mail.gmail.com>	<ca471dc20909101344s3cb114e8p1970868caeb605ad@mail.gmail.com>	<7659cab30909101352u14554ca1i1a64dd07ccb8c29b@mail.gmail.com>	<4AA96B9A.6020505@gmail.com>
	<4AAA116E.9080504@trueblade.com>
Message-ID: <4AAA13FE.7050002@trueblade.com>

Eric Smith wrote:
> Nick Coghlan wrote:
>> Anyone wanting to replace/compete with optparse (particularly with goals
>> for latter standard library inclusion) would do well to better
>> articulate what they don't like about optparse though. I acknowledge
>> that using optparse the first couple of times can have something of a
>> learning curve, but that's because it is rather powerful.
> 
> Note that argparse does provide that justification:
> http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html
> 
> In particular:
> http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html#upgrading-optparse-code 
> 
> has a short blurb on why Steven didn't just extend optparse. He tried 
> to, but decided it was easier if he didn't.

And I notice now that this has already been posted to stdlib-sig, which 
I've joined. I'll continue this over there.


From ubershmekel at gmail.com  Fri Sep 11 17:16:50 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Fri, 11 Sep 2009 18:16:50 +0300
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <4A9BF08C.9060607@mrabarnett.plus.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>
	<4A9BC96B.2010207@gmail.com>
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>
	<4A9BF08C.9060607@mrabarnett.plus.com>
Message-ID: <9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>

Does anybody have any more use cases, ideas or suggestions? I'm getting the
feeling this suggestion is +0 to most people and +1 for the rest. I'm pretty
new to these mailing lists so does that mean a yes or a no?

On Mon, Aug 31, 2009 at 6:47 PM, MRAB <python at mrabarnett.plus.com> wrote:

> Masklinn wrote:
>
>> On 31 Aug 2009, at 15:00 , Nick Coghlan wrote:
>> Yuvgoog Greenle wrote:
>>
>>> I believe int(s, base) needs an inverse function to allow string
>>>> representation with different bases. An example use case is 'hashing' a
>>>> counter like video ID's on youtube, you could use a regular int
>>>> internally and publish a shorter base-62 id
>>>> for links.
>>>>
>>>> This subject was discussed 2.5 years ago:
>>>> http://mail.python.org/pipermail/python-dev/2006-January/059789.html
>>>>
>>>> I opened a feature request ticket:
>>>> http://bugs.python.org/issue6783
>>>>
>>>> Some of the questions that remain:
>>>> 1. Whether this should be a method for int or a regular function in a
>>>> standard library module like math.
>>>> 2. What should the method/function be called? (base_convert, radix, etc)
>>>>
>>>> What do you guys think?
>>>>
>>>
>>> This has been coming up for years and always gets bogged down in a
>>> spelling argument (a method on int, a function in the math module and an
>>> update to the str.format mini language would be the current contenders).
>>>
>>> However, most of the actual real use cases for bases between 2 and 36
>>> were dealt with by the addition of binary and octal output to string
>>> formatting so the impetus to do anything about it is now a lot lower.
>>>
>>> As far as bases between 37 and 62 go, that would involve first getting
>>> agreement on extending int() to handle those bases by allowing case
>>> sensitive digit parsing. Presumably that would use string lexical
>>> ordering so that int('a', 37) > int('A', 37) and int('b', 37) would
>>> raise an exception.
>>>
>>> That would only be intuitive to someone that knows how ASCII based
>>> alphanumeric ordering works though.
>>>
>>
> ASCII? Surely it should be Unicode! :-)
>
>  Or it could be handled via a translation table (needed both ways of
>> course) mapping n indexes to n characters (with n the base you're working
>> with), defaulting to something sane.
>>
>>  The default could cover only bases 2 to 36. Any base > 36 would require
> a user-supplied translation table.
>
>  Though I'm not sure this is of much interest really: even Erlang (which
>> provides pretty good base conversion tools: it supports literal integers of
>> any base between 2 and 36) doesn't natively support bases beyond 36. A
>> library would probably be better for those more conflictual (or less
>> intuitive) ranges.
>>
>>  It could permit a dict as the translation table when 'decoding' so that
> both 'A' and 'a' could be mapped to 10, if necessary.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090911/8b727bb6/attachment.html>

From ncoghlan at gmail.com  Fri Sep 11 18:08:28 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Sep 2009 02:08:28 +1000
Subject: [Python-ideas] Add a builtin method to 'int' for
	base/radix	conversion
In-Reply-To: <9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>	<4A9BC96B.2010207@gmail.com>	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
Message-ID: <4AAA75FC.4000001@gmail.com>

Yuvgoog Greenle wrote:
> Does anybody have any more use cases, ideas or suggestions? I'm getting
> the feeling this suggestion is +0 to most people and +1 for the rest.
> I'm pretty new to these mailing lists so does that mean a yes or a no?

A generally lukewarm response means a maybe :)

A positive response on python-ideas is still a maybe until the idea has
subsequently also run the gauntlet of python-dev with actual code to
back it up.

In this case, the status quo is:

str -> int (arbitrary base up to 36) via int() constructor (base "0"
meaning Python literal format).

int -> str via str() (for decimal output), hex(), oct(), bin() and
string formatting

So the currently unsupported use cases are limited to outputting numbers
in bases between 3 and 36 that are not 8, 10 or 16.

You're probably going to have a hard time convincing anyone that those
additional use cases are worth putting much effort into supporting (and
even then, they're probably better off as a 3rd party library that can
add things like support for integers in bases up to 62).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From python at mrabarnett.plus.com  Fri Sep 11 21:51:55 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 11 Sep 2009 20:51:55 +0100
Subject: [Python-ideas] Add a builtin method to 'int' for
	base/radix	conversion
In-Reply-To: <4AAA75FC.4000001@gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>	<4A9BC96B.2010207@gmail.com>	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
	<4AAA75FC.4000001@gmail.com>
Message-ID: <4AAAAA5B.2060500@mrabarnett.plus.com>

Nick Coghlan wrote:
> Yuvgoog Greenle wrote:
>> Does anybody have any more use cases, ideas or suggestions? I'm getting
>> the feeling this suggestion is +0 to most people and +1 for the rest.
>> I'm pretty new to these mailing lists so does that mean a yes or a no?
> 
> A generally lukewarm response means a maybe :)
> 
> A positive response on python-ideas is still a maybe until the idea has
> subsequently also run the gauntlet of python-dev with actual code to
> back it up.
> 
> In this case, the status quo is:
> 
> str -> int (arbitrary base up to 36) via int() constructor (base "0"
> meaning Python literal format).
> 
> int -> str via str() (for decimal output), hex(), oct(), bin() and
> string formatting
> 
> So the currently unsupported use cases are limited to outputting numbers
> in bases between 3 and 36 that are not 8, 10 or 16.
> 
> You're probably going to have a hard time convincing anyone that those
> additional use cases are worth putting much effort into supporting (and
> even then, they're probably better off as a 3rd party library that can
> add things like support for integers in bases up to 62).
> 
It's one of those ideas:

Q: Do you think it's a good idea?
A: Yes.
Q: Do you think you'd use it?
A: Probably not.

:-)


From dickinsm at gmail.com  Sun Sep 13 20:06:22 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sun, 13 Sep 2009 19:06:22 +0100
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>
	<4A9BC96B.2010207@gmail.com>
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>
	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
Message-ID: <5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>

On Fri, Sep 11, 2009 at 4:16 PM, Yuvgoog Greenle <ubershmekel at gmail.com> wrote:
> Does anybody have any more use cases, ideas or suggestions? I'm getting the
> feeling this suggestion is +0 to most people and +1 for the rest. I'm pretty
> new to these mailing lists so does that mean a yes or a no?

Just out of curiosity, I did a Google code search[*] for uses of the
inverse operation: int(<some_string> ,n).  I found a good handful of
uses of int(s, 36), almost all apparently to do with turning integers
into suitable id strings;  there was also evidence that people have
implemented the reverse 'integer -> base 36 string' conversion at
least twice.  I found no meaningful uses of any bases other than
2, 8, 10, 16, and 36.  So the main use case seems to be
serialization and deserialization of integers into some 'suitably nice'
alphabet, and that alphabet is likely to be application-dependent.

-0 for int.to_base(n) (2 <= n <= 36) or equivalent functionality in the core.

+0 for a pair of library functions converting to and from base n, with
explicitly given translation table.  I agree with MRAB that an implicit
digit set should only be allowed for 2 <= base <= 36, if at all.

By the way, _PyLong_Format in Objects/longobject.c *does* contain
code for general integer -> base b conversions, 2 <= b <= 36,
but that code is currently unused (as far as I can tell).

Mark

[*] http://www.google.com/codesearch?hl=en&lr=&q=%5CWint%5Cs*%5C%28.*%5C%2C%5Cs*36%5Cs*%5C%29+lang%3Apython&sbtn=Search


From gerald.britton at gmail.com  Sun Sep 13 20:10:45 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Sun, 13 Sep 2009 14:10:45 -0400
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
Message-ID: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>

Hi -- This is maybe the wrong list for this question.  If would
someone please redirect me?

I stumbled across a performance anomaly wrt the set.add method.  My
idea was that if I try to add something via set.add, the method has to
first check if the new item is already in the set, since set items are
supposed to be unique.  Then, on a whim, I stuck an "if x in set"
condition in front of it.  I was surprised to learn that this latter
approach runs faster!  Here are some results:

$ python -m timeit -n 1000000  -s 'with open("/usr/share/dict/words")
as f: s = set(w.strip("\n") for w in f)'  's.add("mother")'
1000000 loops, best of 3: 0.292 usec per loop

britton at TheBrittons:~$ python -m timeit -n 1000000  -s 'with
open("/usr/share/dict/words") as f: s = set(w.strip("\n") for w in f)'
 'if "mother" not in s:s.add("mother")'
1000000 loops, best of 3: 0.185 usec per loop

the second example beats the first by about 36%

Is the timing difference just the cost of the method lookup for s.add,
or is something else happening that I'm not seeing?

-- 
Gerald Britton


From python at rcn.com  Sun Sep 13 21:37:07 2009
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 13 Sep 2009 12:37:07 -0700
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>
Message-ID: <440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>


On Sep 13, 2009, at 11:10 AM, Gerald Britton wrote:
>  Here are some results:
>
> $ python -m timeit -n 1000000  -s 'with open("/usr/share/dict/words")
> as f: s = set(w.strip("\n") for w in f)'  's.add("mother")'
> 1000000 loops, best of 3: 0.292 usec per loop
>
> britton at TheBrittons:~$ python -m timeit -n 1000000  -s 'with
> open("/usr/share/dict/words") as f: s = set(w.strip("\n") for w in f)'
> 'if "mother" not in s:s.add("mother")'
> 1000000 loops, best of 3: 0.185 usec per loop
>
> the second example beats the first by about 36%
>
> Is the timing difference just the cost of the method lookup for s.add,
> or is something else happening that I'm not seeing?

It is the something else you're not seeing ;-)

On the first pass of the 1000000 loops, "mother" gets added.
On the remaining passes the 'if "mother" not in set' test fails
and the set.add() never gets executed.  That latter operation
is a bit more expensive than the contains-test because it
includes the time to lookup and bind the add method.


Raymond



From bernie at codewiz.org  Sun Sep 13 23:25:23 2009
From: bernie at codewiz.org (Bernie Innocenti)
Date: Sun, 13 Sep 2009 17:25:23 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
Message-ID: <1252877123.19979.43.camel@giskard>

On startup, the Python interpreter changes the default behavior
of SIGINT, which results in  many Python programs to ignore the
keyboard interrupt exactly in the situations when users are
most likely to use it (i.e.: when the program becomes unresponsive).

Minimal testcase:
 $ echo "void foo() { for(;;) {} }" >foo.c
 $ gcc -shared -o foo.so foo.c
 $ python -c 'import ctypes;ctypes.CDLL("./foo.so").foo()'
 ^C^C^C
 ^C
 ^C DAMN!
 ^C

This scenario mimics a Python program calling some blocking library
function.  It can also happen with IO-bound functions if they loop
on read() and don't abort on short reads.

One might be tempted to say "this behavior of the Python intepreter
is by design" and suggest users to use CTRL-\ instead of CTRL-C.
However, this non-standard behavior is very annoying for users who
expect ^C to work on UNIX systems.  In fact, no other compiled or
interpreted language I know of behaves this way, and Python should
not be the only exception.

While I see the usefulness of KeyboardInterrupt from the programmer
point of view, only a minority of programs actually need to trap
SIGINT and do something with it.  Other language runtimes require
the programmer to manually trap SIGINT when needed.  The Python
interpreter could maintain backwards compatibility by enabling
automatic SIGINT trapping when entering a  "try" block that would
intercept KeyboardInterrupt.

For 2 years, I've been using this workaround in my
/usr/lib64/python2.6/sitecustomize.py:

----cut-----
import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)
----cut-----

CTRL-C has been working perfectly ever since.  So far, I have
not yet found a single Python program where restoring the
default behavior of SIGINT causes real issues, but there may
certainly be a few.

Granted, this is just a kludge, not a perfect fix, but from a
user perspective, it already improves upon the current behavior
(i.e. more pros than cons).  At least, this is my personal
experience.  If you're skeptical, please try the above workaround
yourself for a few months and let me know what breaks for you.

If we could break the syntax of "print" statements, I'm sure we
can also find a satisfactory compromise for CTRL-C handling that
won't affect more than 0.1% of existing Python programs.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/



From pyideas at rebertia.com  Sun Sep 13 23:32:29 2009
From: pyideas at rebertia.com (Chris Rebert)
Date: Sun, 13 Sep 2009 14:32:29 -0700
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <1252877123.19979.43.camel@giskard>
References: <1252877123.19979.43.camel@giskard>
Message-ID: <50697b2c0909131432w387cb34fl311d934d4680039f@mail.gmail.com>

On Sun, Sep 13, 2009 at 2:25 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
<snip>
> If we could break the syntax of "print" statements, I'm sure we
> can also find a satisfactory compromise for CTRL-C handling that
> won't affect more than 0.1% of existing Python programs.

What does the print syntax have to do with this? You know it became a
regular function in Python 3, right?

Cheers,
Chris
--
http://blog.rebertia.com


From benjamin at python.org  Sun Sep 13 23:35:56 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 13 Sep 2009 21:35:56 +0000 (UTC)
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
References: <1252877123.19979.43.camel@giskard>
Message-ID: <loom.20090913T233307-707@post.gmane.org>

Bernie Innocenti <bernie at ...> writes:
> If we could break the syntax of "print" statements, I'm sure we
> can also find a satisfactory compromise for CTRL-C handling that
> won't affect more than 0.1% of existing Python programs.

It would actually be a huge compatibility break because finally statments would
no longer be garunteed to execute.






From bernie at codewiz.org  Mon Sep 14 00:34:12 2009
From: bernie at codewiz.org (Bernie Innocenti)
Date: Sun, 13 Sep 2009 18:34:12 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <50697b2c0909131432w387cb34fl311d934d4680039f@mail.gmail.com>
References: <1252877123.19979.43.camel@giskard>
	<50697b2c0909131432w387cb34fl311d934d4680039f@mail.gmail.com>
Message-ID: <1252881252.19979.99.camel@giskard>

El Sun, 13-09-2009 a las 14:32 -0700, Chris Rebert escribi?:
> On Sun, Sep 13, 2009 at 2:25 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> <snip>
> > If we could break the syntax of "print" statements, I'm sure we
> > can also find a satisfactory compromise for CTRL-C handling that
> > won't affect more than 0.1% of existing Python programs.
> 
> What does the print syntax have to do with this? You know it became a
> regular function in Python 3, right?

Yes, I do.  What I meant is that changing the behavior of SIGINT would
introduce negligible incompatibilities compared to the things that were
changed in Python 3.0.

By this, I'm not implying that SIGINT handling must absolutely be
changed NOW.  It can certainly wait until the next major revision of the
language, if one is planned.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/



From pyideas at rebertia.com  Mon Sep 14 00:36:22 2009
From: pyideas at rebertia.com (Chris Rebert)
Date: Sun, 13 Sep 2009 15:36:22 -0700
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <1252881252.19979.99.camel@giskard>
References: <1252877123.19979.43.camel@giskard>
	<50697b2c0909131432w387cb34fl311d934d4680039f@mail.gmail.com>
	<1252881252.19979.99.camel@giskard>
Message-ID: <50697b2c0909131536q528674f5ued4a12ea584809ac@mail.gmail.com>

On Sun, Sep 13, 2009 at 3:34 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Sun, 13-09-2009 a las 14:32 -0700, Chris Rebert escribi?:
>> On Sun, Sep 13, 2009 at 2:25 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
>> <snip>
>> > If we could break the syntax of "print" statements, I'm sure we
>> > can also find a satisfactory compromise for CTRL-C handling that
>> > won't affect more than 0.1% of existing Python programs.
>>
>> What does the print syntax have to do with this? You know it became a
>> regular function in Python 3, right?
>
> Yes, I do. ?What I meant is that changing the behavior of SIGINT would
> introduce negligible incompatibilities compared to the things that were
> changed in Python 3.0.

Ah, my apologies, I misread that sentence in your original missive.

Cheers,
Chris


From mwm-keyword-python.b4bdba at mired.org  Mon Sep 14 01:38:47 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Sun, 13 Sep 2009 19:38:47 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <loom.20090913T233307-707@post.gmane.org>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
Message-ID: <20090913193847.1efca525@bhuda.mired.org>

On Sun, 13 Sep 2009 21:35:56 +0000 (UTC)
Benjamin Peterson <benjamin at python.org> wrote:

> Bernie Innocenti <bernie at ...> writes:
> > If we could break the syntax of "print" statements, I'm sure we
> > can also find a satisfactory compromise for CTRL-C handling that
> > won't affect more than 0.1% of existing Python programs.
> 
> It would actually be a huge compatibility break because finally statments would
> no longer be garunteed to execute.

They aren't now. os._exit() skips unwinding the try/except chain
before exiting.

     <mike

-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From python at mrabarnett.plus.com  Mon Sep 14 01:53:22 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 14 Sep 2009 00:53:22 +0100
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <loom.20090913T233307-707@post.gmane.org>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
Message-ID: <4AAD85F2.9080609@mrabarnett.plus.com>

Benjamin Peterson wrote:
> Bernie Innocenti <bernie at ...> writes:
>> If we could break the syntax of "print" statements, I'm sure we
>> can also find a satisfactory compromise for CTRL-C handling that
>> won't affect more than 0.1% of existing Python programs.
> 
> It would actually be a huge compatibility break because finally statments would
> no longer be garunteed to execute.
> 
Perhaps CTRL-C could be left as-is but also have a 'stronger' version
like SHIFT-CTRL-C.


From mwm-keyword-python.b4bdba at mired.org  Mon Sep 14 02:05:09 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Sun, 13 Sep 2009 20:05:09 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAD85F2.9080609@mrabarnett.plus.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<4AAD85F2.9080609@mrabarnett.plus.com>
Message-ID: <20090913200509.439ca1b6@bhuda.mired.org>

On Mon, 14 Sep 2009 00:53:22 +0100
MRAB <python at mrabarnett.plus.com> wrote:

> Benjamin Peterson wrote:
> > Bernie Innocenti <bernie at ...> writes:
> >> If we could break the syntax of "print" statements, I'm sure we
> >> can also find a satisfactory compromise for CTRL-C handling that
> >> won't affect more than 0.1% of existing Python programs.
> > 
> > It would actually be a huge compatibility break because finally statments would
> > no longer be garunteed to execute.
> > 
> Perhaps CTRL-C could be left as-is but also have a 'stronger' version
> like SHIFT-CTRL-C.

Possibly that will work on Windows. It won't work on Posix-compliant
systems. The tty driver handles turning characters into signals to the
controlling process, and does this in the kernel. To get a keystroke
to generate some signal, you have to chose a signal the TTY driver can
generate. Further, you need to use one that's not already used for
other things.

Needing to emulate SIGINFO on a system that doesn't support it, I wind
up choosing SIGQUIT, as we don't get much use from python core dumps
from production, whereas everything else I can't see the users giving
up readily.

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From python at mrabarnett.plus.com  Mon Sep 14 02:11:35 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 14 Sep 2009 01:11:35 +0100
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <20090913200509.439ca1b6@bhuda.mired.org>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<4AAD85F2.9080609@mrabarnett.plus.com>
	<20090913200509.439ca1b6@bhuda.mired.org>
Message-ID: <4AAD8A37.8080504@mrabarnett.plus.com>

Mike Meyer wrote:
> On Mon, 14 Sep 2009 00:53:22 +0100
> MRAB <python at mrabarnett.plus.com> wrote:
> 
>> Benjamin Peterson wrote:
>>> Bernie Innocenti <bernie at ...> writes:
>>>> If we could break the syntax of "print" statements, I'm sure we
>>>> can also find a satisfactory compromise for CTRL-C handling that
>>>> won't affect more than 0.1% of existing Python programs.
>>> It would actually be a huge compatibility break because finally statments would
>>> no longer be garunteed to execute.
>>>
>> Perhaps CTRL-C could be left as-is but also have a 'stronger' version
>> like SHIFT-CTRL-C.
> 
> Possibly that will work on Windows. It won't work on Posix-compliant
> systems. The tty driver handles turning characters into signals to the
> controlling process, and does this in the kernel. To get a keystroke
> to generate some signal, you have to chose a signal the TTY driver can
> generate. Further, you need to use one that's not already used for
> other things.
> 
> Needing to emulate SIGINFO on a system that doesn't support it, I wind
> up choosing SIGQUIT, as we don't get much use from python core dumps
> from production, whereas everything else I can't see the users giving
> up readily.
> 
How about 2 (or 3?) in rapid succession ("here's a CTRL-C, and here's
another one to show I mean it!" :-)).


From steve at pearwood.info  Mon Sep 14 02:16:21 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Mon, 14 Sep 2009 10:16:21 +1000
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <loom.20090913T233307-707@post.gmane.org>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
Message-ID: <200909141016.21945.steve@pearwood.info>

On Mon, 14 Sep 2009 07:35:56 am Benjamin Peterson wrote:
> Bernie Innocenti <bernie at ...> writes:
> > If we could break the syntax of "print" statements, I'm sure we
> > can also find a satisfactory compromise for CTRL-C handling that
> > won't affect more than 0.1% of existing Python programs.
>
> It would actually be a huge compatibility break because finally
> statments would no longer be garunteed to execute.

Guarantee not a guarantee :) Finally statements are only guaranteed to 
execute if the Python process isn't killed or otherwise interrupted. 
You can kill an unresponsive Python program from the outside, (say) 
with ctrl-\, and the finally clause never executes:

>>> try:
...     t = time.time()
...     while 1:
...         pass
... finally:
...     print "finished infinite loop in %f seconds" % (time.time() - t)
...
Quit
[steve] $

I think it's worth considering what the OP's real complaint is: namely, 
that (some? all?) C extensions can't be interrupted by ctrl-C as the 
user would expect. Is that a valid issue, or is it expected that Python 
has no control over what happens inside the C extension?



-- 
Steven D'Aprano


From stephen at xemacs.org  Mon Sep 14 02:30:30 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 14 Sep 2009 09:30:30 +0900
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <loom.20090913T233307-707@post.gmane.org>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
Message-ID: <87vdjmv049.fsf@uwakimon.sk.tsukuba.ac.jp>

Benjamin Peterson writes:

 > It would actually be a huge compatibility break because finally
 > statments would no longer be garunteed to execute.

Hey, kill -9 trumps any guarantee you can give, and that's what the
user resorts to in the use case at hand.  This is a bad thing, even
from the point of view of those who use "finally" a lot.



From greg.ewing at canterbury.ac.nz  Mon Sep 14 02:37:51 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 14 Sep 2009 12:37:51 +1200
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAD85F2.9080609@mrabarnett.plus.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<4AAD85F2.9080609@mrabarnett.plus.com>
Message-ID: <4AAD905F.1090507@canterbury.ac.nz>

MRAB wrote:

> Perhaps CTRL-C could be left as-is but also have a 'stronger' version
> like SHIFT-CTRL-C.

There's already a stronger version, it's Ctrl-\.

-- 
Greg


From python at mrabarnett.plus.com  Mon Sep 14 02:57:50 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 14 Sep 2009 01:57:50 +0100
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAD905F.1090507@canterbury.ac.nz>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<4AAD85F2.9080609@mrabarnett.plus.com>
	<4AAD905F.1090507@canterbury.ac.nz>
Message-ID: <4AAD950E.7000205@mrabarnett.plus.com>

Greg Ewing wrote:
> MRAB wrote:
> 
>> Perhaps CTRL-C could be left as-is but also have a 'stronger' version
>> like SHIFT-CTRL-C.
> 
> There's already a stronger version, it's Ctrl-\.
> 
OK, and as far as I can tell it's ctrl-break on Windows.


From greg.ewing at canterbury.ac.nz  Mon Sep 14 03:12:30 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 14 Sep 2009 13:12:30 +1200
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <200909141016.21945.steve@pearwood.info>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<200909141016.21945.steve@pearwood.info>
Message-ID: <4AAD987E.1070900@canterbury.ac.nz>

Steven D'Aprano wrote:

> You can kill an unresponsive Python program from the outside, (say) 
> with ctrl-\, and the finally clause never executes:

Yes, but you expect that signal to kill the process
immediately without bothering with any cleanup.
Ctrl-C, on the other hand, is meant to be a graceful
request to terminate cleanly. In the context of
Python, one can reasonably expect that to include
execution of finally blocks.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Mon Sep 14 03:15:58 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 14 Sep 2009 13:15:58 +1200
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <200909141016.21945.steve@pearwood.info>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<200909141016.21945.steve@pearwood.info>
Message-ID: <4AAD994E.8040908@canterbury.ac.nz>

Steven D'Aprano wrote:

> I think it's worth considering what the OP's real complaint is: namely, 
> that (some? all?) C extensions can't be interrupted by ctrl-C as the 
> user would expect. Is that a valid issue, or is it expected that Python 
> has no control over what happens inside the C extension?

I think it's an unavoidable consequence of the desire
to be able to unwind cleanly in the event of a Ctrl-C.
If it happens in the middle of arbitrary C code, you
can't just jump out of it because that could leave things
in an unpredictable state, and execution of further
Python code wouldn't be safe.

-- 
Greg


From stephen at xemacs.org  Mon Sep 14 03:23:14 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 14 Sep 2009 10:23:14 +0900
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAD8A37.8080504@mrabarnett.plus.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<4AAD85F2.9080609@mrabarnett.plus.com>
	<20090913200509.439ca1b6@bhuda.mired.org>
	<4AAD8A37.8080504@mrabarnett.plus.com>
Message-ID: <87r5uauxod.fsf@uwakimon.sk.tsukuba.ac.jp>

MRAB writes:

 > How about 2 (or 3?) in rapid succession ("here's a CTRL-C, and here's
 > another one to show I mean it!" :-)).

That's more complexity than you want to put in a signal handler.  The
way Emacs handles this is that the signal handler just enqueues a quit
event, and the event loop checks for it and handles it.  In other
places (such as looping functions) more complex QUIT processing (that
checks for repeated signals and throws to the innermost QUIT catcher)
is done, but this can only be done in "safe" places, not in the signal
handler itself.  I imagine Python works the same way and it works fine
in pure Python programs, too.

The problem here is that when you return from the signal handler,
you're trapped inside a poorly-written (for this purpose) C extension,
and Python never gets to check for the first quit, let alone repeated
ones.  In Emacs it's pretty rare to get those, because Emacs is quite
hostile to third-party C extensions, so C code QUIT-ified by the
maintainers before it's allowed to be added.  Python has lots of C
extensions, and some are going to need QUIT occasionally -- but not
often enough for the extension maintainer to notice and handle it. :-P



From mwm-keyword-python.b4bdba at mired.org  Mon Sep 14 04:41:54 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Sun, 13 Sep 2009 22:41:54 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <200909141016.21945.steve@pearwood.info>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<200909141016.21945.steve@pearwood.info>
Message-ID: <20090913224154.189bd9cb@bhuda.mired.org>

On Mon, 14 Sep 2009 10:16:21 +1000
Steven D'Aprano <steve at pearwood.info> wrote:
> I think it's worth considering what the OP's real complaint is: namely, 
> that (some? all?) C extensions can't be interrupted by ctrl-C as the 
> user would expect. Is that a valid issue, or is it expected that Python 
> has no control over what happens inside the C extension?

I think it's valid. It's expected that the USER will have some control
over what's going on in a program - in particular, that they should be
able to interrupt it pretty much any time barring a bug of some
sort. The interaction between Python's default SIGINT handling and C
extensions breaks that expectation.

It's not clear what a good solution would be, though. This problem
exists for pretty much all signal handlers - they don't get a chance
to run if there's a misbehaving C extension executing.

The simplest solution is to just not handle SIGINT by default, which
raises the objection that try/finally doesn't "work". I don't think
this will matter in most cases; the finally block is usually freeing
up some resource that is going to be freed by the process exiting as
part of default SIGINT behavior. We've certainly had similarly subtle
changes that are much harder to deal with in the 2.X line.

To me, the nasty part of such a change is the loss of traceback on
SIGINT by default. During development, hitting C-C when the python
code is in an infinite loop pretty reliably provides a traceback that
nails down the problem. Yes, I could just boilerplate that into every
program, but part of python's attraction is that such things are so
seldom needed.

I suspect this might be best dealt with by documenting how C
extensions should behave with respect to signals - particularly SIGINT
- and providing sample code for doing so.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From ubershmekel at gmail.com  Mon Sep 14 04:51:29 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Mon, 14 Sep 2009 05:51:29 +0300
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>
	<4A9BC96B.2010207@gmail.com>
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>
	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>
Message-ID: <9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>

Btw, when you say translation table, do you mean just a string? Because a
translation table would need to be continuous from 0 to the base so a real
dicitionary-esque table may be overkill. The only advantage of a table might
be to convert certain digits into multiple bytes (some sort of ad-hoc
unicode use case?).
--yuv

On Sun, Sep 13, 2009 at 9:06 PM, Mark Dickinson <dickinsm at gmail.com> wrote:

> On Fri, Sep 11, 2009 at 4:16 PM, Yuvgoog Greenle <ubershmekel at gmail.com>
> wrote:
> > Does anybody have any more use cases, ideas or suggestions? I'm getting
> the
> > feeling this suggestion is +0 to most people and +1 for the rest. I'm
> pretty
> > new to these mailing lists so does that mean a yes or a no?
>
> Just out of curiosity, I did a Google code search[*] for uses of the
> inverse operation: int(<some_string> ,n).  I found a good handful of
> uses of int(s, 36), almost all apparently to do with turning integers
> into suitable id strings;  there was also evidence that people have
> implemented the reverse 'integer -> base 36 string' conversion at
> least twice.  I found no meaningful uses of any bases other than
> 2, 8, 10, 16, and 36.  So the main use case seems to be
> serialization and deserialization of integers into some 'suitably nice'
> alphabet, and that alphabet is likely to be application-dependent.
>
> -0 for int.to_base(n) (2 <= n <= 36) or equivalent functionality in the
> core.
>
> +0 for a pair of library functions converting to and from base n, with
> explicitly given translation table.  I agree with MRAB that an implicit
> digit set should only be allowed for 2 <= base <= 36, if at all.
>
> By the way, _PyLong_Format in Objects/longobject.c *does* contain
> code for general integer -> base b conversions, 2 <= b <= 36,
> but that code is currently unused (as far as I can tell).
>
> Mark
>
> [*]
> http://www.google.com/codesearch?hl=en&lr=&q=%5CWint%5Cs*%5C%28.*%5C%2C%5Cs*36%5Cs*%5C%29+lang%3Apython&sbtn=Search
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090914/480eaef9/attachment.html>

From ubershmekel at gmail.com  Mon Sep 14 04:56:05 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Mon, 14 Sep 2009 05:56:05 +0300
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>
	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
Message-ID: <9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>

So this pattern is a valid python optimization? Funky...
Sadly, there's no way around it unless the interpreter somehow did it
magically for you.

On Sun, Sep 13, 2009 at 10:37 PM, Raymond Hettinger <python at rcn.com> wrote:

>
> On Sep 13, 2009, at 11:10 AM, Gerald Britton wrote:
>
>>  Here are some results:
>>
>> $ python -m timeit -n 1000000  -s 'with open("/usr/share/dict/words")
>> as f: s = set(w.strip("\n") for w in f)'  's.add("mother")'
>> 1000000 loops, best of 3: 0.292 usec per loop
>>
>> britton at TheBrittons:~$ python -m timeit -n 1000000  -s 'with
>> open("/usr/share/dict/words") as f: s = set(w.strip("\n") for w in f)'
>> 'if "mother" not in s:s.add("mother")'
>> 1000000 loops, best of 3: 0.185 usec per loop
>>
>> the second example beats the first by about 36%
>>
>> Is the timing difference just the cost of the method lookup for s.add,
>> or is something else happening that I'm not seeing?
>>
>
> It is the something else you're not seeing ;-)
>
> On the first pass of the 1000000 loops, "mother" gets added.
> On the remaining passes the 'if "mother" not in set' test fails
> and the set.add() never gets executed.  That latter operation
> is a bit more expensive than the contains-test because it
> includes the time to lookup and bind the add method.
>
>
> Raymond
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090914/1917f8e2/attachment.html>

From stephen at xemacs.org  Mon Sep 14 05:49:10 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 14 Sep 2009 12:49:10 +0900
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <1afaf6160909131726y444532c7h1b3dae0d3744667a@mail.gmail.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<87vdjmv049.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1afaf6160909131726y444532c7h1b3dae0d3744667a@mail.gmail.com>
Message-ID: <87ljkiuqx5.fsf@uwakimon.sk.tsukuba.ac.jp>

Benjamin Peterson writes:
 > 2009/9/13 Stephen J. Turnbull <stephen at xemacs.org>:
 > > Benjamin Peterson writes:
 > >
 > > ?> It would actually be a huge compatibility break because finally
 > > ?> statments would no longer be garunteed to execute.
 > >
 > > Hey, kill -9 trumps any guarantee you can give, and that's what the
 > > user resorts to in the use case at hand. ?This is a bad thing, even
 > > from the point of view of those who use "finally" a lot.
 > 
 > Naturally, users should be able to control their programs absolutely,
 > but C-c is supposed to tell the program to clean up all its messes
 > then exit as gracefully as possible.

Sure.  But setting things up so that C-c doesn't even get through to
the program doesn't help that cause.  Since the OP claims it works for
him, maybe the "IDEA" has merit in some more limited form, for
example, by default uninstalling the Python graceful_SIGINT_handler
when calling into a C module.  (Probably this would have to be
introduced in stages to allow extensions to update their functions as
needed -- I suppose this would be a performance hit.)

Then you could provide a with-signal-handler form of the standard
macro for defining a Python function, with the semantics that the
signal handler change gets optimized away if you specify the standard
handler.  And document that in this form the function needs to handle
the SIGINT_signaled flag (or however it works) itself, or accept the
possibility of an uninterruptible hang.


From tjreedy at udel.edu  Mon Sep 14 08:53:43 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 14 Sep 2009 02:53:43 -0400
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
Message-ID: <h8kp9o$rd7$1@ger.gmane.org>

Yuvgoog Greenle wrote:
> So this pattern is a valid python optimization?

That exactly not how I interpreted Raymond

> 
> On Sun, Sep 13, 2009 at 10:37 PM, Raymond Hettinger 
> <python at rcn.com 
> <mailto:python at rcn.com>> wrote:
> 
> 
>     On Sep 13, 2009, at 11:10 AM, Gerald Britton wrote:
> 
>          Here are some results:
> 
>         $ python -m timeit -n 1000000  -s 'with
>         open("/usr/share/dict/words")
>         as f: s = set(w.strip("\n") for w in f)'  's.add("mother")'
>         1000000 loops, best of 3: 0.292 usec per loop

Try looking up and binding the method just once, any any experienced 
Python programmer might do if doing repeated 'additions'.

-s'...: sadd=set(w.strip("\n") for w in f).add' 'sadd("mother")

>         britton at TheBrittons:~$ python -m timeit -n 1000000  -s 'with
>         open("/usr/share/dict/words") as f: s = set(w.strip("\n") for w
>         in f)'
>         'if "mother" not in s:s.add("mother")'
>         1000000 loops, best of 3: 0.185 usec per loop

Add 'sadd = s.add' at end of setup, followed by
'if "mother" not in s: sadd("mother")

I doubt second will still be faster.

>         the second example beats the first by about 36%
> 
>         Is the timing difference just the cost of the method lookup for
>         s.add,
>         or is something else happening that I'm not seeing?
> 
> 
>     It is the something else you're not seeing ;-)
> 
>     On the first pass of the 1000000 loops, "mother" gets added.
>     On the remaining passes the 'if "mother" not in set' test fails
>     and the set.add() never gets executed.  That latter operation
>     is a bit more expensive than the contains-test because it
>     includes the time to lookup and bind the add method.

My suggested alteration removes the repeated lookup and bind.

tjr



From g.brandl at gmx.net  Mon Sep 14 11:23:11 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 14 Sep 2009 09:23:11 +0000
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <h8kp9o$rd7$1@ger.gmane.org>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
	<h8kp9o$rd7$1@ger.gmane.org>
Message-ID: <h8kr4n$vn5$1@ger.gmane.org>

Terry Reedy schrieb:

>>         britton at TheBrittons:~$ python -m timeit -n 1000000  -s 'with
>>         open("/usr/share/dict/words") as f: s = set(w.strip("\n") for w
>>         in f)'
>>         'if "mother" not in s:s.add("mother")'
>>         1000000 loops, best of 3: 0.185 usec per loop
> 
> Add 'sadd = s.add' at end of setup, followed by
> 'if "mother" not in s: sadd("mother")
> 
> I doubt second will still be faster.

Well, the method also has to be *called* (think argument parsing, but in this
case that should be trivial).

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From g.brandl at gmx.net  Mon Sep 14 11:28:56 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 14 Sep 2009 09:28:56 +0000
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAD85F2.9080609@mrabarnett.plus.com>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>
	<4AAD85F2.9080609@mrabarnett.plus.com>
Message-ID: <h8krfh$vn5$2@ger.gmane.org>

MRAB schrieb:
> Benjamin Peterson wrote:
>> Bernie Innocenti <bernie at ...> writes:
>>> If we could break the syntax of "print" statements, I'm sure we
>>> can also find a satisfactory compromise for CTRL-C handling that
>>> won't affect more than 0.1% of existing Python programs.
>> 
>> It would actually be a huge compatibility break because finally statments would
>> no longer be garunteed to execute.
>> 
> Perhaps CTRL-C could be left as-is but also have a 'stronger' version
> like SHIFT-CTRL-C.

Isn't it as easy as

   signal.signal(signal.SIGINT, signal.SIG_DFL)

if you don't like the current handler?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From lie.1296 at gmail.com  Mon Sep 14 14:36:43 2009
From: lie.1296 at gmail.com (Lie Ryan)
Date: Mon, 14 Sep 2009 22:36:43 +1000
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>	<4A9BC96B.2010207@gmail.com>	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>	<4A9BF08C.9060607@mrabarnett.plus.com>	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>
	<9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
Message-ID: <h8ldd3$n42$1@ger.gmane.org>

Yuvgoog Greenle wrote:
> Btw, when you say translation table, do you mean just a string? Because 
> a translation table would need to be continuous from 0 to the base so a 
> real dicitionary-esque table may be overkill. The only advantage of a 
> table might be to convert certain digits into multiple bytes (some sort 
> of ad-hoc unicode use case?).
> 

If the translation table is limited to a string, the function would be 
very limited. For example, it might be useful to use base-change 
function to convert between an IPv4 address and integer. The common 
representation of IPv4 address uses base-255 "number" 
(0.0.0.0-255.255.255.255)



From ncoghlan at gmail.com  Mon Sep 14 15:20:27 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Sep 2009 23:20:27 +1000
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
Message-ID: <4AAE431B.2020404@gmail.com>

Yuvgoog Greenle wrote:
> So this pattern is a valid python optimization? Funky...
> 
> Sadly, there's no way around it unless the interpreter somehow did it
> magically for you.

The interpreter has no way of knowing a priori that the branch won't be
taken 999,999 times out of 1,000,000.

Think about what you are actually comparing here:

Average speed of 1 million calls to s.add(x)

Average speed of 1 million calls to "x in s" + one call to s.add(x)

Now think about the fact that s.add(x) includes a containment test plus
function call and name lookup overhead even in the case that the item is
already present in the set.

All overhead included:
$ python -m timeit -s "s = set()" "s.add(1)"
1000000 loops, best of 3: 0.197 usec per loop

Lose the attribute lookup:
$ python -m timeit -s "s = set()" -s "sadd = s.add" "sadd(1)"
10000000 loops, best of 3: 0.146 usec per loop

Skip the function call altogether most of the time:
$ python -m timeit -s "s = set()" "if 1 not in s: s.add(1)"
10000000 loops, best of 3: 0.101 usec per loop

Just do the containment test:
$ python -m timeit -s "s = set([1])" "1 not in s"
10000000 loops, best of 3: 0.1 usec per loop

Now then, lets also look at the absolute numbers we're discussing here
(on my machine, anyway). Is the fastest version twice as fast as the
slowest version? Yes it is. But that difference is only 97
*nano*seconds. And relative to the recommended approach of caching the
attribute looking, we're only saving 45 nanoseconds.

And in more realistic use cases where some items are already in the set
and some aren't, the "I'll check first" implementation can become a
pessimisation instead of an optimisation. To emphasise the point, we'll
go to the other extreme where the item is added to the set every time:

All the overhead:
$ python -m timeit -s "s = set()" "s.add(1)" "s.clear()"
1000000 loops, best of 3: 0.374 usec per loop

The "optimised" approach:
$ python -m timeit -s "s = set()" "if 1 not in s: s.add(1)" "s.clear()"
1000000 loops, best of 3: 0.444 usec per loop

Oops, looks like the approach that saves us 45 nanoseconds when the item
is already in the set may cost us up to *70* nanoseconds when it turns
out we need to add the item after all.

Caching attribute lookups before time critical loops is a good
optimisation technique that most experienced Python programmers learn.
Pre-checking a condition that a called function is just going to check
again and bail out quickly in less than 50% of cases? Usually a bad idea
- the extra checks made when the function is invoked anyway will often
cancel out any gains you make from avoiding the function call overhead.

That said, as with any micro-optimisation: time it on a range of typical
and end-case data sets. If you avoid the function call overhead often
enough, doing a pre-check may be a net win for some inner loops.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From ncoghlan at gmail.com  Mon Sep 14 15:23:29 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Sep 2009 23:23:29 +1000
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <20090913193847.1efca525@bhuda.mired.org>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>
	<20090913193847.1efca525@bhuda.mired.org>
Message-ID: <4AAE43D1.1030707@gmail.com>

Mike Meyer wrote:
> On Sun, 13 Sep 2009 21:35:56 +0000 (UTC)
> Benjamin Peterson <benjamin at python.org> wrote:
> 
>> Bernie Innocenti <bernie at ...> writes:
>>> If we could break the syntax of "print" statements, I'm sure we
>>> can also find a satisfactory compromise for CTRL-C handling that
>>> won't affect more than 0.1% of existing Python programs.
>> It would actually be a huge compatibility break because finally statments would
>> no longer be garunteed to execute.
> 
> They aren't now. os._exit() skips unwinding the try/except chain
> before exiting.

An application calling an underscore prefixed function (in the os module
no less) is significantly different to a user pressing Ctrl-C while the
application is running normally.

If a user wants to kill it ungracefully, that's what Ctrl-Break is for.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From python at mrabarnett.plus.com  Mon Sep 14 15:37:20 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 14 Sep 2009 14:37:20 +0100
Subject: [Python-ideas] Add a builtin method to 'int' for
	base/radix	conversion
In-Reply-To: <h8ldd3$n42$1@ger.gmane.org>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>	<4A9BC96B.2010207@gmail.com>	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>	<4A9BF08C.9060607@mrabarnett.plus.com>	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>	<9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
	<h8ldd3$n42$1@ger.gmane.org>
Message-ID: <4AAE4710.1060301@mrabarnett.plus.com>

Lie Ryan wrote:
> Yuvgoog Greenle wrote:
>> Btw, when you say translation table, do you mean just a string? 
>> Because a translation table would need to be continuous from 0 to the 
>> base so a real dicitionary-esque table may be overkill. The only 
>> advantage of a table might be to convert certain digits into multiple 
>> bytes (some sort of ad-hoc unicode use case?).
>>
> 
> If the translation table is limited to a string, the function would be 
> very limited. For example, it might be useful to use base-change 
> function to convert between an IPv4 address and integer. The common 
> representation of IPv4 address uses base-255 "number" 
> (0.0.0.0-255.255.255.255)
> 
If the translation table is a dict then you can decode both 'A' and 'a'
to 10. You could, of course, permit either a string or a dict, with a
string being converted to a dict.


From tjreedy at udel.edu  Mon Sep 14 16:16:58 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 14 Sep 2009 10:16:58 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAE43D1.1030707@gmail.com>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<20090913193847.1efca525@bhuda.mired.org>
	<4AAE43D1.1030707@gmail.com>
Message-ID: <h8lj8r$cip$1@ger.gmane.org>

Nick Coghlan wrote:
> Mike Meyer wrote:
>> On Sun, 13 Sep 2009 21:35:56 +0000 (UTC)
>> Benjamin Peterson <benjamin at python.org> wrote:
>>
>>> Bernie Innocenti <bernie at ...> writes:
>>>> If we could break the syntax of "print" statements, I'm sure we
>>>> can also find a satisfactory compromise for CTRL-C handling that
>>>> won't affect more than 0.1% of existing Python programs.
>>> It would actually be a huge compatibility break because finally statments would
>>> no longer be garunteed to execute.
>> They aren't now. os._exit() skips unwinding the try/except chain
>> before exiting.
> 
> An application calling an underscore prefixed function (in the os module
> no less) is significantly different to a user pressing Ctrl-C while the
> application is running normally.
> 
> If a user wants to kill it ungracefully, that's what Ctrl-Break is for.

I was not aware of that. Perhaps a deficiency in my Windows knowledge.
"Using Python" only mentions ctrl-d on unix and ctrl-z on windows.
Perhaps more could be added.



From gerald.britton at gmail.com  Mon Sep 14 16:19:06 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Mon, 14 Sep 2009 10:19:06 -0400
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <4AAE431B.2020404@gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com> 
	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com> 
	<4AAE431B.2020404@gmail.com>
Message-ID: <5d1a32000909140719k19dfcd0clac348667feae60f5@mail.gmail.com>

Interesting discussion here!  I did a little analysis:

let a = cost of "item in set"
let b = cost of set.add
let c = cost of sadd = set.add

if I do x+y additions to my set where x is number of items already in
the set and y is the number not in the set, using my original approach
I get a cost of:

   a.(x+y) + b.y     # we always test for set membership, but only add new items

for the "if item not in set: set.add(item)" approach, or

   a.(x+y) + c.y,  if I substitute sadd for set.add

If I always add the item to the set without checking first, the cost is

  b.(x+y)   (or c.(x+y) using sadd)

assuming that set.add() takes close to the same time whether the item
is in the set or not (in reality I suppose that it needs to play with
a few pointers if the item is not in the set and may need to rebalance
the tree, if it is a red-black tree or something similar -- what is
it, actually?)

That means that break-even should happen when:

a.(x+y) +b.y = b.(x+y)

ax + ay + by = bx + by

ay = (b-a)x

y = ((b-a)/a)x

plugging in the numbers from earlier in this thread, we have:

a = .276 uS
b = .489 uS
c = .298uS

(b-a)/a = .772
(c-a)/a = .08

so the approach "if item not in set: set.add(item)" wins when the
number of items not added to the set (thus failing the "if" statement)
 >= 23% of those that are added.  Setting sadd = set.add beforehand
increases that break-even point to about 92% (almost no advantage).

Lesson learned: If you know (or can reasonably test) your sample data,
you can choose the better method.  If your data is unknown (random
from your viewpoint), you could assume that about half the items to be
added are already in the set, which is < 92%, so there is no point in
doing the "if item in set" test beforehand.

YMMV

On Mon, Sep 14, 2009 at 9:20 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Yuvgoog Greenle wrote:
>> So this pattern is a valid python optimization? Funky...
>>
>> Sadly, there's no way around it unless the interpreter somehow did it
>> magically for you.
>
> The interpreter has no way of knowing a priori that the branch won't be
> taken 999,999 times out of 1,000,000.
>
> Think about what you are actually comparing here:
>
> Average speed of 1 million calls to s.add(x)
>
> Average speed of 1 million calls to "x in s" + one call to s.add(x)
>
> Now think about the fact that s.add(x) includes a containment test plus
> function call and name lookup overhead even in the case that the item is
> already present in the set.
>
> All overhead included:
> $ python -m timeit -s "s = set()" "s.add(1)"
> 1000000 loops, best of 3: 0.197 usec per loop
>
> Lose the attribute lookup:
> $ python -m timeit -s "s = set()" -s "sadd = s.add" "sadd(1)"
> 10000000 loops, best of 3: 0.146 usec per loop
>
> Skip the function call altogether most of the time:
> $ python -m timeit -s "s = set()" "if 1 not in s: s.add(1)"
> 10000000 loops, best of 3: 0.101 usec per loop
>
> Just do the containment test:
> $ python -m timeit -s "s = set([1])" "1 not in s"
> 10000000 loops, best of 3: 0.1 usec per loop
>
> Now then, lets also look at the absolute numbers we're discussing here
> (on my machine, anyway). Is the fastest version twice as fast as the
> slowest version? Yes it is. But that difference is only 97
> *nano*seconds. And relative to the recommended approach of caching the
> attribute looking, we're only saving 45 nanoseconds.
>
> And in more realistic use cases where some items are already in the set
> and some aren't, the "I'll check first" implementation can become a
> pessimisation instead of an optimisation. To emphasise the point, we'll
> go to the other extreme where the item is added to the set every time:
>
> All the overhead:
> $ python -m timeit -s "s = set()" "s.add(1)" "s.clear()"
> 1000000 loops, best of 3: 0.374 usec per loop
>
> The "optimised" approach:
> $ python -m timeit -s "s = set()" "if 1 not in s: s.add(1)" "s.clear()"
> 1000000 loops, best of 3: 0.444 usec per loop
>
> Oops, looks like the approach that saves us 45 nanoseconds when the item
> is already in the set may cost us up to *70* nanoseconds when it turns
> out we need to add the item after all.
>
> Caching attribute lookups before time critical loops is a good
> optimisation technique that most experienced Python programmers learn.
> Pre-checking a condition that a called function is just going to check
> again and bail out quickly in less than 50% of cases? Usually a bad idea
> - the extra checks made when the function is invoked anyway will often
> cancel out any gains you make from avoiding the function call overhead.
>
> That said, as with any micro-optimisation: time it on a range of typical
> and end-case data sets. If you avoid the function call overhead often
> enough, doing a pre-check may be a net win for some inner loops.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan ? | ? ncoghlan at gmail.com ? | ? Brisbane, Australia
> ---------------------------------------------------------------
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From daniel at stutzbachenterprises.com  Mon Sep 14 16:26:04 2009
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Mon, 14 Sep 2009 09:26:04 -0500
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <5d1a32000909140719k19dfcd0clac348667feae60f5@mail.gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>
	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
	<4AAE431B.2020404@gmail.com>
	<5d1a32000909140719k19dfcd0clac348667feae60f5@mail.gmail.com>
Message-ID: <eae285400909140726k4a45d2b1t80f8dd2cce4c9e06@mail.gmail.com>

On Mon, Sep 14, 2009 at 9:19 AM, Gerald Britton <gerald.britton at gmail.com>wrote:

> assuming that set.add() takes close to the same time whether the item
> is in the set or not (in reality I suppose that it needs to play with
> a few pointers if the item is not in the set and may need to rebalance
> the tree, if it is a red-black tree or something similar -- what is
> it, actually?)
>

Under the hood, the set type uses a hash table.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090914/1238d388/attachment.html>

From stephen at xemacs.org  Mon Sep 14 16:57:21 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 14 Sep 2009 23:57:21 +0900
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAE43D1.1030707@gmail.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<20090913193847.1efca525@bhuda.mired.org>
	<4AAE43D1.1030707@gmail.com>
Message-ID: <8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>

Nick Coghlan writes:

 > If a user wants to kill it ungracefully, that's what Ctrl-Break is for.

Discussion of how to spell SIGKILL looks like bikeshed painting to me,
but the question of how to extend graceful interrupt behavior to C
modules looks worthy of an idea to me.

Is that too hard or too rare a need?


From gerald.britton at gmail.com  Mon Sep 14 17:03:15 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Mon, 14 Sep 2009 11:03:15 -0400
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <eae285400909140726k4a45d2b1t80f8dd2cce4c9e06@mail.gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com> 
	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com> 
	<4AAE431B.2020404@gmail.com>
	<5d1a32000909140719k19dfcd0clac348667feae60f5@mail.gmail.com> 
	<eae285400909140726k4a45d2b1t80f8dd2cce4c9e06@mail.gmail.com>
Message-ID: <5d1a32000909140803o58f3aa2qe6b6892e8fa15228@mail.gmail.com>

Aha ok, so cheap inserts, not so cheap lookups (especially if not found)

On Mon, Sep 14, 2009 at 10:26 AM, Daniel Stutzbach
<daniel at stutzbachenterprises.com> wrote:
> On Mon, Sep 14, 2009 at 9:19 AM, Gerald Britton <gerald.britton at gmail.com>
> wrote:
>>
>> assuming that set.add() takes close to the same time whether the item
>> is in the set or not (in reality I suppose that it needs to play with
>> a few pointers if the item is not in the set and may need to rebalance
>> the tree, if it is a red-black tree or something similar -- what is
>> it, actually?)
>
> Under the hood, the set type uses a hash table.
>
> --
> Daniel Stutzbach, Ph.D.
> President, Stutzbach Enterprises, LLC



-- 
Gerald Britton


From daniel at stutzbachenterprises.com  Mon Sep 14 17:13:32 2009
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Mon, 14 Sep 2009 10:13:32 -0500
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <5d1a32000909140803o58f3aa2qe6b6892e8fa15228@mail.gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>
	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
	<4AAE431B.2020404@gmail.com>
	<5d1a32000909140719k19dfcd0clac348667feae60f5@mail.gmail.com>
	<eae285400909140726k4a45d2b1t80f8dd2cce4c9e06@mail.gmail.com>
	<5d1a32000909140803o58f3aa2qe6b6892e8fa15228@mail.gmail.com>
Message-ID: <eae285400909140813i734397a7g327348e4b34bddc0@mail.gmail.com>

On Mon, Sep 14, 2009 at 10:03 AM, Gerald Britton
<gerald.britton at gmail.com>wrote:

> Aha ok, so cheap inserts, not so cheap lookups (especially if not found)
>

Eh?

The average case lookup cost for a hash table is O(1), better than most tree
structures which typically have a cost of O(log n).

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090914/4d34b663/attachment.html>

From g.brandl at gmx.net  Mon Sep 14 19:40:58 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 14 Sep 2009 19:40:58 +0200
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <h8krfh$vn5$2@ger.gmane.org>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<4AAD85F2.9080609@mrabarnett.plus.com>
	<h8krfh$vn5$2@ger.gmane.org>
Message-ID: <h8loa5$uu9$1@ger.gmane.org>

Georg Brandl schrieb:
> MRAB schrieb:
>> Benjamin Peterson wrote:
>>> Bernie Innocenti <bernie at ...> writes:
>>>> If we could break the syntax of "print" statements, I'm sure we
>>>> can also find a satisfactory compromise for CTRL-C handling that
>>>> won't affect more than 0.1% of existing Python programs.
>>> 
>>> It would actually be a huge compatibility break because finally statments would
>>> no longer be garunteed to execute.
>>> 
>> Perhaps CTRL-C could be left as-is but also have a 'stronger' version
>> like SHIFT-CTRL-C.
> 
> Isn't it as easy as
> 
>    signal.signal(signal.SIGINT, signal.SIG_DFL)
> 
> if you don't like the current handler?

I'm sorry, this was actually in the OP.

Hopefully our diversity statement will include the reading-impaired :)

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From ncoghlan at gmail.com  Mon Sep 14 22:44:58 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Sep 2009 06:44:58 +1000
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <5d1a32000909140803o58f3aa2qe6b6892e8fa15228@mail.gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com>
	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com>
	<4AAE431B.2020404@gmail.com>
	<5d1a32000909140719k19dfcd0clac348667feae60f5@mail.gmail.com>
	<eae285400909140726k4a45d2b1t80f8dd2cce4c9e06@mail.gmail.com>
	<5d1a32000909140803o58f3aa2qe6b6892e8fa15228@mail.gmail.com>
Message-ID: <4AAEAB4A.8090707@gmail.com>

Gerald Britton wrote:
> Aha ok, so cheap inserts, not so cheap lookups (especially if not found)

Other way around - lookup is cheap (unless you have an expensive hash
calculation or poor hash diversity), addition can be more expensive
(although the set C implementation is optimised pretty well).

Note that this does mean the relative benefits of the LBYL
(Look-Before-You-Leap) approach and the EAFP
(Easier-to-Ask-Forgiveness-than-Permission) approach vary based on the
data types involved. I would get different performance numbers using
strings or floats or Decimal objects rather than ints because the
relative cost of the hash() calculation would change.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From ncoghlan at gmail.com  Mon Sep 14 22:51:32 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Sep 2009 06:51:32 +1000
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<20090913193847.1efca525@bhuda.mired.org>	<4AAE43D1.1030707@gmail.com>
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4AAEACD4.2080605@gmail.com>

Stephen J. Turnbull wrote:
> Discussion of how to spell SIGKILL looks like bikeshed painting to me,
> but the question of how to extend graceful interrupt behavior to C
> modules looks worthy of an idea to me.
> 
> Is that too hard or too rare a need?

If someone can come up with an adequate C API spelling of the change
(e.g. a PYTHON_BEGIN_ALLOW_SIGINT_ABORT/PYTHON_END_ALLOW_SIGINT_ABORT)
and define it in such a way that the burden for cleaning up before
resumption of execution of Python code is placed on the developer using
the new API then I'd be +1.

For a C API spelling with the semantics of a genuine C abort for the
duration, I'd probably be -0 at best. I like Ctrl-C hitting exception
handlers and finally clauses.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From g.brandl at gmx.net  Tue Sep 15 01:21:13 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 15 Sep 2009 01:21:13 +0200
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAEACD4.2080605@gmail.com>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<20090913193847.1efca525@bhuda.mired.org>	<4AAE43D1.1030707@gmail.com>	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4AAEACD4.2080605@gmail.com>
Message-ID: <h8mc84$aim$1@ger.gmane.org>

Nick Coghlan schrieb:
> Stephen J. Turnbull wrote:
>> Discussion of how to spell SIGKILL looks like bikeshed painting to me,
>> but the question of how to extend graceful interrupt behavior to C
>> modules looks worthy of an idea to me.
>> 
>> Is that too hard or too rare a need?
> 
> If someone can come up with an adequate C API spelling of the change
> (e.g. a PYTHON_BEGIN_ALLOW_SIGINT_ABORT/PYTHON_END_ALLOW_SIGINT_ABORT)
> and define it in such a way that the burden for cleaning up before
> resumption of execution of Python code is placed on the developer using
> the new API then I'd be +1.

Do you think people would use it?  It's already hard to convince them of
using the thread state macros correctly, and the benefit of doing that
is subjectively much larger (multithreading works without blocking) than
for the SIGINT handling.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From ncoghlan at gmail.com  Tue Sep 15 00:05:31 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Sep 2009 08:05:31 +1000
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <h8mc84$aim$1@ger.gmane.org>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<20090913193847.1efca525@bhuda.mired.org>	<4AAE43D1.1030707@gmail.com>	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>	<4AAEACD4.2080605@gmail.com>
	<h8mc84$aim$1@ger.gmane.org>
Message-ID: <4AAEBE2B.6020606@gmail.com>

Georg Brandl wrote:
> Nick Coghlan schrieb:
>> Stephen J. Turnbull wrote:
>>> Discussion of how to spell SIGKILL looks like bikeshed painting to me,
>>> but the question of how to extend graceful interrupt behavior to C
>>> modules looks worthy of an idea to me.
>>>
>>> Is that too hard or too rare a need?
>> If someone can come up with an adequate C API spelling of the change
>> (e.g. a PYTHON_BEGIN_ALLOW_SIGINT_ABORT/PYTHON_END_ALLOW_SIGINT_ABORT)
>> and define it in such a way that the burden for cleaning up before
>> resumption of execution of Python code is placed on the developer using
>> the new API then I'd be +1.
> 
> Do you think people would use it?  It's already hard to convince them of
> using the thread state macros correctly, and the benefit of doing that
> is subjectively much larger (multithreading works without blocking) than
> for the SIGINT handling.

I think some of the major well-maintained extensions might be persuaded
to use it (think numpy) and we'd be able to use it ourselves
(time.sleep(), I'm looking at you).

time.sleep() is actually a great example. Firstly, I didn't use it just
yesterday precisely because dropping it in in a naive fashion would have
broken Ctrl-C handling and I didn't feel like taking the time to use it
in a less naive way. Secondly, it's a stateless call - if the sleep call
is aborted due to a Ctrl-C, then the only thing to do before going back
into Python code is reacquire the GIL.

That said, my signal-handling-fu isn't even close to being able to
handle writing the macros to make that happen.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From greg.ewing at canterbury.ac.nz  Tue Sep 15 02:13:46 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 15 Sep 2009 12:13:46 +1200
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAEBE2B.6020606@gmail.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<20090913193847.1efca525@bhuda.mired.org> <4AAE43D1.1030707@gmail.com>
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp> <4AAEACD4.2080605@gmail.com>
	<h8mc84$aim$1@ger.gmane.org> <4AAEBE2B.6020606@gmail.com>
Message-ID: <4AAEDC3A.40207@canterbury.ac.nz>

Nick Coghlan wrote:

> time.sleep() is actually a great example. Firstly, I didn't use it just
> yesterday precisely because dropping it in in a naive fashion would have
> broken Ctrl-C handling

What do you mean? Ctrl-C interrupts time.sleep()
okay in my Python (on MacOSX).

-- 
Greg



From rylesny at gmail.com  Tue Sep 15 06:04:20 2009
From: rylesny at gmail.com (ryles)
Date: Mon, 14 Sep 2009 21:04:20 -0700 (PDT)
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAEDC3A.40207@canterbury.ac.nz>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org> 
	<20090913193847.1efca525@bhuda.mired.org> <4AAE43D1.1030707@gmail.com> 
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp> <4AAEACD4.2080605@gmail.com>
	<h8mc84$aim$1@ger.gmane.org> <4AAEBE2B.6020606@gmail.com> 
	<4AAEDC3A.40207@canterbury.ac.nz>
Message-ID: <4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>



On Sep 14, 8:13?pm, Greg Ewing <greg.ew... at canterbury.ac.nz> wrote:
> Nick Coghlan wrote:
> > time.sleep() is actually a great example. Firstly, I didn't use it just
> > yesterday precisely because dropping it in in a naive fashion would have
> > broken Ctrl-C handling
>
> What do you mean? Ctrl-C interrupts time.sleep()
> okay in my Python (on MacOSX).
>

It's OS-dependent, apparently. Ctrl-C interrupts for me too on Linux
or in Cygwin, but it doesn't work on Windows XP. I sometimes replace
sleep() with my own implementation that does small time.sleep()'s in a
loop so that it can be interrupted.


From dickinsm at gmail.com  Tue Sep 15 11:38:13 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 15 Sep 2009 10:38:13 +0100
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>
	<4A9BC96B.2010207@gmail.com>
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>
	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>
	<9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
Message-ID: <5c6f2a5d0909150238q374f125ai3192d2de81c3c7e9@mail.gmail.com>

On Mon, Sep 14, 2009 at 3:51 AM, Yuvgoog Greenle <ubershmekel at gmail.com> wrote:
> Btw, when you say translation table, do you mean just a string? Because a
> translation table would need to be continuous from 0 to the base so a real
> dicitionary-esque table may be overkill. The only advantage of a table might
> be to convert certain digits into multiple bytes (some sort of ad-hoc
> unicode use case?).

Yes, sorry, I just meant a string (or possibly some other iterable of
characters).
Something like (3.x code):

def encode_int(n, alphabet):
    if n < 0:
        raise ValueError("nonnegative integers only, please")
    base = len(alphabet)
    cs = []
    while True:
        n, c = divmod(n, base)
        cs.append(alphabet[c])
        if not n:
            break
    return ''.join(reversed(cs))

def decode_int(s, alphabet):
    base = len(alphabet)
    char_to_int = {c: i for i, c in enumerate(alphabet)}
    n = 0
    for c in s:
        n = n * base + char_to_int[c]
    return n

>>> alphabet = '1ilI|:'
>>> encode_int(10**10, alphabet)
'|IIli|l|ili||'
>>> decode_int(_, alphabet)
10000000000

This doesn't allow negative numbers.  If negative numbers should be
permitted, there are some decisions to be made there too.  How are
they represented?  With a leading '-'?  If so, then '-' should not be
permitted in the alphabet.  Should the negative sign character be
user-configurable?

One problem with allowing multi-character digits in encoding is that it
complicates the decoding:  parsing the digit string is no longer trivial.
I don't see how to make this a viable option.

I'm still only +0 (now leaning towards -0, having seen how easy this
is to implement, and thinking about how much possible variation
there might be in what's actually needed) on adding something like this.

Mark


From ncoghlan at gmail.com  Tue Sep 15 11:44:04 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Sep 2009 19:44:04 +1000
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>
	<20090913193847.1efca525@bhuda.mired.org>
	<4AAE43D1.1030707@gmail.com>
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4AAEACD4.2080605@gmail.com>	<h8mc84$aim$1@ger.gmane.org>
	<4AAEBE2B.6020606@gmail.com> <4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
Message-ID: <4AAF61E4.9080605@gmail.com>

[Greg]
>> What do you mean? Ctrl-C interrupts time.sleep()
>> okay in my Python (on MacOSX).

[ryles]
> it doesn't work on Windows XP.

It is, indeed, Windows. (I didn't realise the *nix based OS's didn't
have this problem - an artifact of mostly using Python on Windows,
despite the fact that I do my development *of* Python on Linux).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From g.brandl at gmx.net  Tue Sep 15 14:55:03 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 15 Sep 2009 14:55:03 +0200
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAF61E4.9080605@gmail.com>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<20090913193847.1efca525@bhuda.mired.org>	<4AAE43D1.1030707@gmail.com>	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>	<4AAEACD4.2080605@gmail.com>	<h8mc84$aim$1@ger.gmane.org>	<4AAEBE2B.6020606@gmail.com>
	<4AAEDC3A.40207@canterbury.ac.nz>	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com>
Message-ID: <h8o2v3$r9i$1@ger.gmane.org>

Nick Coghlan schrieb:
> [Greg]
>>> What do you mean? Ctrl-C interrupts time.sleep()
>>> okay in my Python (on MacOSX).
> 
> [ryles]
>> it doesn't work on Windows XP.
> 
> It is, indeed, Windows. (I didn't realise the *nix based OS's didn't
> have this problem - an artifact of mostly using Python on Windows,
> despite the fact that I do my development *of* Python on Linux).

But looking at timemodule.c, there's lots of code that says it's there
for "Ctrl+C" events/interruptions on Windows. Did that work at any time?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From phd at phd.pp.ru  Tue Sep 15 15:05:47 2009
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Tue, 15 Sep 2009 17:05:47 +0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <h8o2v3$r9i$1@ger.gmane.org>
References: <20090913193847.1efca525@bhuda.mired.org>
	<4AAE43D1.1030707@gmail.com>
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4AAEACD4.2080605@gmail.com> <h8mc84$aim$1@ger.gmane.org>
	<4AAEBE2B.6020606@gmail.com> <4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org>
Message-ID: <20090915130547.GB20518@phd.pp.ru>

On Tue, Sep 15, 2009 at 02:55:03PM +0200, Georg Brandl wrote:
> Nick Coghlan schrieb:
> > [Greg]
> >>> What do you mean? Ctrl-C interrupts time.sleep()
> >>> okay in my Python (on MacOSX).
> > 
> > [ryles]
> >> it doesn't work on Windows XP.
> > 
> > It is, indeed, Windows. (I didn't realise the *nix based OS's didn't
> > have this problem - an artifact of mostly using Python on Windows,
> > despite the fact that I do my development *of* Python on Linux).
> 
> But looking at timemodule.c, there's lots of code that says it's there
> for "Ctrl+C" events/interruptions on Windows. Did that work at any time?

   Works for me:

C:\Python25>python.exe
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import sleep
>>> try: sleep(10)
... except KeyboardInterrupt: print 'QuQu'
... [Hit Ctrl+C]
QuQu
>>>

   WinXP SP2.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.


From ncoghlan at gmail.com  Tue Sep 15 15:34:46 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Sep 2009 23:34:46 +1000
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <h8o2v3$r9i$1@ger.gmane.org>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>	<20090913193847.1efca525@bhuda.mired.org>	<4AAE43D1.1030707@gmail.com>	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>	<4AAEACD4.2080605@gmail.com>	<h8mc84$aim$1@ger.gmane.org>	<4AAEBE2B.6020606@gmail.com>	<4AAEDC3A.40207@canterbury.ac.nz>	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>	<4AAF61E4.9080605@gmail.com>
	<h8o2v3$r9i$1@ger.gmane.org>
Message-ID: <4AAF97F6.1040209@gmail.com>

Georg Brandl wrote:
> Nick Coghlan schrieb:
>> [Greg]
>>>> What do you mean? Ctrl-C interrupts time.sleep()
>>>> okay in my Python (on MacOSX).
>> [ryles]
>>> it doesn't work on Windows XP.
>> It is, indeed, Windows. (I didn't realise the *nix based OS's didn't
>> have this problem - an artifact of mostly using Python on Windows,
>> despite the fact that I do my development *of* Python on Linux).
> 
> But looking at timemodule.c, there's lots of code that says it's there
> for "Ctrl+C" events/interruptions on Windows. Did that work at any time?

Actually, it looks like it works with a modern version of Python (I just
checked with the 2.6 install on my home Windows machine).

My work environment is stuck on 2.4, which is comparatively ancient
these days - it would appear someone fixed this particular gripe while I
wasn't looking :)

I guess that means we can scratch that as an example use case then...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From rylesny at gmail.com  Tue Sep 15 18:16:27 2009
From: rylesny at gmail.com (ryles)
Date: Tue, 15 Sep 2009 09:16:27 -0700 (PDT)
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <4AAF97F6.1040209@gmail.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org> 
	<20090913193847.1efca525@bhuda.mired.org> <4AAE43D1.1030707@gmail.com> 
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp> <4AAEACD4.2080605@gmail.com>
	<h8mc84$aim$1@ger.gmane.org> <4AAEBE2B.6020606@gmail.com> 
	<4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org> 
	<4AAF97F6.1040209@gmail.com>
Message-ID: <5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>

On Sep 15, 9:34?am, Nick Coghlan <ncogh... at gmail.com> wrote:
> Actually, it looks like it works with a modern version of Python (I just
> checked with the 2.6 install on my home Windows machine).
>

I'm using 2.6.2 on XP SP3 and time.sleep() is not interrupted with
Control-C.

FYI, threading.Event().wait(n) actually looks to be interruptible on
both *nix and Windows.


From python at mrabarnett.plus.com  Tue Sep 15 18:48:11 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 15 Sep 2009 17:48:11 +0100
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
 conversion
In-Reply-To: <5c6f2a5d0909150238q374f125ai3192d2de81c3c7e9@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>	
	<4A9BC96B.2010207@gmail.com>	
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>	
	<4A9BF08C.9060607@mrabarnett.plus.com>	
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>	
	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>	
	<9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
	<5c6f2a5d0909150238q374f125ai3192d2de81c3c7e9@mail.gmail.com>
Message-ID: <4AAFC54B.1090406@mrabarnett.plus.com>

Mark Dickinson wrote:
> On Mon, Sep 14, 2009 at 3:51 AM, Yuvgoog Greenle <ubershmekel at gmail.com> wrote:
>> Btw, when you say translation table, do you mean just a string? Because a
>> translation table would need to be continuous from 0 to the base so a real
>> dicitionary-esque table may be overkill. The only advantage of a table might
>> be to convert certain digits into multiple bytes (some sort of ad-hoc
>> unicode use case?).
> 
> Yes, sorry, I just meant a string (or possibly some other iterable of
> characters).
> Something like (3.x code):
> 
> def encode_int(n, alphabet):
>     if n < 0:
>         raise ValueError("nonnegative integers only, please")
>     base = len(alphabet)
>     cs = []
>     while True:
>         n, c = divmod(n, base)
>         cs.append(alphabet[c])
>         if not n:
>             break
>     return ''.join(reversed(cs))
> 
> def decode_int(s, alphabet):
>     base = len(alphabet)
>     char_to_int = {c: i for i, c in enumerate(alphabet)}
>     n = 0
>     for c in s:
>         n = n * base + char_to_int[c]
>     return n
> 
>>>> alphabet = '1ilI|:'
>>>> encode_int(10**10, alphabet)
> '|IIli|l|ili||'
>>>> decode_int(_, alphabet)
> 10000000000
> 
> This doesn't allow negative numbers.  If negative numbers should be
> permitted, there are some decisions to be made there too.  How are
> they represented?  With a leading '-'?  If so, then '-' should not be
> permitted in the alphabet.  Should the negative sign character be
> user-configurable?
> 
> One problem with allowing multi-character digits in encoding is that it
> complicates the decoding:  parsing the digit string is no longer trivial.
> I don't see how to make this a viable option.
> 
> I'm still only +0 (now leaning towards -0, having seen how easy this
> is to implement, and thinking about how much possible variation
> there might be in what's actually needed) on adding something like this.
> 
I'd prefer the arguments to be: value, base, optional translation table.
The translation table would default to 0-9, A-Z/a-z (when decoding,
multiple characters could map to the same numeric value, eg 'A' => 10
and 'a' => 10, hence the ability to use a dict). The default translation
table would work up to base 36; higher bases would raise a ValueError
exception "translation table too small for base".

Could a single translation table work both ways? A dict for decoding
could contain {'A': 10, 'a': 10}, but how could you reverse that for
encoding?


From qrczak at knm.org.pl  Tue Sep 15 19:58:20 2009
From: qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Tue, 15 Sep 2009 19:58:20 +0200
Subject: [Python-ideas] set.add(x) slower than if x in set:set.add(x)
In-Reply-To: <4AAE431B.2020404@gmail.com>
References: <5d1a32000909131110k636f0d6v2413fb190e5a3c38@mail.gmail.com> 
	<440A5B08-A86C-4F86-A03E-57C55D7B241C@rcn.com>
	<9d153b7c0909131956u42e1e77aufdb6fa9e16b020c5@mail.gmail.com> 
	<4AAE431B.2020404@gmail.com>
Message-ID: <3f4107910909151058s9674c77t7f5425ab3ffbf926@mail.gmail.com>

2009/9/14 Nick Coghlan <ncoghlan at gmail.com>:

> The interpreter has no way of knowing a priori that the branch won't be
> taken 999,999 times out of 1,000,000.

And it does not know a priori that s.add(x) will involve checking
whether the set s contains x. It does not even try to infer that s
must be a set at this point.

-- 
Marcin Kowalczyk
qrczak at knm.org.pl
http://qrnik.knm.org.pl/~qrczak/


From p.f.moore at gmail.com  Tue Sep 15 20:56:15 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 15 Sep 2009 19:56:15 +0100
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
References: <1252877123.19979.43.camel@giskard> <4AAEACD4.2080605@gmail.com>
	<h8mc84$aim$1@ger.gmane.org> <4AAEBE2B.6020606@gmail.com>
	<4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org>
	<4AAF97F6.1040209@gmail.com>
	<5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
Message-ID: <79990c6b0909151156x46c31cdco6bc44e5a37f99d56@mail.gmail.com>

2009/9/15 ryles <rylesny at gmail.com>:
> On Sep 15, 9:34?am, Nick Coghlan <ncogh... at gmail.com> wrote:
>> Actually, it looks like it works with a modern version of Python (I just
>> checked with the 2.6 install on my home Windows machine).
>>
>
> I'm using 2.6.2 on XP SP3 and time.sleep() is not interrupted with
> Control-C.

Works for me using 2.6.2 on Windows 7. Do you use IPython (and/or
pyreadline)? That does ugly things with keyboard handling...

Paul.


From mwm-keyword-python.b4bdba at mired.org  Tue Sep 15 21:45:30 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Tue, 15 Sep 2009 15:45:30 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<20090913193847.1efca525@bhuda.mired.org>
	<4AAE43D1.1030707@gmail.com>
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4AAEACD4.2080605@gmail.com> <h8mc84$aim$1@ger.gmane.org>
	<4AAEBE2B.6020606@gmail.com> <4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org>
	<4AAF97F6.1040209@gmail.com>
	<5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
Message-ID: <20090915154530.3dcd2045@bhuda.mired.org>

On Tue, 15 Sep 2009 09:16:27 -0700 (PDT)
ryles <rylesny at gmail.com> wrote:

> On Sep 15, 9:34?am, Nick Coghlan <ncogh... at gmail.com> wrote:
> > Actually, it looks like it works with a modern version of Python (I just
> > checked with the 2.6 install on my home Windows machine).
> >
> 
> I'm using 2.6.2 on XP SP3 and time.sleep() is not interrupted with
> Control-C.
> 
> FYI, threading.Event().wait(n) actually looks to be interruptible on
> both *nix and Windows.

Is there an example in the standard library that doesn't handle
interrupts properly on both systems? How about a libc function that
fails when invoked via ctypes?

If not, then it might be reasonable to conclude that the problem is
buggy extensions, and go back to figuring out how to make it easier to
write extensions that handle this properly.

   <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From tjreedy at udel.edu  Tue Sep 15 22:47:00 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 15 Sep 2009 16:47:00 -0400
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
References: <1252877123.19979.43.camel@giskard>	<loom.20090913T233307-707@post.gmane.org>
	<20090913193847.1efca525@bhuda.mired.org>
	<4AAE43D1.1030707@gmail.com>
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4AAEACD4.2080605@gmail.com>	<h8mc84$aim$1@ger.gmane.org>
	<4AAEBE2B.6020606@gmail.com>
	<4AAEDC3A.40207@canterbury.ac.nz>	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>	<4AAF61E4.9080605@gmail.com>
	<h8o2v3$r9i$1@ger.gmane.org> <4AAF97F6.1040209@gmail.com>
	<5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
Message-ID: <h8oug4$uq8$1@ger.gmane.org>

ryles wrote:
> On Sep 15, 9:34 am, Nick Coghlan <ncogh... at gmail.com> wrote:
>> Actually, it looks like it works with a modern version of Python (I just
>> checked with the 2.6 install on my home Windows machine).
>>
> 
> I'm using 2.6.2 on XP SP3 and time.sleep() is not interrupted with
> Control-C.

Win32XP, Py3.1

Keyboard Interrupt is immediately caught in console.
In IDLE, only caught when sleep ends.

 >>> while 1:pass

Traceback (most recent call last):
   File "<pyshell#12>", line 1, in <module>
     while 1:pass
KeyboardInterrupt

caught immediately even with idle.



From rylesny at gmail.com  Wed Sep 16 01:31:05 2009
From: rylesny at gmail.com (ryles)
Date: Tue, 15 Sep 2009 16:31:05 -0700 (PDT)
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <20090915154530.3dcd2045@bhuda.mired.org>
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org> 
	<20090913193847.1efca525@bhuda.mired.org> <4AAE43D1.1030707@gmail.com> 
	<8763blvajy.fsf@uwakimon.sk.tsukuba.ac.jp> <4AAEACD4.2080605@gmail.com>
	<h8mc84$aim$1@ger.gmane.org> <4AAEBE2B.6020606@gmail.com> 
	<4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org> 
	<4AAF97F6.1040209@gmail.com>
	<5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
	<20090915154530.3dcd2045@bhuda.mired.org>
Message-ID: <bb2b5095-cee7-4db3-a0ef-181f83a24d95@y20g2000vbk.googlegroups.com>

On Sep 15, 3:45?pm, Mike Meyer <mwm-keyword-python.b4b... at mired.org>
wrote:
> Is there an example in the standard library that doesn't handle
> interrupts properly on both systems?

The one that often annoys people in the standard library is
threading.Thread.join():

http://bugs.python.org/issue1167930


From ubershmekel at gmail.com  Wed Sep 16 04:39:55 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Wed, 16 Sep 2009 05:39:55 +0300
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <4AAFC54B.1090406@mrabarnett.plus.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>
	<4A9BC96B.2010207@gmail.com>
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>
	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>
	<9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
	<5c6f2a5d0909150238q374f125ai3192d2de81c3c7e9@mail.gmail.com>
	<4AAFC54B.1090406@mrabarnett.plus.com>
Message-ID: <9d153b7c0909151939j3500417dh30cb715044d68aaa@mail.gmail.com>

also, negative numbers aren't taboo. FTFY
import string

def mirror_dict(dict):
    # list because iteration doesn't support changing of the dict
    for key, val in list(dict.items()):
        dict[val] = key

_lows = string.digits + string.ascii_lowercase
default_alphabet = dict(zip(range(len(_lows)), _lows))
mirror_dict(default_alphabet)

def encode_int(value, base, alphabet=default_alphabet):
    if value < 0:
        is_negative = True
        value = value*(-1)
    else:
        is_negative = False

    cs = []
    while True:
        value, index = divmod(value, base)
        cs.insert(0, alphabet[index])
        if not value:
            break

    if is_negative:
        cs.insert(0, '-')

    return ''.join(cs)

def decode_int(str_num, base, alphabet=default_alphabet):
    char_to_int = {c: i for i, c in enumerate(alphabet)}
    value = 0
    for c in str_num:
        value = value * base + char_to_int[c]
    return value

alphabet = '1ilI|:'
enc = encode_int(10**10, len(alphabet), alphabet)
print('|IIli|l|ili||')
print(enc)

dec = decode_int(enc, len(alphabet), alphabet)
print(dec)
print(10000000000)

print(encode_int(12345, 32))
print(encode_int(-12345, 32))

-----
The only problem with {'A': 10, 'a': 10} is that it's not reversible. If we
wantted to encode, 10, what should be used, A or a?


On Tue, Sep 15, 2009 at 7:48 PM, MRAB <python at mrabarnett.plus.com> wrote:

> Mark Dickinson wrote:
>
>> On Mon, Sep 14, 2009 at 3:51 AM, Yuvgoog Greenle <ubershmekel at gmail.com>
>> wrote:
>>
>>> Btw, when you say translation table, do you mean just a string? Because a
>>> translation table would need to be continuous from 0 to the base so a
>>> real
>>> dicitionary-esque table may be overkill. The only advantage of a table
>>> might
>>> be to convert certain digits into multiple bytes (some sort of ad-hoc
>>> unicode use case?).
>>>
>>
>> Yes, sorry, I just meant a string (or possibly some other iterable of
>> characters).
>> Something like (3.x code):
>>
>> def encode_int(n, alphabet):
>>    if n < 0:
>>        raise ValueError("nonnegative integers only, please")
>>    base = len(alphabet)
>>    cs = []
>>    while True:
>>        n, c = divmod(n, base)
>>        cs.append(alphabet[c])
>>        if not n:
>>            break
>>    return ''.join(reversed(cs))
>>
>> def decode_int(s, alphabet):
>>    base = len(alphabet)
>>    char_to_int = {c: i for i, c in enumerate(alphabet)}
>>    n = 0
>>    for c in s:
>>        n = n * base + char_to_int[c]
>>    return n
>>
>>  alphabet = '1ilI|:'
>>>>> encode_int(10**10, alphabet)
>>>>>
>>>> '|IIli|l|ili||'
>>
>>> decode_int(_, alphabet)
>>>>>
>>>> 10000000000
>>
>> This doesn't allow negative numbers.  If negative numbers should be
>> permitted, there are some decisions to be made there too.  How are
>> they represented?  With a leading '-'?  If so, then '-' should not be
>> permitted in the alphabet.  Should the negative sign character be
>> user-configurable?
>>
>> One problem with allowing multi-character digits in encoding is that it
>> complicates the decoding:  parsing the digit string is no longer trivial.
>> I don't see how to make this a viable option.
>>
>> I'm still only +0 (now leaning towards -0, having seen how easy this
>> is to implement, and thinking about how much possible variation
>> there might be in what's actually needed) on adding something like this.
>>
>>  I'd prefer the arguments to be: value, base, optional translation table.
> The translation table would default to 0-9, A-Z/a-z (when decoding,
> multiple characters could map to the same numeric value, eg 'A' => 10
> and 'a' => 10, hence the ability to use a dict). The default translation
> table would work up to base 36; higher bases would raise a ValueError
> exception "translation table too small for base".
>
> Could a single translation table work both ways? A dict for decoding
> could contain {'A': 10, 'a': 10}, but how could you reverse that for
> encoding?
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090916/bc06f497/attachment.html>

From greg at krypto.org  Wed Sep 16 08:11:34 2009
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 15 Sep 2009 23:11:34 -0700
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <bb2b5095-cee7-4db3-a0ef-181f83a24d95@y20g2000vbk.googlegroups.com>
References: <1252877123.19979.43.camel@giskard> <4AAEBE2B.6020606@gmail.com> 
	<4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org> 
	<4AAF97F6.1040209@gmail.com>
	<5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
	<20090915154530.3dcd2045@bhuda.mired.org>
	<bb2b5095-cee7-4db3-a0ef-181f83a24d95@y20g2000vbk.googlegroups.com>
Message-ID: <52dc1c820909152311k2450d5fcu8ea3345f8ee40cf5@mail.gmail.com>

On Tue, Sep 15, 2009 at 4:31 PM, ryles <rylesny at gmail.com> wrote:
> On Sep 15, 3:45?pm, Mike Meyer <mwm-keyword-python.b4b... at mired.org>
> wrote:
>> Is there an example in the standard library that doesn't handle
>> interrupts properly on both systems?
>
> The one that often annoys people in the standard library is
> threading.Thread.join():
>
> http://bugs.python.org/issue1167930

Another work around is to do absolutely nothing in your main program
thread other than sit in:

while not_time_to_exit:
        time.sleep(9999999)

The main thread handles all signals.  Move the rest of your work
(including joining, etc) to other threads.  Have one of them set
not_time_to_exit and send a signal to yourself to cause the sleep to
exit.  (or instead of sleep, open a pipe and poke the pipe by writing
some data to it to indicate its time to exit vs loop again, etc.)


From arnodel at googlemail.com  Wed Sep 16 09:34:46 2009
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Wed, 16 Sep 2009 08:34:46 +0100
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <9d153b7c0909151939j3500417dh30cb715044d68aaa@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>
	<4A9BC96B.2010207@gmail.com>
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>
	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>
	<9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
	<5c6f2a5d0909150238q374f125ai3192d2de81c3c7e9@mail.gmail.com>
	<4AAFC54B.1090406@mrabarnett.plus.com>
	<9d153b7c0909151939j3500417dh30cb715044d68aaa@mail.gmail.com>
Message-ID: <9bfc700a0909160034n54efbba3u99faa8745d04c8fe@mail.gmail.com>

2009/9/16 Yuvgoog Greenle <ubershmekel at gmail.com>:
[...]
> The only problem with?{'A': 10, 'a': 10} is that it's not reversible. If we
> wantted to encode, 10, what should be used, A or a?

Obviously, either  :)

-- 
Arnaud


From rylesny at gmail.com  Wed Sep 16 17:53:34 2009
From: rylesny at gmail.com (ryles)
Date: Wed, 16 Sep 2009 08:53:34 -0700 (PDT)
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <79990c6b0909151156x46c31cdco6bc44e5a37f99d56@mail.gmail.com>
References: <1252877123.19979.43.camel@giskard> <4AAEACD4.2080605@gmail.com> 
	<h8mc84$aim$1@ger.gmane.org> <4AAEBE2B.6020606@gmail.com> 
	<4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org> 
	<4AAF97F6.1040209@gmail.com>
	<5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
	<79990c6b0909151156x46c31cdco6bc44e5a37f99d56@mail.gmail.com>
Message-ID: <e264b7f4-5364-40c5-9261-5809dad5d90b@o13g2000vbl.googlegroups.com>



On Sep 15, 2:56?pm, Paul Moore <p.f.mo... at gmail.com> wrote:
> 2009/9/15 ryles <ryle... at gmail.com>:
> > I'm using 2.6.2 on XP SP3 and time.sleep() is not interrupted with
> > Control-C.
>
> Works for me using 2.6.2 on Windows 7. Do you use IPython (and/or
> pyreadline)? That does ugly things with keyboard handling...
>

Hey Paul,

Terry was right. It's something that happens only in IDLE. I was
surprised to find that it works on the command-line, as others have
reported.


From rylesny at gmail.com  Wed Sep 16 18:01:47 2009
From: rylesny at gmail.com (ryles)
Date: Wed, 16 Sep 2009 09:01:47 -0700 (PDT)
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
In-Reply-To: <52dc1c820909152311k2450d5fcu8ea3345f8ee40cf5@mail.gmail.com>
References: <1252877123.19979.43.camel@giskard> <4AAEBE2B.6020606@gmail.com> 
	<4AAEDC3A.40207@canterbury.ac.nz>
	<4c4cbffa-3dfb-43b4-9ce8-9941cfc8d7e7@o21g2000vbl.googlegroups.com>
	<4AAF61E4.9080605@gmail.com> <h8o2v3$r9i$1@ger.gmane.org> 
	<4AAF97F6.1040209@gmail.com>
	<5c0b8363-45de-4809-aa19-50500269008b@31g2000vbf.googlegroups.com>
	<20090915154530.3dcd2045@bhuda.mired.org>
	<bb2b5095-cee7-4db3-a0ef-181f83a24d95@y20g2000vbk.googlegroups.com>
	<52dc1c820909152311k2450d5fcu8ea3345f8ee40cf5@mail.gmail.com>
Message-ID: <a23c3452-ab0c-4d7f-b598-e803bbb0ea28@j9g2000vbp.googlegroups.com>

On Sep 16, 2:11?am, "Gregory P. Smith" <g... at krypto.org> wrote:
> On Tue, Sep 15, 2009 at 4:31 PM, ryles <ryle... at gmail.com> wrote:
> > On Sep 15, 3:45?pm, Mike Meyer <mwm-keyword-python.b4b... at mired.org>
> > wrote:
> >> Is there an example in the standard library that doesn't handle
> >> interrupts properly on both systems?
>
> > The one that often annoys people in the standard library is
> > threading.Thread.join():
>
> >http://bugs.python.org/issue1167930
>
> Another work around is to do absolutely nothing in your main program
> thread other than sit in:
>
> while not_time_to_exit:
> ? ? ? ? time.sleep(9999999)
>
> The main thread handles all signals. ?Move the rest of your work
> (including joining, etc) to other threads. ?Have one of them set
> not_time_to_exit and send a signal to yourself to cause the sleep to
> exit. ?(or instead of sleep, open a pipe and poke the pipe by writing
> some data to it to indicate its time to exit vs loop again, etc.)

I usually tend towards something simple like:

while thread.is_alive():
    time.sleep(1)

Often this represented as a wait() method of thread objects themselves.


From ubershmekel at gmail.com  Thu Sep 17 03:12:59 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Thu, 17 Sep 2009 04:12:59 +0300
Subject: [Python-ideas] Add a builtin method to 'int' for base/radix
	conversion
In-Reply-To: <9bfc700a0909160034n54efbba3u99faa8745d04c8fe@mail.gmail.com>
References: <9d153b7c0908301745n51a9751avbaf16d0e155fec7e@mail.gmail.com>
	<1AD8D421-A250-421D-A6ED-4992234A5B96@masklinn.net>
	<4A9BF08C.9060607@mrabarnett.plus.com>
	<9d153b7c0909110816k93a3b91n161cb58572bf1151@mail.gmail.com>
	<5c6f2a5d0909131106x4e6f49aep56b47eb5675ab894@mail.gmail.com>
	<9d153b7c0909131951m585f3dcev953de169ffbf3b95@mail.gmail.com>
	<5c6f2a5d0909150238q374f125ai3192d2de81c3c7e9@mail.gmail.com>
	<4AAFC54B.1090406@mrabarnett.plus.com>
	<9d153b7c0909151939j3500417dh30cb715044d68aaa@mail.gmail.com>
	<9bfc700a0909160034n54efbba3u99faa8745d04c8fe@mail.gmail.com>
Message-ID: <9d153b7c0909161812y16980381xd3b0727555fb8b6d@mail.gmail.com>

Excuse my 'obviously', let me clarify.
The following alphabet is reversable:
for encode: {0 : 'a', 1, 'b'}
for encode/decode: {0: 'a', 1: 'b', 'a':0, 'b':1}

You can have 'a' and 'A' coexist, but the encode will have only one option.
for encode: :{0 : 'a', 1, 'b'}
for encode/decode: {0: 'a', 1: 'b', 'a': 0, 'b': 1, 'A': 0, 'B': 1}

So one could say the encoding alphabet is the canonical representation. The
encoding alphabet is actually alphabet_dict[0],..., alphabet_dict[base - 1].

On Wed, Sep 16, 2009 at 10:34 AM, Arnaud Delobelle
<arnodel at googlemail.com>wrote:

> 2009/9/16 Yuvgoog Greenle <ubershmekel at gmail.com>:
> [...]
> > The only problem with {'A': 10, 'a': 10} is that it's not reversible. If
> we
> > wantted to encode, 10, what should be used, A or a?
>
> Obviously, either  :)
>
> --
> Arnaud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090917/dab26385/attachment.html>

From rasky at develer.com  Thu Sep 17 10:15:41 2009
From: rasky at develer.com (Giovanni Bajo)
Date: Thu, 17 Sep 2009 08:15:41 +0000 (UTC)
Subject: [Python-ideas] IDEA: do not alter default SIGINT handling
References: <1252877123.19979.43.camel@giskard>
	<loom.20090913T233307-707@post.gmane.org>
	<4AAD85F2.9080609@mrabarnett.plus.com>
	<20090913200509.439ca1b6@bhuda.mired.org>
	<4AAD8A37.8080504@mrabarnett.plus.com>
	<87r5uauxod.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <h8sr7d$lkv$1@ger.gmane.org>

On Mon, 14 Sep 2009 10:23:14 +0900, Stephen J. Turnbull wrote:

> MRAB writes:
> 
>  > How about 2 (or 3?) in rapid succession ("here's a CTRL-C, and here's
>  > another one to show I mean it!" :-)).
> 
> That's more complexity than you want to put in a signal handler.  The
> way Emacs handles this is that the signal handler just enqueues a quit
> event, and the event loop checks for it and handles it.  In other places
> (such as looping functions) more complex QUIT processing (that checks
> for repeated signals and throws to the innermost QUIT catcher) is done,
> but this can only be done in "safe" places, not in the signal handler
> itself.  I imagine Python works the same way and it works fine in pure
> Python programs, too.

A cursory check over the signal handler shows the Python calls 
PyErr_SetNone(PyExc_KeyboardInterrupt) within the signal handler itself.

Handling a double-Ctrl-C would be very trivial, would solve the OP 
problem, and would not declare all existing C/C++ code in the world as 
"non-compatible-with-Python-ctrl-c-by-default", which is the current 
shame we live in.
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com



From janssen at parc.com  Fri Sep 18 02:24:56 2009
From: janssen at parc.com (Bill Janssen)
Date: Thu, 17 Sep 2009 17:24:56 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes" to
	hashlib?
Message-ID: <7922.1253233496@parc.com>

A couple of weeks ago, there was a discussion on python-dev about adding
the ability to load modules from encrypted zip files.  I'm not sure the
discussion went anywhere, and I was on vacation when it took place.

However, it reminded me of an idea from a couple of years ago: extend
the hashlib module to produce two additional kinds of hashes: a digital
signature for some sequence of bytes, and an encrypted/decrypted version
of a sequence of bytes.  Basically, the would bring more of the OpenSSL
EVP API out to Python (hashlib already uses OpenSSL EVP for various hash
formations).

http://www.openssl.org/docs/crypto/evp.html

With this, it would be fairly trivial to implement strong encryption of
zip files (or anything else), and this could then be used to do the
import feature.

I'd envision adding new constructors to hashlib:

   sig = hashlib.signature([data] [, keyfile=...] [, signature_algorithm=...])

This would have the regular update() method, and digest() and
hexdigest(), but would also support the method

   sig.verify(existing_sig)

which would return a boolean saying the "existing sig" is a verified
signature for that data.

Similarly, encryption/decryption would be

   enc = hashlib.encryptor([plaintext] [, keyfile=...] [, ciphers=...])

enc.digest() would give the ciphertext.

And

   dec = hashlib.decryptor([ciphertext] [, keyfile=...] [, ciphers=...])

and dec.digest would yield the plaintext.

The encryptor and decryptor constructors could take either "key" or
"keyfile" parameters.  Using "key" would support symmetric encrytion,
while using "keyfile" would produce EVP envelope encryption/decryption.

Bill


From g.brandl at gmx.net  Fri Sep 18 16:07:35 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 18 Sep 2009 16:07:35 +0200
Subject: [Python-ideas] Wild idea: Exception.format
Message-ID: <h904b7$4qh$1@ger.gmane.org>

To make Exceptions where some object(s) are involved more useful, it is
often necessary to put the objects on the exception *in addition to*
formatting them into a string representation for the message.

This little classmethod would make that easier::

  class BaseException:
    @classmethod
    def format(cls, fmt, *args):
      return cls(fmt.format(*args), *args)

Example usage::

  ext = 'foo'
  raise LookupError.format('Extension {0} not registered', ext)

'foo' could then be accessed as ``exc.args[1]``.


A similar, but also very useful implementation would be ::

  def format(cls, fmt, **kwds):
    exc = cls(fmt.format(**kwds))
    exc.__dict__.update(kwds)
    return exc

with example usage being::

  raise LookupError.format('Extension {ext} not registered', ext='foo')

and 'foo' being accessible as ``exc.ext``.

I realize this is probably too obscure for Python core, but I wanted to
show it to you anyway, maybe it'll be found useful.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From ilya.nikokoshev at gmail.com  Fri Sep 18 21:54:24 2009
From: ilya.nikokoshev at gmail.com (ilya)
Date: Fri, 18 Sep 2009 23:54:24 +0400
Subject: [Python-ideas] Wild idea: Exception.format
In-Reply-To: <h904b7$4qh$1@ger.gmane.org>
References: <h904b7$4qh$1@ger.gmane.org>
Message-ID: <d8cc6f9d0909181254n2852bbfap68164d4c6f97f1bc@mail.gmail.com>

How about simplifying creation of a subclass for this pattern::

class NotRegisteredError(LookupError):
    template = 'Extension {1} not registered'

...
raise NotRegisteredError(ext)


This is instead of::

class NotRegisteredError(LookupError):
    def __init__(self, *args):
        super().__init__('Extension {1} not registered'.format(self,
*args), *args)


Advantages to having a separate subclass:
(1) it can be reused
(2) it can be caught separately from LookupError
(3) you can list possible exceptions in the beginning of module
(4) you can search for functions that raise a specific exception

What do you think?

Ilya.

On Fri, Sep 18, 2009 at 6:07 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> To make Exceptions where some object(s) are involved more useful, it is
> often necessary to put the objects on the exception *in addition to*
> formatting them into a string representation for the message.
>
> This little classmethod would make that easier::
>
> ?class BaseException:
> ? ?@classmethod
> ? ?def format(cls, fmt, *args):
> ? ? ?return cls(fmt.format(*args), *args)
>
> Example usage::
>
> ?ext = 'foo'
> ?raise LookupError.format('Extension {0} not registered', ext)
>
> 'foo' could then be accessed as ``exc.args[1]``.
>
>
> A similar, but also very useful implementation would be ::
>
> ?def format(cls, fmt, **kwds):
> ? ?exc = cls(fmt.format(**kwds))
> ? ?exc.__dict__.update(kwds)
> ? ?return exc
>
> with example usage being::
>
> ?raise LookupError.format('Extension {ext} not registered', ext='foo')
>
> and 'foo' being accessible as ``exc.ext``.
>
> I realize this is probably too obscure for Python core, but I wanted to
> show it to you anyway, maybe it'll be found useful.
>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From ubershmekel at gmail.com  Sat Sep 19 02:57:37 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Sat, 19 Sep 2009 03:57:37 +0300
Subject: [Python-ideas] Wild idea: Exception.format
In-Reply-To: <d8cc6f9d0909181254n2852bbfap68164d4c6f97f1bc@mail.gmail.com>
References: <h904b7$4qh$1@ger.gmane.org>
	<d8cc6f9d0909181254n2852bbfap68164d4c6f97f1bc@mail.gmail.com>
Message-ID: <9d153b7c0909181757i15988313s6298bea383f35dd8@mail.gmail.com>

I fail to see why you can't have both args and kwargs...
class BaseException:
    @classmethod
    def format(cls, fmt, *args, **kwargs):
        return cls(fmt.format(*args, **kwargs), *args, **kwargs)

And concerning Gerog's actual question, I think this is a not uncommon
pattern, but
    raise Exception.format(...)
doesn't sound good. It's not really as readable as
    raise Exception(fmt.format(ext), ext)

ilya suggested an almost ok direction but he doesn't define formats at
runtime. So maybe instead we can make a factory for formatted exceptions.

def formatted_exception(exception):
    def format_and_return(fmt, *args, **kwargs):
        return exception(fmt.format(*args, **kwargs), *args, **kwargs)
    return format_and_return

@formatted_exception
class NotRegisteredError(LookupError): pass

then the usage becomes:
raise NotRegisteredError("Extension {0} not registered.", ext)

On Fri, Sep 18, 2009 at 10:54 PM, ilya <ilya.nikokoshev at gmail.com> wrote:

> How about simplifying creation of a subclass for this pattern::
>
> class NotRegisteredError(LookupError):
>    template = 'Extension {1} not registered'
>
> ...
> raise NotRegisteredError(ext)
>
>
> This is instead of::
>
> class NotRegisteredError(LookupError):
>    def __init__(self, *args):
>        super().__init__('Extension {1} not registered'.format(self,
> *args), *args)
>
>
> Advantages to having a separate subclass:
> (1) it can be reused
> (2) it can be caught separately from LookupError
> (3) you can list possible exceptions in the beginning of module
> (4) you can search for functions that raise a specific exception
>
> What do you think?
>
> Ilya.
>
> On Fri, Sep 18, 2009 at 6:07 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> > To make Exceptions where some object(s) are involved more useful, it is
> > often necessary to put the objects on the exception *in addition to*
> > formatting them into a string representation for the message.
> >
> > This little classmethod would make that easier::
> >
> >  class BaseException:
> >    @classmethod
> >    def format(cls, fmt, *args):
> >      return cls(fmt.format(*args), *args)
> >
> > Example usage::
> >
> >  ext = 'foo'
> >  raise LookupError.format('Extension {0} not registered', ext)
> >
> > 'foo' could then be accessed as ``exc.args[1]``.
> >
> >
> > A similar, but also very useful implementation would be ::
> >
> >  def format(cls, fmt, **kwds):
> >    exc = cls(fmt.format(**kwds))
> >    exc.__dict__.update(kwds)
> >    return exc
> >
> > with example usage being::
> >
> >  raise LookupError.format('Extension {ext} not registered', ext='foo')
> >
> > and 'foo' being accessible as ``exc.ext``.
> >
> > I realize this is probably too obscure for Python core, but I wanted to
> > show it to you anyway, maybe it'll be found useful.
> >
> > Georg
> >
> > --
> > Thus spake the Lord: Thou shalt indent with four spaces. No more, no
> less.
> > Four shall be the number of spaces thou shalt indent, and the number of
> thy
> > indenting shall be four. Eight shalt thou not indent, nor either indent
> thou
> > two, excepting that thou then proceed to four. Tabs are right out.
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > http://mail.python.org/mailman/listinfo/python-ideas
> >
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090919/efec5776/attachment.html>

From ncoghlan at gmail.com  Sat Sep 19 03:43:05 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Sep 2009 11:43:05 +1000
Subject: [Python-ideas] Wild idea: Exception.format
In-Reply-To: <9d153b7c0909181757i15988313s6298bea383f35dd8@mail.gmail.com>
References: <h904b7$4qh$1@ger.gmane.org>	<d8cc6f9d0909181254n2852bbfap68164d4c6f97f1bc@mail.gmail.com>
	<9d153b7c0909181757i15988313s6298bea383f35dd8@mail.gmail.com>
Message-ID: <4AB43729.2040109@gmail.com>

Yuvgoog Greenle wrote:
> I fail to see why you can't have both args and kwargs...
> 
> class BaseException:
>     @classmethod
>     def format(cls, fmt, *args, **kwargs):
>         return cls(fmt.format(*args, **kwargs), *args, **kwargs)
> 
> And concerning Gerog's actual question, I think this is a not uncommon
> pattern, but
>     raise Exception.format(...)
> doesn't sound good. It's not really as readable as
>     raise Exception(fmt.format(ext), ext)
> 
> ilya suggested an almost ok direction but he doesn't define formats at
> runtime. So maybe instead we can make a factory for formatted exceptions.
> 
> def formatted_exception(exception):
>     def format_and_return(fmt, *args, **kwargs):
>         return exception(fmt.format(*args, **kwargs), *args, **kwargs)
>     return format_and_return
> 
> @formatted_exception
> class NotRegisteredError(LookupError): pass
> 
> then the usage becomes:
> raise NotRegisteredError("Extension {0} not registered.", ext)

I like the class decorator idea (to avoid namespace conflicts on the
exception objects - cf. the dramas with ex.message). However, the above
would break exception handling since NotRegisteredError would refer to
the factory function instead of the exception that is actually thrown.

Combining it with Ilya's idea (by having the class decorator return a
new subclass rather than a factory function) gives something that should
work in practice:

def formatted_exception(exc):
  class FormattedExc(exc):
    def __init__(*args, **kwds):
      self, fmt, args = args[0], args[1], args[2:]
      super(FormattedExc, self).__init__(
            fmt.format(*args, **kwds), *args, **kwds)
    def __str__(self):
      return self.args[0]
    __name__ = exc.__name__
    __doc__ = exc.__doc__
    __module__ = exc.__module__
  return FormattedExc

@formatted_exception
class ExampleError(Exception): pass

>>> try:
...   raise ExampleError("Format: {}", "Value")
... except ExampleError as ex:
...   saved = ex
...
>>> saved
FormattedExc('Format: Value', 'Value')
>>> print(saved)
Format: Value
>>> saved.args[1]
'Value'
>>> saved.__name__
'ExampleError'


Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From ilya.nikokoshev at gmail.com  Sat Sep 19 09:29:30 2009
From: ilya.nikokoshev at gmail.com (ilya)
Date: Sat, 19 Sep 2009 11:29:30 +0400
Subject: [Python-ideas] Wild idea: Exception.format
In-Reply-To: <4AB43729.2040109@gmail.com>
References: <h904b7$4qh$1@ger.gmane.org>
	<d8cc6f9d0909181254n2852bbfap68164d4c6f97f1bc@mail.gmail.com>
	<9d153b7c0909181757i15988313s6298bea383f35dd8@mail.gmail.com>
	<4AB43729.2040109@gmail.com>
Message-ID: <d8cc6f9d0909190029w5991d507k27494400cdaced03@mail.gmail.com>

I think there's a way to define an exception subclass with message as
a one-liner::

# Simple syntax to define exception classes.
_ = BaseFormattedException
class RegisterError(_, LookupError): 'Extension "{0}" not registered.'
class ExtensionError(_, ValueError): 'Extension "{0}" returns wrong data.'

# Another way to define exception classes --- factory function.
MissingError = _.formatted(IndexError, 'No extension named "{0}"')
SomeOtherError = _.formatted(Exception)


>>> raise RegisterError('test')
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    raise RegisterError('test')
exceptions.RegisterError: Extension "test" not registered.

>>> raise MissingError('test')
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    raise MissingError('test')
exceptions.IndexError: No extension named "test"


(Note the difference between two methods above: RegisterError has its
separate __name__ while still being a subclass of IndexError, while
MissingError doesn't have its own __name__)

The trick is in defining the `BaseFormattedException` which harvests
(the first line of a) docstring to provide template (I figured out for
a small, locally-used exception class there may be no difference
between what it prints and its docstring).

The whole example is at http://web.mit.edu/~unknot/www/exceptions.py

How does that sound?

On Sat, Sep 19, 2009 at 5:43 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Yuvgoog Greenle wrote:
>> I fail to see why you can't have both args and kwargs...
>>
>> class BaseException:
>> ? ? @classmethod
>> ? ? def format(cls, fmt, *args, **kwargs):
>> ? ? ? ? return cls(fmt.format(*args, **kwargs), *args, **kwargs)
>>
>> And concerning Gerog's actual question, I think this is a not uncommon
>> pattern, but
>> ? ? raise Exception.format(...)
>> doesn't sound good. It's not really as readable as
>> ? ? raise Exception(fmt.format(ext), ext)
>>
>> ilya suggested an almost ok direction but he doesn't define formats at
>> runtime. So maybe instead we can make a factory for formatted exceptions.
>>
>> def formatted_exception(exception):
>> ? ? def format_and_return(fmt, *args, **kwargs):
>> ? ? ? ? return exception(fmt.format(*args, **kwargs), *args, **kwargs)
>> ? ? return format_and_return
>>
>> @formatted_exception
>> class NotRegisteredError(LookupError): pass
>>
>> then the usage becomes:
>> raise NotRegisteredError("Extension {0} not registered.", ext)
>
> I like the class decorator idea (to avoid namespace conflicts on the
> exception objects - cf. the dramas with ex.message). However, the above
> would break exception handling since NotRegisteredError would refer to
> the factory function instead of the exception that is actually thrown.
>
> Combining it with Ilya's idea (by having the class decorator return a
> new subclass rather than a factory function) gives something that should
> work in practice:
>
> def formatted_exception(exc):
> ?class FormattedExc(exc):
> ? ?def __init__(*args, **kwds):
> ? ? ?self, fmt, args = args[0], args[1], args[2:]
> ? ? ?super(FormattedExc, self).__init__(
> ? ? ? ? ? ?fmt.format(*args, **kwds), *args, **kwds)
> ? ?def __str__(self):
> ? ? ?return self.args[0]
> ? ?__name__ = exc.__name__
> ? ?__doc__ = exc.__doc__
> ? ?__module__ = exc.__module__
> ?return FormattedExc
>
> @formatted_exception
> class ExampleError(Exception): pass
>
>>>> try:
> ... ? raise ExampleError("Format: {}", "Value")
> ... except ExampleError as ex:
> ... ? saved = ex
> ...
>>>> saved
> FormattedExc('Format: Value', 'Value')
>>>> print(saved)
> Format: Value
>>>> saved.args[1]
> 'Value'
>>>> saved.__name__
> 'ExampleError'
>
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan ? | ? ncoghlan at gmail.com ? | ? Brisbane, Australia
> ---------------------------------------------------------------
>


From digitalxero at gmail.com  Sat Sep 19 10:19:25 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 02:19:25 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
Message-ID: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>

I do not expect this idea to gain much traction but it has been an
idea rolling around in my head for a year or two, so I decided to
write it all down and see what other thought.



Abstract:
    Python does not currently support static typing of variables, which is
    something I like, but there are times it would be nice to have static
    typing for variables, or method/function return values.

    Static Ducks should be able to run along side or imported to code that
    does not use Static Ducks. Actual runtime enforcement of Static Ducks
    should be off by default and require activation either via the command line
    or at the top of a file (similar to the __future__ requirement)
where it would
    affect only that file (and any Static Ducks imported to it)

Design Goals:
    The new syntax should
        * Be simple to read
        * Make it obvious what is happening; at the very least it should be
        obvious that new users can safely ignore it when writing their own code
        * Allow future compilers to optimize for Static Typing.
        * Work within a function or method definition to ensure a passed
        variable is the proper type
        * Allow Functions/Methods return values to be typed and checked
        * Raise an TypeError exception when the variable is set to something
        improper, or the function/method tries to return an improper value

Issues:
    If this PEP is implemented it may conflict with PEP 362
    (Function Signature Object)

Use Cases:
    Python to C compilers could be enhanced by allowing static ducks.
    IDE's code complete could be enhanced by having static ducks available
    IDE's issues prediction could be enhanced to detect type issues for code
    that uses static ducks (Like any static typed language)

Syntax Idea:
    """$type variable = value

    $returnType def function($type variable):
        #do stuff
        return value

    $returnType
    def function($type variable):
        #do stuff
        return value

    class test:
        $type variable = value

        $returnType def method(self, $type variable):
            #do stuff
            return value"""

    The reason I selected $type is because I couldn't think of anything else
    that $ was used for and I wanted a syntax similar to Decorators and similar
    to other statically typed languages.

    All types allow None or their proper type when setting, this so people
    can have typed variables that can be "undefined" for checking

Example:
    $int count = 0

    $bool def check($string testValue):
        return testValue.lower() == "true"


    class test:
        $string _name = None

        $string def get_name(self):
            return self._name

        def set_name(self, $string name):
            self._name = name

Usage Details:
    When a variable has been statically type, any time it is set later its type
    needs to be verified. I see this working in a similar way to how
    properties work. Also using this style would allow people to create
    their own static ducks.

    """psudo-code
        class StaticDuckBase(object):
            _value = None

        class IntTypeClass(StaticDuckBase):
            def _get_value(self):
                return self._value

            def _set_value(self, val):
                if isinstance(val, (int, type(None))):
                    self._value = val
                else:
                    try:
                        val = int(val)
                        self._value = val
                    except:
                        raise TypeError("Expected int, got " +
str(type(val)) + " instead!")

            value = property(_get_value, _set_value, None)

        class MyTypeClass(StaticDuckBase):
            def _get_value(self):
                return self._value

            def _set_value(self, val):
                if isinstance(val, MyType)):
                    self._value = val
                else:
                    raise TypeError("Expected MyType, got " +
str(type(val)) + " instead!")

            value = property(_get_value, _set_value, None)

        staticducks.add('mytype', MyTypeClass)
    """

    Though there will need to be some way to check if a variable is
    statically typed so that when you do $int count = 0 then later count = 5 it
    uses the static typing. Also if no static duck is specified it should
    revert to nonstatic but emit a warning that is only show when run
    with the -W option

Type List:
    Base Types:
        $int
        $float
        $bool
        $string
        $tuple
        $namedtuple
        $list
        $set
        $frozenset
        $dict
        $byte
        $bytearray
        $memoryview
        $nonstatic # This means treat it as if it were not statically typed

    Composite type
        $bytes -> $byte | $bytearray
        $number -> $int | $float | Decimal
        $seq -> $tuple | $list | $set | $frozenset | $namedtuple
        $sets -> $set | $frozenset

    Special Cases
        #lets you require a specific type for keys and values
        $dict($type key[, $type value])
            """eg
                $dict($int, $string) tmp = {} # creates a dict that requires
                ints as keys and strings as values
                $dict($nonstatic, $bool) tmp = {} # creates a dict that
                requires values to be bool, but keys can be anything
            """

        $tuple($type value) # lets you specify the type for the tuples values
        $list($type value) # lets you specify the type for the lists values
        $set($type value) # lets you specify the type for the sets values
        $frozenset($type value) # lets you specify the type for the sets values
        $sets($type value) # lets you specify the type for the sets values
        $seq($type value) # lets you specify the type for the sequence values

        $string(encoding="UTF-8", normalized=False)
        $normalized # This would be equiv of doing $string(normalized=True)
        $normalized(encoding="UTF-8")


From anfedorov at gmail.com  Sat Sep 19 10:32:12 2009
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Sat, 19 Sep 2009 04:32:12 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
Message-ID: <7659cab30909190132g487de729k3319960aff658965@mail.gmail.com>

I've seen type checking decorators that do what I think you're describing -
run-time type checking. Example 4 in PEP318 comes to mind:

http://www.python.org/dev/peps/pep-0318/#examples

Probably won't be added to the language syntax, however, although I could
see it sometimes being useful.

Cheers,
Andrey

On Sat, Sep 19, 2009 at 4:19 AM, Dj Gilcrease <digitalxero at gmail.com> wrote:

> I do not expect this idea to gain much traction but it has been an
> idea rolling around in my head for a year or two, so I decided to
> write it all down and see what other thought.
>
>
>
> Abstract:
>    Python does not currently support static typing of variables, which is
>    something I like, but there are times it would be nice to have static
>    typing for variables, or method/function return values.
>
>    Static Ducks should be able to run along side or imported to code that
>    does not use Static Ducks. Actual runtime enforcement of Static Ducks
>    should be off by default and require activation either via the command
> line
>    or at the top of a file (similar to the __future__ requirement)
> where it would
>    affect only that file (and any Static Ducks imported to it)
>
> Design Goals:
>    The new syntax should
>        * Be simple to read
>        * Make it obvious what is happening; at the very least it should be
>        obvious that new users can safely ignore it when writing their own
> code
>        * Allow future compilers to optimize for Static Typing.
>        * Work within a function or method definition to ensure a passed
>        variable is the proper type
>        * Allow Functions/Methods return values to be typed and checked
>        * Raise an TypeError exception when the variable is set to something
>        improper, or the function/method tries to return an improper value
>
> Issues:
>    If this PEP is implemented it may conflict with PEP 362
>    (Function Signature Object)
>
> Use Cases:
>    Python to C compilers could be enhanced by allowing static ducks.
>    IDE's code complete could be enhanced by having static ducks available
>    IDE's issues prediction could be enhanced to detect type issues for code
>    that uses static ducks (Like any static typed language)
>
> Syntax Idea:
>    """$type variable = value
>
>    $returnType def function($type variable):
>        #do stuff
>        return value
>
>    $returnType
>    def function($type variable):
>        #do stuff
>        return value
>
>    class test:
>        $type variable = value
>
>        $returnType def method(self, $type variable):
>            #do stuff
>            return value"""
>
>    The reason I selected $type is because I couldn't think of anything else
>    that $ was used for and I wanted a syntax similar to Decorators and
> similar
>    to other statically typed languages.
>
>    All types allow None or their proper type when setting, this so people
>    can have typed variables that can be "undefined" for checking
>
> Example:
>    $int count = 0
>
>    $bool def check($string testValue):
>        return testValue.lower() == "true"
>
>
>    class test:
>        $string _name = None
>
>        $string def get_name(self):
>            return self._name
>
>        def set_name(self, $string name):
>            self._name = name
>
> Usage Details:
>    When a variable has been statically type, any time it is set later its
> type
>    needs to be verified. I see this working in a similar way to how
>    properties work. Also using this style would allow people to create
>    their own static ducks.
>
>    """psudo-code
>        class StaticDuckBase(object):
>            _value = None
>
>        class IntTypeClass(StaticDuckBase):
>            def _get_value(self):
>                return self._value
>
>            def _set_value(self, val):
>                if isinstance(val, (int, type(None))):
>                    self._value = val
>                else:
>                    try:
>                        val = int(val)
>                        self._value = val
>                    except:
>                        raise TypeError("Expected int, got " +
> str(type(val)) + " instead!")
>
>            value = property(_get_value, _set_value, None)
>
>        class MyTypeClass(StaticDuckBase):
>            def _get_value(self):
>                return self._value
>
>            def _set_value(self, val):
>                if isinstance(val, MyType)):
>                    self._value = val
>                else:
>                    raise TypeError("Expected MyType, got " +
> str(type(val)) + " instead!")
>
>            value = property(_get_value, _set_value, None)
>
>        staticducks.add('mytype', MyTypeClass)
>    """
>
>    Though there will need to be some way to check if a variable is
>    statically typed so that when you do $int count = 0 then later count = 5
> it
>    uses the static typing. Also if no static duck is specified it should
>    revert to nonstatic but emit a warning that is only show when run
>    with the -W option
>
> Type List:
>    Base Types:
>        $int
>        $float
>        $bool
>        $string
>        $tuple
>        $namedtuple
>        $list
>        $set
>        $frozenset
>        $dict
>        $byte
>        $bytearray
>        $memoryview
>        $nonstatic # This means treat it as if it were not statically typed
>
>    Composite type
>        $bytes -> $byte | $bytearray
>        $number -> $int | $float | Decimal
>        $seq -> $tuple | $list | $set | $frozenset | $namedtuple
>        $sets -> $set | $frozenset
>
>    Special Cases
>        #lets you require a specific type for keys and values
>        $dict($type key[, $type value])
>            """eg
>                $dict($int, $string) tmp = {} # creates a dict that requires
>                ints as keys and strings as values
>                $dict($nonstatic, $bool) tmp = {} # creates a dict that
>                requires values to be bool, but keys can be anything
>            """
>
>        $tuple($type value) # lets you specify the type for the tuples
> values
>        $list($type value) # lets you specify the type for the lists values
>        $set($type value) # lets you specify the type for the sets values
>        $frozenset($type value) # lets you specify the type for the sets
> values
>        $sets($type value) # lets you specify the type for the sets values
>        $seq($type value) # lets you specify the type for the sequence
> values
>
>        $string(encoding="UTF-8", normalized=False)
>        $normalized # This would be equiv of doing $string(normalized=True)
>        $normalized(encoding="UTF-8")
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090919/427453d9/attachment.html>

From steve at pearwood.info  Sat Sep 19 11:16:42 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Sat, 19 Sep 2009 19:16:42 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
Message-ID: <200909191916.42861.steve@pearwood.info>

On Sat, 19 Sep 2009 06:19:25 pm Dj Gilcrease wrote:
> I do not expect this idea to gain much traction but it has been an
> idea rolling around in my head for a year or two, so I decided to
> write it all down and see what other thought.

For starters, it's not clear what a static duck is.

Is it a type? Is it a syntax? Is it an extension to existing built-in 
types? All of the above? 

When enabled, does the compiler do the type checking at compile time? 
Does it happen at runtime? Both? What sort of type checking is done? 
Pascal-style declarative type checking, or Haskell-style type 
inference?

Why "static duck"? What does this have to do with duck typing?

Rather than give an implementation of how users can create their own 
static ducks, it would be better to give some use-cases for where you 
would use them and what the behaviour is.



-- 
Steven D'Aprano


From masklinn at masklinn.net  Sat Sep 19 12:44:56 2009
From: masklinn at masklinn.net (Masklinn)
Date: Sat, 19 Sep 2009 12:44:56 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909191916.42861.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
Message-ID: <C994A7E7-5757-4DF7-A9E7-9115E849317C@masklinn.net>

On 19 Sep 2009, at 11:16 , Steven D'Aprano wrote:
> What sort of type checking is done?
> Pascal-style declarative type checking, or Haskell-style type
> inference?
Can't answer the rest, but from his examples and if $type and  
$returnType are indeed type specifications placeholders (which would  
be the ducks), it would be a java-style static type system (?).

And it would probably be run at "compile" time given the name, doing  
the checking at runtime wouldn't be very static.

As far as I'm concerned, it's a terrible idea. Because it doesn't fit  
well within Python as a dynamically typed language, because the syntax  
is ugly, because Java's C-inherited type prefixes look terrible and  
are extremely verbose, because Java's type system is pretty bad and  
finally because the proposal doesn't handle "generic" types, making it  
completely useless.

I also haven't seen any example of typing an instance attribute, the  
only example involving classes creates a class attribute:

    class test:
        $type variable = value

        $returnType def method(self, $type variable):
            #do stuff
            return value

From van.lindberg at gmail.com  Sat Sep 19 18:13:53 2009
From: van.lindberg at gmail.com (VanL)
Date: Sat, 19 Sep 2009 11:13:53 -0500
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909191916.42861.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
Message-ID: <4AB50341.1060303@gmail.com>

Steven D'Aprano wrote:
> Why "static duck"? What does this have to do with duck typing?

Because after someone proposes adding static typing, they need to duck. 
As in "Python types should be static." (ducks)

ducking'ly yours,

Van



From van.lindberg at gmail.com  Sat Sep 19 18:15:15 2009
From: van.lindberg at gmail.com (VanL)
Date: Sat, 19 Sep 2009 11:15:15 -0500
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909191916.42861.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
Message-ID: <4AB50393.9080703@gmail.com>

Steven D'Aprano wrote:
 > Why "static duck"? What does this have to do with duck typing?

Because after someone proposes adding static typing, they need to duck. 
As in "Python types should be static." (ducks)

ducking'ly yours,

Van



From lorgandon at gmail.com  Sat Sep 19 18:46:34 2009
From: lorgandon at gmail.com (Imri Goldberg)
Date: Sat, 19 Sep 2009 19:46:34 +0300
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
Message-ID: <fa980a6f0909190946l763b212cr81a01add8bebafd6@mail.gmail.com>

On Sat, Sep 19, 2009 at 11:19 AM, Dj Gilcrease <digitalxero at gmail.com>wrote:
[snip]

> Design Goals:
>    The new syntax should
>        * Be simple to read
>

Personally, I'm -1 on this. Still, if you're already changing the syntax,
you don't need the extra punctuation ( '$' in your examples). This could
work just as well without them:


> Example:
>    $int count = 0
>
>    $bool def check($string testValue):
>        return testValue.lower() == "true"
>

int count = 0
bool def check(string testValue):
    return testValue.lower() == "true"

AFAIK, since today all these cases generate syntax errors, they are pretty
unambiguous.

Cheers,
Imri

-- 
Imri Goldberg
--------------------------------------
www.algorithm.co.il/blogs/
--------------------------------------
-- insert signature here ----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090919/28209579/attachment.html>

From gerald.britton at gmail.com  Sat Sep 19 22:05:58 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Sat, 19 Sep 2009 16:05:58 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <fa980a6f0909190946l763b212cr81a01add8bebafd6@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com> 
	<fa980a6f0909190946l763b212cr81a01add8bebafd6@mail.gmail.com>
Message-ID: <5d1a32000909191305nfa31790i173bffc49d333ed3@mail.gmail.com>

Wow!  Python that looks a bit like Perl!  Larry and Guido reconciled!!
I love it!!!

+1000

On Sat, Sep 19, 2009 at 12:46 PM, Imri Goldberg <lorgandon at gmail.com> wrote:
>
> On Sat, Sep 19, 2009 at 11:19 AM, Dj Gilcrease <digitalxero at gmail.com>
> wrote:
> [snip]
>>
>> Design Goals:
>> ? ?The new syntax should
>> ? ? ? ?* Be simple to read
>
> Personally, I'm -1 on this. Still, if you're already changing the syntax,
> you don't need the extra punctuation ( '$' in your examples). This could
> work just as well without them:
>
>>
>> Example:
>> ? ?$int count = 0
>>
>> ? ?$bool def check($string testValue):
>> ? ? ? ?return testValue.lower() == "true"
>
> int count = 0
> bool def check(string testValue):
> ??? return testValue.lower() == "true"
>
> AFAIK, since today all these cases generate syntax errors, they are pretty
> unambiguous.
>
> Cheers,
> Imri
>
> --
> Imri Goldberg
> --------------------------------------
> www.algorithm.co.il/blogs/
> --------------------------------------
> -- insert signature here ----
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>



-- 
Gerald Britton


From digitalxero at gmail.com  Sun Sep 20 00:21:24 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 16:21:24 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909191916.42861.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
Message-ID: <e9764b730909191521g6c3c1618he915417d9c9dd346@mail.gmail.com>

On Sat, Sep 19, 2009 at 3:16 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Sat, 19 Sep 2009 06:19:25 pm Dj Gilcrease wrote:
>> I do not expect this idea to gain much traction but it has been an
>> idea rolling around in my head for a year or two, so I decided to
>> write it all down and see what other thought.
>
> For starters, it's not clear what a static duck is.
>
> Is it a type? Is it a syntax? Is it an extension to existing built-in
> types? All of the above?
>
> When enabled, does the compiler do the type checking at compile time?
> Does it happen at runtime? Both? What sort of type checking is done?
> Pascal-style declarative type checking, or Haskell-style type
> inference?
>
> Why "static duck"? What does this have to do with duck typing?
>
> Rather than give an implementation of how users can create their own
> static ducks, it would be better to give some use-cases for where you
> would use them and what the behaviour is.

The reason I called it static ducks is because you can do "static duck
typing". I didnt list file type objects because that means something
different to different people.

So lets say you want a file like object, any you only care about read,
write, and close.

class FileTypeCheck(StaticDuckBase):
    def _get_value(self):
        return self._value

    def _set_value(self, value):
        if not hasattr(value, 'read') or not hasattr(value, 'write')
or not hasattr(value, 'close'):
            raise TypeError("value must be have read, write and close methods")

        self._value = value

staticducks.add('file', FileTypeCheck)


From digitalxero at gmail.com  Sun Sep 20 00:24:03 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 16:24:03 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <C994A7E7-5757-4DF7-A9E7-9115E849317C@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
	<C994A7E7-5757-4DF7-A9E7-9115E849317C@masklinn.net>
Message-ID: <e9764b730909191524v787e8c7do9691f77e7f924fea@mail.gmail.com>

On Sat, Sep 19, 2009 at 4:44 AM, Masklinn <masklinn at masklinn.net> wrote:
> As far as I'm concerned, it's a terrible idea. Because it doesn't fit well
> within Python as a dynamically typed language, because the syntax is ugly,
> because Java's C-inherited type prefixes look terrible and are extremely
> verbose, because Java's type system is pretty bad and finally because the
> proposal doesn't handle "generic" types, making it completely useless.

explain "generic" types


From digitalxero at gmail.com  Sun Sep 20 00:26:51 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 16:26:51 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <fa980a6f0909190946l763b212cr81a01add8bebafd6@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<fa980a6f0909190946l763b212cr81a01add8bebafd6@mail.gmail.com>
Message-ID: <e9764b730909191526y59c1d5adnc6fb6792dfc09417@mail.gmail.com>

On Sat, Sep 19, 2009 at 10:46 AM, Imri Goldberg <lorgandon at gmail.com> wrote:
> Personally, I'm -1 on this. Still, if you're already changing the syntax,
> you don't need the extra punctuation ( '$' in your examples). This could
> work just as well without them:

The reason I picked the $ is because I think it would be harder to
change the syntax to support dynamically added types without some
"start type" token, but I may be wrong in that case since I suck at
language syntax generation


From masklinn at masklinn.net  Sun Sep 20 00:40:35 2009
From: masklinn at masklinn.net (Masklinn)
Date: Sun, 20 Sep 2009 00:40:35 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909191524v787e8c7do9691f77e7f924fea@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
	<C994A7E7-5757-4DF7-A9E7-9115E849317C@masklinn.net>
	<e9764b730909191524v787e8c7do9691f77e7f924fea@mail.gmail.com>
Message-ID: <5E288D2B-15EC-4316-92F4-541F67E72D5F@masklinn.net>

On 20 Sep 2009, at 00:24 , Dj Gilcrease wrote:
On Sat, Sep 19, 2009 at 4:44 AM, Masklinn <masklinn at masklinn.net> wrote:
>> As far as I'm concerned, it's a terrible idea. Because it doesn't  
>> fit well
>> within Python as a dynamically typed language, because the syntax  
>> is ugly,
>> because Java's C-inherited type prefixes look terrible and are  
>> extremely
>> verbose, because Java's type system is pretty bad and finally  
>> because the
>> proposal doesn't handle "generic" types, making it completely  
>> useless.
>
> explain "generic" types
parameterized types: a list of strings (List[String]), a tuple of  
(int, string) (Tuple[Int, String]), a dict of {Foo:Bar} (Dict[Foo,  
Bar]) etc?

Not having parameterized types means every time you take values out of  
e.g. a collection you'll have to either use an untyped/"dynamic"  
variable or cast it to the "right" type (nb: and Python doesn't have  
casts), and you lose the static guarantee of homogeneity for e.g.  
lists (with non-generic lists, all your lists are lists of `id` the  
"dynamic" type).

From tjreedy at udel.edu  Sun Sep 20 00:55:54 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 19 Sep 2009 18:55:54 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
Message-ID: <h93nhn$uhb$1@ger.gmane.org>

Dj Gilcrease wrote:

> Design Goals:
>     The new syntax should
>         * Be simple to read
>         * Make it obvious what is happening; at the very least it should be
>         obvious that new users can safely ignore it when writing their own code
>         * Allow future compilers to optimize for Static Typing.
>         * Work within a function or method definition to ensure a passed
>         variable is the proper type
>         * Allow Functions/Methods return values to be typed and checked
>         * Raise an TypeError exception when the variable is set to something
>         improper, or the function/method tries to return an improper value

My impression is that all the above could be done (at least by 
alternative implementations) with current 3.x function signatures. Where 
do you think they fail?

> Issues:
>     If this PEP is implemented it may conflict with PEP 362
>     (Function Signature Object)



From digitalxero at gmail.com  Sun Sep 20 00:59:44 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 16:59:44 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5E288D2B-15EC-4316-92F4-541F67E72D5F@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
	<C994A7E7-5757-4DF7-A9E7-9115E849317C@masklinn.net>
	<e9764b730909191524v787e8c7do9691f77e7f924fea@mail.gmail.com>
	<5E288D2B-15EC-4316-92F4-541F67E72D5F@masklinn.net>
Message-ID: <e9764b730909191559u20450edfteb2e06031290b3c9@mail.gmail.com>

On Sat, Sep 19, 2009 at 4:40 PM, Masklinn <masklinn at masklinn.net> wrote:
> parameterized types: a list of strings (List[String]), a tuple of (int,
> string) (Tuple[Int, String]), a dict of {Foo:Bar} (Dict[Foo, Bar]) etc?


$dict($type key[, $type value])
$tuple($type value) # lets you specify the type for the tuples values
$list($type value) # lets you specify the type for the lists values
$set($type value) # lets you specify the type for the sets values
$frozenset($type value) # lets you specify the type for the sets values
$sets($type value) # lets you specify the type for the sets values
$seq($type value) # lets you specify the type for the sequence values

These arent what you are looking for?


From steve at pearwood.info  Sun Sep 20 02:00:34 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 20 Sep 2009 10:00:34 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909191521g6c3c1618he915417d9c9dd346@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
	<e9764b730909191521g6c3c1618he915417d9c9dd346@mail.gmail.com>
Message-ID: <200909201000.34945.steve@pearwood.info>

On Sun, 20 Sep 2009 08:21:24 am Dj Gilcrease wrote:
> On Sat, Sep 19, 2009 at 3:16 AM, Steven D'Aprano <steve at pearwood.info> 
wrote:
> > On Sat, 19 Sep 2009 06:19:25 pm Dj Gilcrease wrote:
> >> I do not expect this idea to gain much traction but it has been an
> >> idea rolling around in my head for a year or two, so I decided to
> >> write it all down and see what other thought.
> >
> > For starters, it's not clear what a static duck is.
> >
> > Is it a type? Is it a syntax? Is it an extension to existing
> > built-in types? All of the above?
> >
> > When enabled, does the compiler do the type checking at compile
> > time? Does it happen at runtime? Both? What sort of type checking
> > is done? Pascal-style declarative type checking, or Haskell-style
> > type inference?
> >
> > Why "static duck"? What does this have to do with duck typing?
> >
> > Rather than give an implementation of how users can create their
> > own static ducks, it would be better to give some use-cases for
> > where you would use them and what the behaviour is.
>
> The reason I called it static ducks is because you can do "static
> duck typing". I didnt list file type objects because that means
> something different to different people.

You ignored most of my questions. I'll *guess* what your intention is.

You want the compiler to perform declarative type checking at compile 
time, with no type inference. You're proposing a syntax to declare 
types, with no implementation at all for how the compiler should 
actually do that checking.

(I'm guessing compile time because you call it *static* ducks, even 
though you state it should raise TypeError. But you never actually say 
whether that will be raised when the compiler compiles the code, or 
when it runs it.)

Personally, I'm not convinced that declarative type checking without 
type inference has enough benefit to be worth the pain of declarations.

Nor am I sure that "static duck typing" makes sense in dynamic languages 
like Python. Consider this example:


class Duck(object):
    def walk(self):
        return "waddle waddle"
    def swim(self):
        return "paddle paddle swim paddle"
    def quack(self):
        return "quack quack"


class Goose(object):
    def walk(self):
        return "waddle waddle flap waddle"
    def swim(self):
        return "paddle paddle swim paddle swim"
    def quack(self):
        return "honk honk hiss"


Is a goose sufficiently duck-like to be treated as a duck? Does it walk 
like a duck, swim like a duck and quack like a duck?
    
g = Goose()
hasattr(g, 'walk') and hasattr(g, 'swim') and hasattr(g, 'quack')
-> returns True, so it's a duck
Goose.waddle = Goose.walk
del Goose.walk
hasattr(g, 'walk')
-> returns False, so it's not a duck
Goose.walk = lambda self: "waddle flap flap waddle waddle"
hasattr(g, 'walk')
-> returns True, it's a duck again
del Goose.walk
g.walk = g.waddle
hasattr(g, 'walk')
-> returns True but only for this instance


At *compile time*, how do you know if the goose you receive is 
sufficiently duck-like or not? I don't think you can.

For static checking, it actually gets worse. I can do this:

g.__class__ = Duck

and totally mess up isinstance() checks as well. Just because something 
is created as a Duck doesn't mean it will still be a Duck by the time 
it gets to your function.



-- 
Steven D'Aprano


From digitalxero at gmail.com  Sun Sep 20 02:33:55 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 18:33:55 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909201000.34945.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info>
	<e9764b730909191521g6c3c1618he915417d9c9dd346@mail.gmail.com>
	<200909201000.34945.steve@pearwood.info>
Message-ID: <e9764b730909191733k5bf9f023x1cf30b7cec26634e@mail.gmail.com>

On Sat, Sep 19, 2009 at 6:00 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> You ignored most of my questions. I'll *guess* what your intention is.
>
> You want the compiler to perform declarative type checking at compile
> time, with no type inference. You're proposing a syntax to declare
> types, with no implementation at all for how the compiler should
> actually do that checking.
>
> (I'm guessing compile time because you call it *static* ducks, even
> though you state it should raise TypeError. But you never actually say
> whether that will be raised when the compiler compiles the code, or
> when it runs it.)

Actually I would say it does it at run time because of the requirement
that it work along side code that does not use this, both being
imported to and importing non static ducked code. In the case it
imports code that is not using static ducks it would have to check
anything you pass in to a method that is typed or assigned to an
attribute that is.


> Personally, I'm not convinced that declarative type checking without
> type inference has enough benefit to be worth the pain of declarations.
>
> Nor am I sure that "static duck typing" makes sense in dynamic languages
> like Python. Consider this example:
[snip]
> Is a goose sufficiently duck-like to be treated as a duck? Does it walk
> like a duck, swim like a duck and quack like a duck?

If all you are about are that it can walk swim and quack, then yes. If
you care how it walks, swims or quacks, then you would have to have a
duck and goose type that just checks if it is an instance of the right
class (like my int example). The point of duck typing is that you
generally dont care how just that it can. For file like objects you
dont care how it reads or writes just that it does


> At *compile time*, how do you know if the goose you receive is
> sufficiently duck-like or not? I don't think you can.
>
> For static checking, it actually gets worse. I can do this:
>
> g.__class__ = Duck
>
> and totally mess up isinstance() checks as well. Just because something
> is created as a Duck doesn't mean it will still be a Duck by the time
> it gets to your function.

If it is messing up isinstance then it is going to break any manual
type checking the user would try and setup as well, so I see no issue
with this


From greg.ewing at canterbury.ac.nz  Sun Sep 20 02:45:05 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 20 Sep 2009 12:45:05 +1200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4AB50341.1060303@gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909191916.42861.steve@pearwood.info> <4AB50341.1060303@gmail.com>
Message-ID: <4AB57B11.5020702@canterbury.ac.nz>

VanL wrote:

> Because after someone proposes adding static typing, they need to duck. 
> As in "Python types should be static." (ducks)

Also because having static typing in a dynamic language
is something of a pair o' ducks.

-- 
Greg


From debatem1 at gmail.com  Sun Sep 20 04:28:42 2009
From: debatem1 at gmail.com (CTO)
Date: Sat, 19 Sep 2009 19:28:42 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <7922.1253233496@parc.com>
References: <7922.1253233496@parc.com>
Message-ID: <6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>



On Sep 17, 8:24?pm, Bill Janssen <jans... at parc.com> wrote:
> A couple of weeks ago, there was a discussion on python-dev about adding
> the ability to load modules from encrypted zip files. ?I'm not sure the
> discussion went anywhere, and I was on vacation when it took place.
>
> However, it reminded me of an idea from a couple of years ago: extend
> the hashlib module to produce two additional kinds of hashes: a digital
> signature for some sequence of bytes, and an encrypted/decrypted version
> of a sequence of bytes. ?Basically, the would bring more of the OpenSSL
> EVP API out to Python (hashlib already uses OpenSSL EVP for various hash
> formations).
>
> http://www.openssl.org/docs/crypto/evp.html

Besides the fact that hashes and encryption are pretty much totally
different, I like the idea of putting more cryptographic power in the
standard library.

>
> With this, it would be fairly trivial to implement strong encryption of
> zip files (or anything else), and this could then be used to do the
> import feature.
>
> I'd envision adding new constructors to hashlib:
>
> ? ?sig = hashlib.signature([data] [, keyfile=...] [, signature_algorithm=...])
>
> This would have the regular update() method, and digest() and
> hexdigest(), but would also support the method
>
> ? ?sig.verify(existing_sig)
>
> which would return a boolean saying the "existing sig" is a verified
> signature for that data.
>
> Similarly, encryption/decryption would be
>
> ? ?enc = hashlib.encryptor([plaintext] [, keyfile=...] [, ciphers=...])
>
> enc.digest() would give the ciphertext.
>
> And
>
> ? ?dec = hashlib.decryptor([ciphertext] [, keyfile=...] [, ciphers=...])
>
> and dec.digest would yield the plaintext.
>
> The encryptor and decryptor constructors could take either "key" or
> "keyfile" parameters. ?Using "key" would support symmetric encrytion,
> while using "keyfile" would produce EVP envelope encryption/decryption.
>
> Bill

My only real concern about this approach is that it glosses over the
complexity of selecting and using a cryptosystem. How about passing
on having a default for the 'cipher' argument, at least?

Geremy Condra


From talin at acm.org  Sun Sep 20 04:29:55 2009
From: talin at acm.org (Talin)
Date: Sat, 19 Sep 2009 19:29:55 -0700
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
Message-ID: <4AB593A3.7080706@acm.org>

Dj Gilcrease wrote:
> I do not expect this idea to gain much traction but it has been an
> idea rolling around in my head for a year or two, so I decided to
> write it all down and see what other thought.
> 
> Abstract:
>     Python does not currently support static typing of variables, which is
>     something I like, but there are times it would be nice to have static
>     typing for variables, or method/function return values.

I am working on a somewhat different approach to this problem. (For 
sufficiently large values of 'somwhat different'.)

A while back, I came to the conclusion that there was still much to be 
learned about static typing, and that the existing languages that 
support static typing were misusing it - that is, in most languages 
static typing is used to enforce consistency (the advantage of which has 
been much debated) as opposed to making the language easier and more 
expressive.

Despite my fondness for Python, I realized that I didn't want something 
that would merely be a layer on top of Python syntax - the decision to 
incorporate static types would impact so many of the design choices of 
the language that it would end up being a fundamentally different language.

It was only after I discovered the existence of the LLVM project that I 
realized that I could actually build the language that I had been 
designing in my head.

So I set out to build that language, and along the way I would fix a 
number of other issues in Python, as well as the many issues I have with 
Java, C++, C#, D, Ruby, and so on. And also incorporate a few of the 
ideas which have been suggested on this list and others.

In any case, it's two years later and I am still working on the 
compiler. :) But I am making a lot of progress and it's slowly evolving 
into something that I think is quite cool.

I'm not the first person to attempt this, so if you want to try a 
language that is statically typed, but inspired by Python, then I 
suggest checking out Boo or Scala.

-- Talin


From digitalxero at gmail.com  Sun Sep 20 04:43:05 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 20:43:05 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4AB593A3.7080706@acm.org>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
Message-ID: <e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>

On Sat, Sep 19, 2009 at 8:29 PM, Talin <talin at acm.org> wrote:
> I'm not the first person to attempt this, so if you want to try a language
> that is statically typed, but inspired by Python, then I suggest checking
> out Boo or Scala.

I dont want Static typing as it exists in Java or C or whatever other
statically type langue that exists. I think of what I am trying to
accomplish as an easier way of having syntax for type checking that
does not involve having to do isinstance or hasattr checks in every
place you want to validate the type. You just set the type using a
decorator style syntax and the type checking is done automatically for
you, which will reduce code repetition, especially in getter/setter
methods of properties.


From digitalxero at gmail.com  Sun Sep 20 04:55:19 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 20:55:19 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
Message-ID: <e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>

On Sat, Sep 19, 2009 at 8:43 PM, Dj Gilcrease <digitalxero at gmail.com> wrote:
> I dont want Static typing as it exists in Java or C or whatever other
> statically type langue that exists.

I think a better name might be Strong Ducks, so instead of a Strongly
Typed Language you have a Strongly Duck Typed Option, which is just an
easier way of validating that what you are getting or setting meets
your needs in a way that is more flexible then an interface ala Java
or even an Abstract Base Class.


From bruce at leapyear.org  Sun Sep 20 06:21:02 2009
From: bruce at leapyear.org (Bruce Leban)
Date: Sat, 19 Sep 2009 21:21:02 -0700
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com> 
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com> 
	<e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
Message-ID: <cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>

I don't quite understand what you are trying to solve. Here's a related
problem: One of the issues with duck typing is that something might look
sort of like a duck but isn't really and it would be nice to make it easy to
avoid using an object in a "half-baked" manner:

    def playWithDuck(d):
       d.walk()
       d.quack()

if someone calls playWithDuck(dog) then the dog's going to get walked before
trying to make the dog quack fails. I'd like to be able to avoid that. I
could write:

   def playWithDuck(d):
      d.quack   # raises AttributeError if can't quack
      d.walk()
      d.quack()

but of course that doesn't check that d.quack is a function or even has the
right kind of signature. And I can write

    def playWithDuck(d):
      if not isinstance(d, Duck):
        raise TypeError("need a Duck")
      ...

which has it's own problems (I don't need a Duck; I just need something that
walks like a duck and quacks like a duck).

Is this the problem you are trying to solve? Or something else?

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090919/1cb60918/attachment.html>

From digitalxero at gmail.com  Sun Sep 20 07:50:19 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sat, 19 Sep 2009 23:50:19 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
	<e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
	<cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>
Message-ID: <e9764b730909192250s62853ee2xbc8e5f85309f8e2e@mail.gmail.com>

On Sat, Sep 19, 2009 at 10:21 PM, Bruce Leban <bruce at leapyear.org> wrote:
> I don't quite understand what you are trying to solve. Here's a related
> problem: One of the issues with duck typing is that something might look
> sort of like a duck but isn't really and it would be nice to make it easy to
> avoid using an object in a "half-baked" manner:
>
> ??? def playWithDuck(d):
> ?????? d.walk()
> ?????? d.quack()
>
> if someone calls playWithDuck(dog) then the dog's going to get walked before
> trying to make the dog quack fails. I'd like to be able to avoid that. I
> could write:
>
> ?? def playWithDuck(d):
> ????? d.quack?? # raises AttributeError if can't quack
> ????? d.walk()
> ????? d.quack()
>
> but of course that doesn't check that d.quack is a function or even has the
> right kind of signature. And I can write
>
> ??? def playWithDuck(d):
> ?? ?? if not isinstance(d, Duck):
> ? ? ??? raise TypeError("need a Duck")
> ????? ...
>
> which has it's own problems (I don't need a Duck; I just need something that
> walks like a duck and quacks like a duck).
>
> Is this the problem you are trying to solve? Or something else?


This is a good description of an issue I would like to solve with this.


From ncoghlan at gmail.com  Sun Sep 20 08:20:27 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Sep 2009 16:20:27 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
	<e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
	<cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>
Message-ID: <4AB5C9AB.7070706@gmail.com>

Bruce Leban wrote:
> but of course that doesn't check that d.quack is a function or even has
> the right kind of signature. And I can write
> 
>     def playWithDuck(d):
>       if not isinstance(d, Duck):
>         raise TypeError("need a Duck")
>       ...
> 
> which has it's own problems (I don't need a Duck; I just need something
> that walks like a duck and quacks like a duck).

Actually, so long as Duck is defined as an Abstract Base Class rather
than an ordinary type, then the above does solve your problem. If
someone wants to declare that their type does indeed walk and quack like
a duck, they can just call Duck.register(my_type).

Regarding static typing with type inference, something to look at would
be the repurposing of the auto keyword in C++0x (soon to be known as
C++1x, since the committee has declared the updated standard won't be
getting released this year).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From greg.ewing at canterbury.ac.nz  Sun Sep 20 09:21:45 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 20 Sep 2009 19:21:45 +1200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4AB593A3.7080706@acm.org>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
Message-ID: <4AB5D809.5040609@canterbury.ac.nz>

Talin wrote:
> the existing languages that 
> support static typing were misusing it - that is, in most languages 
> static typing is used to enforce consistency (the advantage of which has 
> been much debated) as opposed to making the language easier and more 
> expressive.

That's one side of it. The other side is giving the compiler
enough information about what you're trying to do that it
can generate safe and efficient code to do it.

> So I set out to build that language, and along the way I would fix a 
> number of other issues in Python, as well as the many issues I have with 
> Java, C++, C#, D, Ruby, and so on. And also incorporate a few of the 
> ideas which have been suggested on this list and others.

This sounds interesting. Would you mind sharing some of the
ideas you have about how to improve on the way previous
languages have used static typing?

Also I notice that all the languages you mention are imperative
ones. Have you looked at languages such as Haskell which use
type inferencing? Is there anything we can learn from that
camp?

(My experiences with type inferencing suggest that it's fine
up to a point, but you really need to insert explicit type
declarations at some key points, otherwise it becomes too
difficult to track down where type errors are coming from.)

I've also been grappling with static vs. dynamic typing
issues to some extent while developing Pyrex. Having an
essentially dynamically typed language that allows static
declarations where desired for efficiency seems to be
a very powerful idea. Cython seems to be heading in that
direction with the ability to add supplemental declarations
to otherwise pure Python code.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Sun Sep 20 09:34:29 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 20 Sep 2009 19:34:29 +1200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
Message-ID: <4AB5DB05.1050804@canterbury.ac.nz>

Dj Gilcrease wrote:

> I think of what I am trying to
> accomplish as an easier way of having syntax for type checking that
> does not involve having to do isinstance or hasattr checks in every
> place you want to validate the type.

A potential problem with this is that if you make it *too*
easy to write type checks, you're likely to end up with
inefficiencies due to types being checked a lot more
often than they really need to be.

There's a school of thought that expensive operations
shouldn't be hidden behind syntax that makes them appear
deceptively cheap. On that basis, since there is some
cost to doing a type check, it could be argued that
you should have to do a bit of work in order to write
one.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Sun Sep 20 09:36:58 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 20 Sep 2009 19:36:58 +1200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
	<e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
Message-ID: <4AB5DB9A.30805@canterbury.ac.nz>

Dj Gilcrease wrote:

> I think a better name might be Strong Ducks,

Or maybe Cautious Ducks, since they always look
before they leap anywhere.

-- 
Greg


From digitalxero at gmail.com  Sun Sep 20 10:42:15 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 20 Sep 2009 02:42:15 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4AB5DB05.1050804@canterbury.ac.nz>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
	<4AB5DB05.1050804@canterbury.ac.nz>
Message-ID: <e9764b730909200142p44163bd4vf99730d19963e87e@mail.gmail.com>

On Sun, Sep 20, 2009 at 1:34 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> A potential problem with this is that if you make it *too*
> easy to write type checks, you're likely to end up with
> inefficiencies due to types being checked a lot more
> often than they really need to be.

True, which is why I figured it should be off by default and need
either a command line option to be enabled globally or some form of
activation at the top of the file to be enabled for a specific module.
Doing it this way will make it so the dev needs to decide if they want
to incur the performance penalty for type safety. I figure it would be
used most often via the command line option for testing to ensure an
app or library is type safe within itself and leave it to people that
use it to make sure they are following the rules. The other common
place I see it being used is within an IDE to mark code as an error
that fails the specified type.


Since you work on Pyrex and one of the potential use cases I listed
was for python to c compilers is there anything you would change about
my specified syntax and usage to work better for Pyrex?


From greg.ewing at canterbury.ac.nz  Sun Sep 20 11:02:23 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 20 Sep 2009 21:02:23 +1200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909200142p44163bd4vf99730d19963e87e@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
	<4AB5DB05.1050804@canterbury.ac.nz>
	<e9764b730909200142p44163bd4vf99730d19963e87e@mail.gmail.com>
Message-ID: <4AB5EF9F.8060702@canterbury.ac.nz>

Dj Gilcrease wrote:

> Since you work on Pyrex and one of the potential use cases I listed
> was for python to c compilers is there anything you would change about
> my specified syntax and usage to work better for Pyrex?

Well, Pyrex already has its own syntax for declaring types
(essentially adopted from C) so it doesn't really need
another one. Also, there's no expectation that Pyrex will
be able to compile Python code in general, so it doesn't
matter to Pyrex what type declaration syntax, if any, gets
use in Python.

You might like to talk to the Cython crowd -- being able
to compile pure Python code *is* one of their goals.

If I were designing a language from scratch now with type
declarations, I would try to arrange it so that the types
come *after* the names being declared, as in Pascal,
because that makes it easier to scan down a list of
declarations looking for the definition of a name.

Also I don't particularly care for your use of $. It
looks out of place amongst the rest of the Python language.

-- 
Greg


From masklinn at masklinn.net  Sun Sep 20 11:56:30 2009
From: masklinn at masklinn.net (Masklinn)
Date: Sun, 20 Sep 2009 11:56:30 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
	<e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
	<cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>
Message-ID: <B3BBCEB3-5C38-4813-B395-3A19A3DF67BB@masklinn.net>

On 20 Sep 2009, at 06:21 , Bruce Leban wrote:
I don't quite understand what you are trying to solve. Here's a related
> problem: One of the issues with duck typing is that something might  
> look
> sort of like a duck but isn't really and it would be nice to make it  
> easy to
> avoid using an object in a "half-baked" manner:
>
>    def playWithDuck(d):
>       d.walk()
>       d.quack()
>
> if someone calls playWithDuck(dog) then the dog's going to get  
> walked before
> trying to make the dog quack fails.

Note that with a structural type system (that of OCaml's objects for  
instance) this will work, the `playWithDuck` function will be inferred  
to take any subtype of < walk : unit; duck : unit > (or something like  
that) (basically, any object with a `walk` and a `quack` method (both  
returning nothing) will work).



From ubershmekel at gmail.com  Sun Sep 20 16:14:26 2009
From: ubershmekel at gmail.com (Yuvgoog Greenle)
Date: Sun, 20 Sep 2009 17:14:26 +0300
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <B3BBCEB3-5C38-4813-B395-3A19A3DF67BB@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<4AB593A3.7080706@acm.org>
	<e9764b730909191943v19f86027ybd1065802ec2e1e4@mail.gmail.com>
	<e9764b730909191955i7cc8ccfflfcfcad296f0a24b4@mail.gmail.com>
	<cf5b87740909192121r2f843733v72fa4b620ceadfdb@mail.gmail.com>
	<B3BBCEB3-5C38-4813-B395-3A19A3DF67BB@masklinn.net>
Message-ID: <9d153b7c0909200714l1f6cff79p782b8c830446ecb9@mail.gmail.com>

I was trying to think how a decorator @strict_duck_typing could be
implemented to solve the issue Bruce Leban described. The more I think about
it, the harder I think it is to implement.
I wanted to do something along the lines of:

def parameters_from_signature(function, args, kwargs):
    "Translate a generic function call to the function's parameters by name"
    argnames, varargs, keywords, defaults = inspect.getargspec(function)
    args_and_kwargs = kwargs.copy()
    names_and_args = zip(argnames, args)
    args_and_kwargs.update(names_and_args)
    if varargs is not None:
        args_and_kwargs[varargs] = args[len(argnames):]
    return args_and_kwargs

def strict_duck_typing(function):
    attr_dict = attributes_used_by_function(function)

    def verify_and_run(*args, **kwargs):
        called_with = parameters_from_signature(function, args, kwargs)

        for parameter, attributes_needed in attr_dict.items():
            for attr in attributes_needed:
                if not hasattr(called_with[parameter], attr):
                    raise TypeError("Parameter '%s' given doesn't have '%s'
attribute/method." % (parameter, attr))

        function(*args, **kwargs)

Of course the big enchilada is the function 'attributes_used_by_function'
which I left out because it has to do some insane things. I was thinking of
using ast.parse(inspect.getsource(function)) and then:

   1. stepping into each function call which involves the function
   parameters, perhaps repeating the ast.parse/inspect.getsource combo.
   2. collecting all the methods and attributes accessed.
   3. getattr/setattr/hasattr need to be simulated or handled
   4. return a dictionary of { parameter_name: attributes_needed_set }

And even after this crazy piece of work there are some limitations ie:

   1. C functions wouldn't be inspected, which is a tragedy, ie len(),
   iter(), etc have to be especially treated...
   2. dynamically generated attributes and attribute names will always break
   this decorator.
   3. performance issues
   4. probably more things i didn't think of...


So I like the idea of strict duck typing, but it's gonna take more than one
mailing list reply for me to write a POC :)


On Sun, Sep 20, 2009 at 12:56 PM, Masklinn <masklinn at masklinn.net> wrote:

> On 20 Sep 2009, at 06:21 , Bruce Leban wrote:
> I don't quite understand what you are trying to solve. Here's a related
>
>> problem: One of the issues with duck typing is that something might look
>> sort of like a duck but isn't really and it would be nice to make it easy
>> to
>> avoid using an object in a "half-baked" manner:
>>
>>   def playWithDuck(d):
>>      d.walk()
>>      d.quack()
>>
>> if someone calls playWithDuck(dog) then the dog's going to get walked
>> before
>> trying to make the dog quack fails.
>>
>
> Note that with a structural type system (that of OCaml's objects for
> instance) this will work, the `playWithDuck` function will be inferred to
> take any subtype of < walk : unit; duck : unit > (or something like that)
> (basically, any object with a `walk` and a `quack` method (both returning
> nothing) will work).
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090920/5739fe57/attachment.html>

From janssen at parc.com  Sun Sep 20 19:07:11 2009
From: janssen at parc.com (Bill Janssen)
Date: Sun, 20 Sep 2009 10:07:11 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
Message-ID: <20862.1253466431@parc.com>

CTO <debatem1 at gmail.com> wrote:

> > However, it reminded me of an idea from a couple of years ago: extend
> > the hashlib module to produce two additional kinds of hashes: a digital
> > signature for some sequence of bytes, and an encrypted/decrypted version
> > of a sequence of bytes.  Basically, the would bring more of the OpenSSL
> > EVP API out to Python (hashlib already uses OpenSSL EVP for various hash
> > formations).
> >
> > http://www.openssl.org/docs/crypto/evp.html
> 
> Besides the fact that hashes and encryption are pretty much totally
> different

I know it seems that way at first glance, but in fact they are strongly
related.  There's a reason all three (and nothing else) are exported
through OpenSSL's EVP API.

Bill


From kornelpal at gmail.com  Sun Sep 20 19:40:48 2009
From: kornelpal at gmail.com (=?ISO-8859-1?Q?Korn=E9l_P=E1l?=)
Date: Sun, 20 Sep 2009 19:40:48 +0200
Subject: [Python-ideas] Python Bytecode Verifier
In-Reply-To: <20090304144922.GA2645@panix.com>
References: <9440ace50903040121o22e86ad4sd354af4030d2d922@mail.gmail.com>
	<20090304144922.GA2645@panix.com>
Message-ID: <4AB66920.50500@gmail.com>

Aahz wrote:
>> I've created a Python Bytecode Verifier in Python. I'm not a Python
>> guru so I borrowed coding patterns from C/C++. I also created this
>> with C portability in mind. The only reason I used Python was to
>> experiment with Python and was easier to morph code during
>> development.
> 
> You should upload this to PyPI.

It's now available at 
http://pypi.python.org/pypi/Python%20Bytecode%20Verifier/0.1 under 
MIT/X11 license now with support for Python versions 2.5, 2.6, 3.0 and 
3.1 but lacks conformance tests for invalid bytecode.

Korn?l



From debatem1 at gmail.com  Sun Sep 20 20:52:29 2009
From: debatem1 at gmail.com (CTO)
Date: Sun, 20 Sep 2009 11:52:29 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <20862.1253466431@parc.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
Message-ID: <9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>



On Sep 20, 1:07?pm, Bill Janssen <jans... at parc.com> wrote:
> CTO <debat... at gmail.com> wrote:
> > > However, it reminded me of an idea from a couple of years ago: extend
> > > the hashlib module to produce two additional kinds of hashes: a digital
> > > signature for some sequence of bytes, and an encrypted/decrypted version
> > > of a sequence of bytes. ?Basically, the would bring more of the OpenSSL
> > > EVP API out to Python (hashlib already uses OpenSSL EVP for various hash
> > > formations).
>
> > >http://www.openssl.org/docs/crypto/evp.html
>
> > Besides the fact that hashes and encryption are pretty much totally
> > different
>
> I know it seems that way at first glance, but in fact they are strongly
> related. ?There's a reason all three (and nothing else) are exported
> through OpenSSL's EVP API.
>
> Bill

Don't get me wrong, I like the basic idea you're advancing, and in
use hashes and crypto are frequently seen together, but they solve
different problems in *very* different ways. The fact that you-
who obviously have some interest in crypto and presumably a good
deal of knowledge about it- seem to be under the impression that
RSA and SHA have some kinship, well, it doesn't reassure me about
the ability of non-experts to figure out what's what. IMO, adding
public key crypto routines to hashlib seems almost guaranteed to
increase that confusion. Others will doubtless disagree.

Geremy Condra


From greg at krypto.org  Mon Sep 21 02:32:16 2009
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 20 Sep 2009 17:32:16 -0700
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
Message-ID: <52dc1c820909201732u58c44c88q4276444112794cdf@mail.gmail.com>

On Sun, Sep 20, 2009 at 11:52 AM, CTO <debatem1 at gmail.com> wrote:
>
>
> On Sep 20, 1:07?pm, Bill Janssen <jans... at parc.com> wrote:
>> CTO <debat... at gmail.com> wrote:
>> > > However, it reminded me of an idea from a couple of years ago: extend
>> > > the hashlib module to produce two additional kinds of hashes: a digital
>> > > signature for some sequence of bytes, and an encrypted/decrypted version
>> > > of a sequence of bytes. ?Basically, the would bring more of the OpenSSL
>> > > EVP API out to Python (hashlib already uses OpenSSL EVP for various hash
>> > > formations).
>>
>> > >http://www.openssl.org/docs/crypto/evp.html
>>
>> > Besides the fact that hashes and encryption are pretty much totally
>> > different
>>
>> I know it seems that way at first glance, but in fact they are strongly
>> related. ?There's a reason all three (and nothing else) are exported
>> through OpenSSL's EVP API.
>>
>> Bill
>
> Don't get me wrong, I like the basic idea you're advancing, and in
> use hashes and crypto are frequently seen together, but they solve
> different problems in *very* different ways. The fact that you-
> who obviously have some interest in crypto and presumably a good
> deal of knowledge about it- seem to be under the impression that
> RSA and SHA have some kinship, well, it doesn't reassure me about
> the ability of non-experts to figure out what's what. IMO, adding
> public key crypto routines to hashlib seems almost guaranteed to
> increase that confusion. Others will doubtless disagree.
>
> Geremy Condra

I don't like the attempt to overload the hash function API.
Encryption and decryption should not be done using a digest() method.
That makes no sense.  They are stream APIs with a constant mapping of
bytes in to bytes out rather than a hash function that always outputs
a constant number of bytes.

I wouldn't put signing functions in hashlib itself but any common EVP
wrapping code under could be shared.  Before doing that I really
suggest someone fleshes out the API and limits its scope to avoid
feature creep.

http://pycrypto.org/ is the API that most Python code wanting crypto
services use today.


From ilya.nikokoshev at gmail.com  Mon Sep 21 03:39:34 2009
From: ilya.nikokoshev at gmail.com (ilya)
Date: Mon, 21 Sep 2009 05:39:34 +0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
Message-ID: <d8cc6f9d0909201839u1e770779n96eae835cea606a3@mail.gmail.com>

I tried to read most of the thread, but I'm still not sure about the
exact meaning of the proposal. Here is how I understand it.

There are two ways to add strong typing to the language. One is called
"static typing", and it's done before you generate a bytecode,
another, "dynamic/run-time typing" is done at run-time.

Static typing is unlikely to work in Python. Suppose I do
$list a = ['string', 5+6]
$int index = some_very_complicated_calculation()
??? a[index]   # Compiler cannot know if this is string, int or IndexError.
or I could try accessing globals(name) or sys.module[name].attribute
-- compile-time check is impossible.

>From what I read I think you suggest to add run-time typing to the
language. That is partly possible now with decorators and the
annotations syntax -- you might want to check that out -- but how
useful is it really? The very fact that X is integer and Y is integer
doesn't mean that X + Y or X * Y always makes sense.


There was a very good question on StackOverflow that dealt with
typing: http://stackoverflow.com/questions/1275646/python-3-and-static-typing/1276582#1276582

My detailed opinion and links can be found there in the answer (the
accepted one).

Ilya.

On Sat, Sep 19, 2009 at 12:19 PM, Dj Gilcrease <digitalxero at gmail.com> wrote:
> I do not expect this idea to gain much traction but it has been an
> idea rolling around in my head for a year or two, so I decided to
> write it all down and see what other thought.
>
>
>
> Abstract:
> ? ?Python does not currently support static typing of variables, which is
> ? ?something I like, but there are times it would be nice to have static
> ? ?typing for variables, or method/function return values.
>
> ? ?Static Ducks should be able to run along side or imported to code that
> ? ?does not use Static Ducks. Actual runtime enforcement of Static Ducks
> ? ?should be off by default and require activation either via the command line
> ? ?or at the top of a file (similar to the __future__ requirement)
> where it would
> ? ?affect only that file (and any Static Ducks imported to it)
>
> Design Goals:
> ? ?The new syntax should
> ? ? ? ?* Be simple to read
> ? ? ? ?* Make it obvious what is happening; at the very least it should be
> ? ? ? ?obvious that new users can safely ignore it when writing their own code
> ? ? ? ?* Allow future compilers to optimize for Static Typing.
> ? ? ? ?* Work within a function or method definition to ensure a passed
> ? ? ? ?variable is the proper type
> ? ? ? ?* Allow Functions/Methods return values to be typed and checked
> ? ? ? ?* Raise an TypeError exception when the variable is set to something
> ? ? ? ?improper, or the function/method tries to return an improper value
>
> Issues:
> ? ?If this PEP is implemented it may conflict with PEP 362
> ? ?(Function Signature Object)
>
> Use Cases:
> ? ?Python to C compilers could be enhanced by allowing static ducks.
> ? ?IDE's code complete could be enhanced by having static ducks available
> ? ?IDE's issues prediction could be enhanced to detect type issues for code
> ? ?that uses static ducks (Like any static typed language)
>
> Syntax Idea:
> ? ?"""$type variable = value
>
> ? ?$returnType def function($type variable):
> ? ? ? ?#do stuff
> ? ? ? ?return value
>
> ? ?$returnType
> ? ?def function($type variable):
> ? ? ? ?#do stuff
> ? ? ? ?return value
>
> ? ?class test:
> ? ? ? ?$type variable = value
>
> ? ? ? ?$returnType def method(self, $type variable):
> ? ? ? ? ? ?#do stuff
> ? ? ? ? ? ?return value"""
>
> ? ?The reason I selected $type is because I couldn't think of anything else
> ? ?that $ was used for and I wanted a syntax similar to Decorators and similar
> ? ?to other statically typed languages.
>
> ? ?All types allow None or their proper type when setting, this so people
> ? ?can have typed variables that can be "undefined" for checking
>
> Example:
> ? ?$int count = 0
>
> ? ?$bool def check($string testValue):
> ? ? ? ?return testValue.lower() == "true"
>
>
> ? ?class test:
> ? ? ? ?$string _name = None
>
> ? ? ? ?$string def get_name(self):
> ? ? ? ? ? ?return self._name
>
> ? ? ? ?def set_name(self, $string name):
> ? ? ? ? ? ?self._name = name
>
> Usage Details:
> ? ?When a variable has been statically type, any time it is set later its type
> ? ?needs to be verified. I see this working in a similar way to how
> ? ?properties work. Also using this style would allow people to create
> ? ?their own static ducks.
>
> ? ?"""psudo-code
> ? ? ? ?class StaticDuckBase(object):
> ? ? ? ? ? ?_value = None
>
> ? ? ? ?class IntTypeClass(StaticDuckBase):
> ? ? ? ? ? ?def _get_value(self):
> ? ? ? ? ? ? ? ?return self._value
>
> ? ? ? ? ? ?def _set_value(self, val):
> ? ? ? ? ? ? ? ?if isinstance(val, (int, type(None))):
> ? ? ? ? ? ? ? ? ? ?self._value = val
> ? ? ? ? ? ? ? ?else:
> ? ? ? ? ? ? ? ? ? ?try:
> ? ? ? ? ? ? ? ? ? ? ? ?val = int(val)
> ? ? ? ? ? ? ? ? ? ? ? ?self._value = val
> ? ? ? ? ? ? ? ? ? ?except:
> ? ? ? ? ? ? ? ? ? ? ? ?raise TypeError("Expected int, got " +
> str(type(val)) + " instead!")
>
> ? ? ? ? ? ?value = property(_get_value, _set_value, None)
>
> ? ? ? ?class MyTypeClass(StaticDuckBase):
> ? ? ? ? ? ?def _get_value(self):
> ? ? ? ? ? ? ? ?return self._value
>
> ? ? ? ? ? ?def _set_value(self, val):
> ? ? ? ? ? ? ? ?if isinstance(val, MyType)):
> ? ? ? ? ? ? ? ? ? ?self._value = val
> ? ? ? ? ? ? ? ?else:
> ? ? ? ? ? ? ? ? ? ?raise TypeError("Expected MyType, got " +
> str(type(val)) + " instead!")
>
> ? ? ? ? ? ?value = property(_get_value, _set_value, None)
>
> ? ? ? ?staticducks.add('mytype', MyTypeClass)
> ? ?"""
>
> ? ?Though there will need to be some way to check if a variable is
> ? ?statically typed so that when you do $int count = 0 then later count = 5 it
> ? ?uses the static typing. Also if no static duck is specified it should
> ? ?revert to nonstatic but emit a warning that is only show when run
> ? ?with the -W option
>
> Type List:
> ? ?Base Types:
> ? ? ? ?$int
> ? ? ? ?$float
> ? ? ? ?$bool
> ? ? ? ?$string
> ? ? ? ?$tuple
> ? ? ? ?$namedtuple
> ? ? ? ?$list
> ? ? ? ?$set
> ? ? ? ?$frozenset
> ? ? ? ?$dict
> ? ? ? ?$byte
> ? ? ? ?$bytearray
> ? ? ? ?$memoryview
> ? ? ? ?$nonstatic # This means treat it as if it were not statically typed
>
> ? ?Composite type
> ? ? ? ?$bytes -> $byte | $bytearray
> ? ? ? ?$number -> $int | $float | Decimal
> ? ? ? ?$seq -> $tuple | $list | $set | $frozenset | $namedtuple
> ? ? ? ?$sets -> $set | $frozenset
>
> ? ?Special Cases
> ? ? ? ?#lets you require a specific type for keys and values
> ? ? ? ?$dict($type key[, $type value])
> ? ? ? ? ? ?"""eg
> ? ? ? ? ? ? ? ?$dict($int, $string) tmp = {} # creates a dict that requires
> ? ? ? ? ? ? ? ?ints as keys and strings as values
> ? ? ? ? ? ? ? ?$dict($nonstatic, $bool) tmp = {} # creates a dict that
> ? ? ? ? ? ? ? ?requires values to be bool, but keys can be anything
> ? ? ? ? ? ?"""
>
> ? ? ? ?$tuple($type value) # lets you specify the type for the tuples values
> ? ? ? ?$list($type value) # lets you specify the type for the lists values
> ? ? ? ?$set($type value) # lets you specify the type for the sets values
> ? ? ? ?$frozenset($type value) # lets you specify the type for the sets values
> ? ? ? ?$sets($type value) # lets you specify the type for the sets values
> ? ? ? ?$seq($type value) # lets you specify the type for the sequence values
>
> ? ? ? ?$string(encoding="UTF-8", normalized=False)
> ? ? ? ?$normalized # This would be equiv of doing $string(normalized=True)
> ? ? ? ?$normalized(encoding="UTF-8")
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From ncoghlan at gmail.com  Mon Sep 21 14:27:02 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 Sep 2009 22:27:02 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <d8cc6f9d0909201839u1e770779n96eae835cea606a3@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<d8cc6f9d0909201839u1e770779n96eae835cea606a3@mail.gmail.com>
Message-ID: <4AB77116.6040802@gmail.com>

ilya wrote:
> I tried to read most of the thread, but I'm still not sure about the
> exact meaning of the proposal. Here is how I understand it.
> 
> There are two ways to add strong typing to the language. One is called
> "static typing", and it's done before you generate a bytecode,
> another, "dynamic/run-time typing" is done at run-time.

Python already has strong dynamic typing. strong-vs-weak and
static-vs-dynamic are orthogonal attributes of type systems.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From masklinn at masklinn.net  Mon Sep 21 14:47:07 2009
From: masklinn at masklinn.net (Masklinn)
Date: Mon, 21 Sep 2009 14:47:07 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4AB77116.6040802@gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<d8cc6f9d0909201839u1e770779n96eae835cea606a3@mail.gmail.com>
	<4AB77116.6040802@gmail.com>
Message-ID: <B6D845F6-1746-4F23-9CD3-F8F1F5359A27@masklinn.net>

On 21 Sep 2009, at 14:27 , Nick Coghlan wrote:
> ilya wrote:
>> I tried to read most of the thread, but I'm still not sure about the
>> exact meaning of the proposal. Here is how I understand it.
>>
>> There are two ways to add strong typing to the language. One is  
>> called
>> "static typing", and it's done before you generate a bytecode,
>> another, "dynamic/run-time typing" is done at run-time.
>
> Python already has strong dynamic typing. strong-vs-weak and
> static-vs-dynamic are orthogonal attributes of type systems.
The first part is usually considered true, the second part is more  
difficult to handle. The issue being that "strong typing/weak typing"  
isn't formally defined at all, an people tend to make "their own"  
definition of it to fit their preconceptions: a few years ago, Mark- 
Jason Dominus found (at least) 8 different definitions of the concept  
( http://groups.google.com/group/comp.lang.perl.moderated/tree/browse_frm/thread/e2e153d2ad7380c5/73d99bd8d5d16d8a?rnum=1&_done=%2Fgroup%2Fcomp.lang.perl.moderated%2Fbrowse_frm%2Fthread%2Fe2e153d2ad7380c5%2F73d99bd8d5d16d8a%3Ftvc%3D1%26#doc_89b5f256ea7bfadb 
  ) and B.C.Pierce [TAPL] gave up on the subject altogether after a  
pair of weeks of research. The mere idea of talking about "strong  
typing" without precisely defining what you mean by that is therefore  
bound to fail (as for one person Tcl will be strongly typed, meanwhile  
for another one anything falling short of *ML or Haskell is weakly  
typed).

The static/dynamic typing axis is better defined (though there's a lot  
of blurring, it's a continuous path rather than a binary proposition).


From python at mrabarnett.plus.com  Mon Sep 21 15:55:57 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 21 Sep 2009 14:55:57 +0100
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <B6D845F6-1746-4F23-9CD3-F8F1F5359A27@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<d8cc6f9d0909201839u1e770779n96eae835cea606a3@mail.gmail.com>	<4AB77116.6040802@gmail.com>
	<B6D845F6-1746-4F23-9CD3-F8F1F5359A27@masklinn.net>
Message-ID: <4AB785ED.7000106@mrabarnett.plus.com>

Masklinn wrote:
> On 21 Sep 2009, at 14:27 , Nick Coghlan wrote:
>> ilya wrote:
>>> I tried to read most of the thread, but I'm still not sure about the
>>> exact meaning of the proposal. Here is how I understand it.
>>>
>>> There are two ways to add strong typing to the language. One is called
>>> "static typing", and it's done before you generate a bytecode,
>>> another, "dynamic/run-time typing" is done at run-time.
>>
>> Python already has strong dynamic typing. strong-vs-weak and
>> static-vs-dynamic are orthogonal attributes of type systems.
> The first part is usually considered true, the second part is more 
> difficult to handle. The issue being that "strong typing/weak typing" 
> isn't formally defined at all, an people tend to make "their own" 
> definition of it to fit their preconceptions: a few years ago, 
> Mark-Jason Dominus found (at least) 8 different definitions of the 
> concept ( 
> http://groups.google.com/group/comp.lang.perl.moderated/tree/browse_frm/thread/e2e153d2ad7380c5/73d99bd8d5d16d8a?rnum=1&_done=%2Fgroup%2Fcomp.lang.perl.moderated%2Fbrowse_frm%2Fthread%2Fe2e153d2ad7380c5%2F73d99bd8d5d16d8a%3Ftvc%3D1%26#doc_89b5f256ea7bfadb ) 
> and B.C.Pierce [TAPL] gave up on the subject altogether after a pair of 
> weeks of research. The mere idea of talking about "strong typing" 
> without precisely defining what you mean by that is therefore bound to 
> fail (as for one person Tcl will be strongly typed, meanwhile for 
> another one anything falling short of *ML or Haskell is weakly typed).
> 
> The static/dynamic typing axis is better defined (though there's a lot 
> of blurring, it's a continuous path rather than a binary proposition).
> 
I know of one language which is weakly typed: BCPL. It's only type is
the bit pattern. It's the function or operator which interprets the bits
as representing a certain value.


From janssen at parc.com  Mon Sep 21 17:43:49 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 21 Sep 2009 08:43:49 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
Message-ID: <19693.1253547829@parc.com>

CTO <debatem1 at gmail.com> wrote:

> > I know it seems that way at first glance, but in fact they are strongly
> > related. ?There's a reason all three (and nothing else) are exported
> > through OpenSSL's EVP API.
> >
> > Bill
> 
> Don't get me wrong, I like the basic idea you're advancing, and in
> use hashes and crypto are frequently seen together,

Yes, that's the relationship I was thinking of.  But from a broader
philosophical view, a ciphertext can be thought of as a hash of a
plaintext, too.  A reversible hash.

> IMO, adding public key crypto routines to hashlib seems almost
> guaranteed to increase that confusion.

Well, that could be.  Perhaps the packaging "insight" I had wasn't
inspired :-).  I was thinking that from the crypto-ignorant point of
view, they seem quite similar.  A SHA256 hash can be seen as a digital
"signature" (or I've heard it called a "fingerprint") of a sequence of
bytes, just as with a public-key signature.  Sure, what's going on is
different, but from a utility point of view, it's much the same.  This
is why people post md5 checksums of downloadable packages -- it's a
signature.

Bill


From janssen at parc.com  Mon Sep 21 17:47:15 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 21 Sep 2009 08:47:15 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <52dc1c820909201732u58c44c88q4276444112794cdf@mail.gmail.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<52dc1c820909201732u58c44c88q4276444112794cdf@mail.gmail.com>
Message-ID: <19716.1253548035@parc.com>

Gregory P. Smith <greg at krypto.org> wrote:

> I don't like the attempt to overload the hash function API.
> Encryption and decryption should not be done using a digest() method.
> That makes no sense.  They are stream APIs with a constant mapping of
> bytes in to bytes out rather than a hash function that always outputs
> a constant number of bytes.

Sure, I could see the stream API, as well, but I think the hashlib
methods actually work pretty well for this, too.  Certainly for
the digital signature portion.

> I wouldn't put signing functions in hashlib itself but any common EVP
> wrapping code under could be shared.  Before doing that I really
> suggest someone fleshes out the API and limits its scope to avoid
> feature creep.

Yes, the right thing to do is to generate a separate module and put it
up in PyPI.  See how it goes.  Further consolidation could be left to
the future.

Bill


From debatem1 at gmail.com  Mon Sep 21 22:46:29 2009
From: debatem1 at gmail.com (CTO)
Date: Mon, 21 Sep 2009 13:46:29 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <19693.1253547829@parc.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
Message-ID: <65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>



On Sep 21, 11:43?am, Bill Janssen <jans... at parc.com> wrote:
> CTO <debat... at gmail.com> wrote:
> > > I know it seems that way at first glance, but in fact they are strongly
> > > related. ?There's a reason all three (and nothing else) are exported
> > > through OpenSSL's EVP API.
>
> > > Bill
>
> > Don't get me wrong, I like the basic idea you're advancing, and in
> > use hashes and crypto are frequently seen together,
>
> Yes, that's the relationship I was thinking of. ?But from a broader
> philosophical view, a ciphertext can be thought of as a hash of a
> plaintext, too. ?A reversible hash.

You really shouldn't conflate these things. The point of a hash is
to ensure message integrity, while the point of encryption is to
preserve secrecy. As an example, ElGamal is a common cryptosystem
that nevertheless preserves the multiplicative homomorphism, ie,
E(m1) * E(m2) = E(m1*m2). Others, including unpadded RSA, will
demonstrate similar properties. Under certain conditions, that
can be desirable, but under many others it is very, very bad.
Think of encrypting the value for a debit purchase- $100000 is
just a public-key operation away from $10, but would be
financially crippling to most people.

> > IMO, adding public key crypto routines to hashlib seems almost
> > guaranteed to increase that confusion.
>
> Well, that could be. ?Perhaps the packaging "insight" I had wasn't
> inspired :-). ?I was thinking that from the crypto-ignorant point of
> view, they seem quite similar. ?A SHA256 hash can be seen as a digital
> "signature" (or I've heard it called a "fingerprint") of a sequence of
> bytes, just as with a public-key signature. ?Sure, what's going on is
> different, but from a utility point of view, it's much the same. ?This
> is why people post md5 checksums of downloadable packages -- it's a
> signature.

Also a very bad idea. Hashes ensure data integrity, not that it came
from the person that you think it came from. As an example, if I took
a message, MD5'd it (a bad idea anyway), and appended it to the end,
an adversary could just man-in-the-middle the process and wind up
changing both message and hash. To you, this would remain
undetectable,
and in your example would result in the adversary installing
arbitrary
code on your machine. A good public key signature system can help to
prevent that, although even that has some nontrivial difficulties
associated with it.

My point here is not to scare you away from crypto- its to point out
that crypto is a big field, and the consequences for getting it wrong
are sometimes very high.

Geremy Condra


From janssen at parc.com  Mon Sep 21 23:37:35 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 21 Sep 2009 14:37:35 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
Message-ID: <28161.1253569055@parc.com>

CTO <debatem1 at gmail.com> wrote:

> On Sep 21, 11:43?am, Bill Janssen <jans... at parc.com> wrote:
> > CTO <debat... at gmail.com> wrote:
> > > > I know it seems that way at first glance, but in fact they are strongly
> > > > related. ?There's a reason all three (and nothing else) are exported
> > > > through OpenSSL's EVP API.
> >
> > > > Bill
> >
> > > Don't get me wrong, I like the basic idea you're advancing, and in
> > > use hashes and crypto are frequently seen together,
> >
> > Yes, that's the relationship I was thinking of. ?But from a broader
> > philosophical view, a ciphertext can be thought of as a hash of a
> > plaintext, too. ?A reversible hash.
> 
> You really shouldn't conflate these things. The point of a hash is
> to ensure message integrity, while the point of encryption is to
> preserve secrecy. As an example, ElGamal is a common cryptosystem
> that nevertheless preserves the multiplicative homomorphism..., ie,

I know lots of non-crypto users -- the people the "batteries included"
aspect of Python are for -- that don't understand the fine points of
this, and don't want to.  They just want to encrypt some text with a
"good" cipher scheme, and they depend on the library implementor to know
how to do that.  They want a function "encrypt(plaintext, key)", and
don't really want to know more than that.

And, by the by, hashes are often used for purposes other than message
integrity, outside the sphere of crypto.

> > > IMO, adding public key crypto routines to hashlib seems almost
> > > guaranteed to increase that confusion.
> >
> > Well, that could be. ?Perhaps the packaging "insight" I had wasn't
> > inspired :-). ?I was thinking that from the crypto-ignorant point of
> > view, they seem quite similar. ?A SHA256 hash can be seen as a digital
> > "signature" (or I've heard it called a "fingerprint") of a sequence of
> > bytes, just as with a public-key signature. ?Sure, what's going on is
> > different, but from a utility point of view, it's much the same. ?This
> > is why people post md5 checksums of downloadable packages -- it's a
> > signature.
> 
> Also a very bad idea. Hashes ensure data integrity, not that it came
> from the person that you think it came from. As an example, if I took

Sure.  And lots of people use digital signatures in that way, too.

Again, I wasn't proposing to replace m2cryto or pycrypto or anything
else; I was suggesting that providing easy-to-use APIs to a couple of
commonly-requested crypto features, for use by non-cryptographers,
wouldn't be a bad idea.

Bill


From robert.kern at gmail.com  Mon Sep 21 23:46:14 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 21 Sep 2009 16:46:14 -0500
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <28161.1253569055@parc.com>
References: <7922.1253233496@parc.com>	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>	<20862.1253466431@parc.com>	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>	<19693.1253547829@parc.com>	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com>
Message-ID: <h98s78$ebk$1@ger.gmane.org>

On 2009-09-21 16:37 PM, Bill Janssen wrote:

> Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> else; I was suggesting that providing easy-to-use APIs to a couple of
> commonly-requested crypto features, for use by non-cryptographers,
> wouldn't be a bad idea.

Going back to CTO's original reply, I would say that he agrees with you. Where 
he (and I, for that matter) diverge is that we don't think they should go into 
hashlib. The name is inappropriate and misleading. The unifying concept among 
the functionality you want to include is not "hashing" but "cryptography", and 
the module that ties together that functionality should be named appropriately.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From ncoghlan at gmail.com  Tue Sep 22 00:05:33 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Sep 2009 08:05:33 +1000
Subject: [Python-ideas] adding digital signature and encryption "hashes"
 to hashlib?
In-Reply-To: <28161.1253569055@parc.com>
References: <7922.1253233496@parc.com>	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>	<20862.1253466431@parc.com>	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>	<19693.1253547829@parc.com>	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com>
Message-ID: <4AB7F8AD.7070403@gmail.com>

Bill Janssen wrote:
> Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> else; I was suggesting that providing easy-to-use APIs to a couple of
> commonly-requested crypto features, for use by non-cryptographers,
> wouldn't be a bad idea.

Actually, it could be a really bad idea that leads to people thinking
they have secured something when they have in fact done nothing of the sort.

Having to go find a crypto library at least means a developer has put in
a minimal amount of thought.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From steve at pearwood.info  Tue Sep 22 01:18:54 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 22 Sep 2009 09:18:54 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4AB785ED.7000106@mrabarnett.plus.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<B6D845F6-1746-4F23-9CD3-F8F1F5359A27@masklinn.net>
	<4AB785ED.7000106@mrabarnett.plus.com>
Message-ID: <200909220918.55558.steve@pearwood.info>

On Mon, 21 Sep 2009 11:55:57 pm MRAB wrote:
> I know of one language which is weakly typed: BCPL. It's only type is
> the bit pattern. It's the function or operator which interprets the
> bits as representing a certain value.

That would make BCPL an untyped language, like assembly. If the language 
has no types, it can't be either weakly or strongly typed.

Weak and string typing is a matter of degree. Most languages are weakly 
typed to some extent, for instance Python will automatically coerce 
various number types so you can add integers to floats etc., as will 
Pascal. Numeric coercion is so widespread that most people consider it 
an exception to weak typing: if all the language coerces are numeric 
types, then it's still strongly typed.

The classic test for weak typing versus strong typing is operations on 
mixed integers and strings. Can you add or concatenate strings to 
integers without an explicit conversion? Perl is weakly typed:

$ perl -e 'print "2"+2; print "\n";'
4
$ perl -e 'print "2".2; print "\n";'
22

PHP and (I think) Javascript will do the same.

It's been some years since I've used it, but I recall Apple's Hypertalk 
behaved similarly. I think you could say 2&"2" (returns "22") and 2+"2" 
(returns 4). Hypertalk is no longer supported, but I expect Apple's 
current generation scripting language, AppleScript, would probably be 
the same.



-- 
Steven D'Aprano


From python at mrabarnett.plus.com  Tue Sep 22 01:57:47 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 22 Sep 2009 00:57:47 +0100
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909220918.55558.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<B6D845F6-1746-4F23-9CD3-F8F1F5359A27@masklinn.net>	<4AB785ED.7000106@mrabarnett.plus.com>
	<200909220918.55558.steve@pearwood.info>
Message-ID: <4AB812FB.3060400@mrabarnett.plus.com>

Steven D'Aprano wrote:
> On Mon, 21 Sep 2009 11:55:57 pm MRAB wrote:
>> I know of one language which is weakly typed: BCPL. It's only type is
>> the bit pattern. It's the function or operator which interprets the
>> bits as representing a certain value.
> 
> That would make BCPL an untyped language, like assembly. If the language 
> has no types, it can't be either weakly or strongly typed.
> 
> Weak and string typing is a matter of degree. Most languages are weakly 
> typed to some extent, for instance Python will automatically coerce 
> various number types so you can add integers to floats etc., as will 
> Pascal. Numeric coercion is so widespread that most people consider it 
> an exception to weak typing: if all the language coerces are numeric 
> types, then it's still strongly typed.
> 
> The classic test for weak typing versus strong typing is operations on 
> mixed integers and strings. Can you add or concatenate strings to 
> integers without an explicit conversion? Perl is weakly typed:
> 
> $ perl -e 'print "2"+2; print "\n";'
> 4
> $ perl -e 'print "2".2; print "\n";'
> 22
> 
> PHP and (I think) Javascript will do the same.
> 
> It's been some years since I've used it, but I recall Apple's Hypertalk 
> behaved similarly. I think you could say 2&"2" (returns "22") and 2+"2" 
> (returns 4). Hypertalk is no longer supported, but I expect Apple's 
> current generation scripting language, AppleScript, would probably be 
> the same.
> 
I read that someone re-wrote a Perl script in Python and found that a
process that it called sometimes returned "ERROR" instead of a numeric
string, which Perl would just coerce to 0, thus hiding the error!

The Icon language also performs automatic coercion, but invalid strings
cause a runtime error (unfortunately the language doesn't support
catchable exceptions, or at least didn't in the last version I know of).
Icon also shows the disadvantage of automatic coercions: there's an
operator for addition, one for string concatenation, and one for list
concatenation. If you wanted to add sets (not just charsets), you'd need
yet another operator. In Python you can just reuse them and let the
classes decide what they do! :-)


From fuzzyman at gmail.com  Tue Sep 22 02:04:53 2009
From: fuzzyman at gmail.com (Michael)
Date: Tue, 22 Sep 2009 01:04:53 +0100
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909220918.55558.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<B6D845F6-1746-4F23-9CD3-F8F1F5359A27@masklinn.net>
	<4AB785ED.7000106@mrabarnett.plus.com>
	<200909220918.55558.steve@pearwood.info>
Message-ID: <26A90646-38B4-4235-9493-5DA4EF8C7FCB@gmail.com>

Unfortunately Excel, probably the most widely used end-user  
programming environment in the world, allows you to both concatenate  
(&) and add strings and numbers.

Interestingly the formula language is also a functional programming  
language (expressions only) where control flow is determined by  
dependencies between expressions.

Michael


--
http://www.ironpythoninaction.com

On 22 Sep 2009, at 00:18, Steven D'Aprano <steve at pearwood.info> wrote:

> On Mon, 21 Sep 2009 11:55:57 pm MRAB wrote:
>> I know of one language which is weakly typed: BCPL. It's only type is
>> the bit pattern. It's the function or operator which interprets the
>> bits as representing a certain value.
>
> That would make BCPL an untyped language, like assembly. If the  
> language
> has no types, it can't be either weakly or strongly typed.
>
> Weak and string typing is a matter of degree. Most languages are  
> weakly
> typed to some extent, for instance Python will automatically coerce
> various number types so you can add integers to floats etc., as will
> Pascal. Numeric coercion is so widespread that most people consider it
> an exception to weak typing: if all the language coerces are numeric
> types, then it's still strongly typed.
>
> The classic test for weak typing versus strong typing is operations on
> mixed integers and strings. Can you add or concatenate strings to
> integers without an explicit conversion? Perl is weakly typed:
>
> $ perl -e 'print "2"+2; print "\n";'
> 4
> $ perl -e 'print "2".2; print "\n";'
> 22
>
> PHP and (I think) Javascript will do the same.
>
> It's been some years since I've used it, but I recall Apple's  
> Hypertalk
> behaved similarly. I think you could say 2&"2" (returns "22") and  
> 2+"2"
> (returns 4). Hypertalk is no longer supported, but I expect Apple's
> current generation scripting language, AppleScript, would probably be
> the same.
>
>
>
> -- 
> Steven D'Aprano
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas


From steve at pearwood.info  Tue Sep 22 02:19:51 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 22 Sep 2009 10:19:51 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909191733k5bf9f023x1cf30b7cec26634e@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909201000.34945.steve@pearwood.info>
	<e9764b730909191733k5bf9f023x1cf30b7cec26634e@mail.gmail.com>
Message-ID: <200909221019.51549.steve@pearwood.info>

On Sun, 20 Sep 2009 10:33:55 am Dj Gilcrease wrote:
> On Sat, Sep 19, 2009 at 6:00 PM, Steven D'Aprano <steve at pearwood.info> 
wrote:
> > You ignored most of my questions. I'll *guess* what your intention
> > is.
> >
> > You want the compiler to perform declarative type checking at
> > compile time, with no type inference. You're proposing a syntax to
> > declare types, with no implementation at all for how the compiler
> > should actually do that checking.
> >
> > (I'm guessing compile time because you call it *static* ducks, even
> > though you state it should raise TypeError. But you never actually
> > say whether that will be raised when the compiler compiles the
> > code, or when it runs it.)
>
> Actually I would say it does it at run time because of the
> requirement that it work along side code that does not use this, both
> being imported to and importing non static ducked code. In the case
> it imports code that is not using static ducks it would have to check
> anything you pass in to a method that is typed or assigned to an
> attribute that is.

I think you're unsure or confused about the different kinds of type 
systems. I don't think it makes sense to talk about static type checks 
happening at runtime -- static typing implies that the type of every 
variable is known at compile time. That's impossible in Python, 
although of course other languages (like Boo) can have static types 
with a Python-like syntax.

You should read:
http://en.wikipedia.org/wiki/Type_system
http://www.pphsg.org/cdsmith/types.html


It sounds like what you want is a framework for hiding the complexity of 
runtime type checkers from the developer. I don't think there's any 
need for new syntax beyond decorators and the type annotations added to 
Python 3. Type annotations give you a way of declaring types of 
arguments and return results. Although such declarations are currently 
ignored by Python, you can write code to enforce them, and decorators 
give you a neat syntax for applying that code to your functions without 
having to explicitly include the type checks inside the function body. 
You can also do the same with metaclasses.

You might also be interested in the concept of pre- and post-conditions, 
taken from Eiffel (and probably other languages as well). Guido van 
Rossum has given some example metaclasses to perform such Eiffel 
condition checks:

http://www.python.org/doc/essays/metaclasses/
(See the "Real-life Examples" section.)


If you haven't already read these, you should:

http://www.artima.com/weblogs/viewpost.jsp?thread=85551
http://www.artima.com/weblogs/viewpost.jsp?thread=86641
http://www.artima.com/weblogs/viewpost.jsp?thread=87182



-- 
Steven D'Aprano


From janssen at parc.com  Tue Sep 22 02:23:26 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 21 Sep 2009 17:23:26 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <4AB7F8AD.7070403@gmail.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <4AB7F8AD.7070403@gmail.com>
Message-ID: <29978.1253579006@parc.com>

Nick Coghlan <ncoghlan at gmail.com> wrote:

> Bill Janssen wrote:
> > Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> > else; I was suggesting that providing easy-to-use APIs to a couple of
> > commonly-requested crypto features, for use by non-cryptographers,
> > wouldn't be a bad idea.
> 
> Actually, it could be a really bad idea that leads to people thinking
> they have secured something when they have in fact done nothing of the sort.

I don't think so.  People make mistakes continually.  Part of life.
Making it easier to do things leads to that sort of misunderstanding.

That being said, are there ways to make things more foolproof?

> Having to go find a crypto library at least means a developer has put in
> a minimal amount of thought.

Too much, IMO.

Bill


From debatem1 at gmail.com  Tue Sep 22 03:37:34 2009
From: debatem1 at gmail.com (CTO)
Date: Mon, 21 Sep 2009 18:37:34 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <28161.1253569055@parc.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com>
Message-ID: <47b7d858-6a35-40a7-a0dd-946009be7419@f10g2000vbf.googlegroups.com>



On Sep 21, 5:37?pm, Bill Janssen <jans... at parc.com> wrote:
> CTO <debat... at gmail.com> wrote:
> > On Sep 21, 11:43?am, Bill Janssen <jans... at parc.com> wrote:
> > > CTO <debat... at gmail.com> wrote:
> > > > > I know it seems that way at first glance, but in fact they are strongly
> > > > > related. ?There's a reason all three (and nothing else) are exported
> > > > > through OpenSSL's EVP API.
>
> > > > > Bill
>
> > > > Don't get me wrong, I like the basic idea you're advancing, and in
> > > > use hashes and crypto are frequently seen together,
>
> > > Yes, that's the relationship I was thinking of. ?But from a broader
> > > philosophical view, a ciphertext can be thought of as a hash of a
> > > plaintext, too. ?A reversible hash.
>
> > You really shouldn't conflate these things. The point of a hash is
> > to ensure message integrity, while the point of encryption is to
> > preserve secrecy. As an example, ElGamal is a common cryptosystem
> > that nevertheless preserves the multiplicative homomorphism..., ie,
>
> I know lots of non-crypto users -- the people the "batteries included"
> aspect of Python are for -- that don't understand the fine points of
> this, and don't want to. ?They just want to encrypt some text with a
> "good" cipher scheme, and they depend on the library implementor to know
> how to do that. ?They want a function "encrypt(plaintext, key)", and
> don't really want to know more than that.
>

Crypto is complex for a reason. I didn't point those examples out
because they were exceptions to the rule, I pointed them out because
in crypto the rule is that your ignorance will burn you in the end.
Trying to make it easier to do security badly is not a goal I'd set
for the standard library.

> And, by the by, hashes are often used for purposes other than message
> integrity, outside the sphere of crypto.

Cryptographic hashes were designed to be used in cryptography. Any
other use should be well-researched before being deployed. Bad
commmon practices aren't less bad for being more common.

> > > > IMO, adding public key crypto routines to hashlib seems almost
> > > > guaranteed to increase that confusion.
>
> > > Well, that could be. ?Perhaps the packaging "insight" I had wasn't
> > > inspired :-). ?I was thinking that from the crypto-ignorant point of
> > > view, they seem quite similar. ?A SHA256 hash can be seen as a digital
> > > "signature" (or I've heard it called a "fingerprint") of a sequence of
> > > bytes, just as with a public-key signature. ?Sure, what's going on is
> > > different, but from a utility point of view, it's much the same. ?This
> > > is why people post md5 checksums of downloadable packages -- it's a
> > > signature.
>
> > Also a very bad idea. Hashes ensure data integrity, not that it came
> > from the person that you think it came from. As an example, if I took
>
> Sure. ?And lots of people use digital signatures in that way, too.

See the above about "bad practice".

> Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> else; I was suggesting that providing easy-to-use APIs to a couple of
> commonly-requested crypto features, for use by non-cryptographers,
> wouldn't be a bad idea.
>
> Bill
> _______________________________________________
> Python-ideas mailing list
> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas


From janssen at parc.com  Tue Sep 22 03:37:33 2009
From: janssen at parc.com (Bill Janssen)
Date: Mon, 21 Sep 2009 18:37:33 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <h98s78$ebk$1@ger.gmane.org>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <h98s78$ebk$1@ger.gmane.org>
Message-ID: <30736.1253583453@parc.com>

Robert Kern <robert.kern at gmail.com> wrote:

> On 2009-09-21 16:37 PM, Bill Janssen wrote:
> 
> > Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> > else; I was suggesting that providing easy-to-use APIs to a couple of
> > commonly-requested crypto features, for use by non-cryptographers,
> > wouldn't be a bad idea.
> 
> Going back to CTO's original reply, I would say that he agrees with
> you. Where he (and I, for that matter) diverge is that we don't think
> they should go into hashlib. The name is inappropriate and
> misleading.

OK, so let's not do that, then.  Greg commented that the underlying C
implementation of access to EVP can be shared, which eliminates the only
real functional justification for adding it to hashlib, which is to
avoid duplicating code.

Suppose we added, then, a simple-minded API to the EVP functions:

  EVP_Seal... and EVP_Open... provide public key encryption
  EVP_Sign... and EVP_Verify... provide digital signatures
  EVP_Encrypt and EVP_Decrypt provide symmetric key encryption

(The EVP_Digest... API is already brought out by hashlib.)

Let's call this new module "evp".  (Or perhaps there should be a
"crypto" package, with "hashes", "encryption", and "signature"
submodules.)

Let's look at symmetric encryption.  You'd want to be able to create a
new encryptor:

  import evp
  e = evp.encryptor(key, cipher="AES256", padding=True)

"cipher" defaults to AES256, the constructor raises an exception if that
isn't available (or the specified cipher isn't available), or for a bad
key (wrong length).

  e.update(plaintext)           # repeat as needed
  ciphertext = e.result()

Very similar for decryption.

What can be done to make something like this foolproof?

Bill


From grosser.meister.morti at gmx.net  Tue Sep 22 05:05:41 2009
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Tue, 22 Sep 2009 05:05:41 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909220918.55558.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<B6D845F6-1746-4F23-9CD3-F8F1F5359A27@masklinn.net>	<4AB785ED.7000106@mrabarnett.plus.com>
	<200909220918.55558.steve@pearwood.info>
Message-ID: <4AB83F05.1030702@gmx.net>

On 09/22/2009 01:18 AM, Steven D'Aprano wrote:
> On Mon, 21 Sep 2009 11:55:57 pm MRAB wrote:
>> I know of one language which is weakly typed: BCPL. It's only type is
>> the bit pattern. It's the function or operator which interprets the
>> bits as representing a certain value.
> 
> That would make BCPL an untyped language, like assembly. If the language 
> has no types, it can't be either weakly or strongly typed.
> 
> Weak and string typing is a matter of degree. Most languages are weakly 
> typed to some extent, for instance Python will automatically coerce 
> various number types so you can add integers to floats etc., as will 
> Pascal. Numeric coercion is so widespread that most people consider it 
> an exception to weak typing: if all the language coerces are numeric 
> types, then it's still strongly typed.
> 
> The classic test for weak typing versus strong typing is operations on 
> mixed integers and strings. Can you add or concatenate strings to 
> integers without an explicit conversion? Perl is weakly typed:
> 
> $ perl -e 'print "2"+2; print "\n";'
> 4
> $ perl -e 'print "2".2; print "\n";'
> 22
> 

Written from memory, C++:

#include <string>
#include <cstdio>

int operator + (const std::string& lhs, int rhs) {
	int i = 0;
	std::sscanf(lhs.c_str(), "%d", &i);
	return i + rhs;
}

int main() {
	std::string s = "2";
	std::printf("%d\n", s + 2);
	return 0;
}

Prints:
4

I don't think this is a valid test to determine how a language is typed. Ok, C++
is more or less weakly typed (for other reasons), but I think you could write
something similar in C#, too. And C# is strongly typed.

> PHP and (I think) Javascript will do the same.
> 
> It's been some years since I've used it, but I recall Apple's Hypertalk 
> behaved similarly. I think you could say 2&"2" (returns "22") and 2+"2" 
> (returns 4). Hypertalk is no longer supported, but I expect Apple's 
> current generation scripting language, AppleScript, would probably be 
> the same.
> 
> 
> 



From digitalxero at gmail.com  Tue Sep 22 13:18:28 2009
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Tue, 22 Sep 2009 05:18:28 -0600
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909221019.51549.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909201000.34945.steve@pearwood.info>
	<e9764b730909191733k5bf9f023x1cf30b7cec26634e@mail.gmail.com>
	<200909221019.51549.steve@pearwood.info>
Message-ID: <e9764b730909220418v3e2bcb2ch92975252145ef3aa@mail.gmail.com>

On Mon, Sep 21, 2009 at 6:19 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> It sounds like what you want is a framework for hiding the complexity of
> runtime type checkers from the developer. I don't think there's any
> need for new syntax beyond decorators and the type annotations added to
> Python 3. Type annotations give you a way of declaring types of
> arguments and return results. Although such declarations are currently
> ignored by Python, you can write code to enforce them, and decorators
> give you a neat syntax for applying that code to your functions without
> having to explicitly include the type checks inside the function body.
> You can also do the same with metaclasses.

Ya but decorators, metaclasses and annotations dont address class
attributes, or module level variables, which you should be able to
type check on assignment, but you need to do it on use.


From steve at pearwood.info  Tue Sep 22 15:16:16 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Tue, 22 Sep 2009 23:16:16 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4AB83F05.1030702@gmx.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909220918.55558.steve@pearwood.info> <4AB83F05.1030702@gmx.net>
Message-ID: <200909222316.17285.steve@pearwood.info>

On Tue, 22 Sep 2009 01:05:41 pm Mathias Panzenb?ck wrote:

> I don't think this is a valid test to determine how a language is
> typed. Ok, C++ is more or less weakly typed (for other reasons), but
> I think you could write something similar in C#, too. And C# is
> strongly typed.

Weak and strong typing are a matter of degree -- there's no definitive 
test for "weak" vs "strong" typing, only degrees of weakness. The 
classic test is whether you can add strings and ints together, but of 
course that's only one possible test out of many. I can imagine a 
language which requires explicit conversions between ints and strings, 
while implicitly converting or casting nearly every other data type!

According to Wikipedia, C# is strongly typed. The only implicit 
conversions are "safe" conversions, such as widening integer types 
(e.g. convert 32-bit ints into 64-bit ints, but not the other way), and 
some implicit conversions between derived types and their base types. 
The rules are relaxed a little for the int literal 0. I assume that, 
like most languages, it allows mixed int/float arithmetic.

This is quite similar to Python, which also implicitly widens ints to 
long ints. Arguably Python is weaker than C#, as Python accepts any 
object in truth concepts, while C# requires an actual bool type.

I'd be surprised if C# implicitly converts strings to ints, but if it 
did, that would be a good example showing that the strength of the type 
system is not a one dimensional quantity.



-- 
Steven D'Aprano


From masklinn at masklinn.net  Tue Sep 22 16:25:32 2009
From: masklinn at masklinn.net (Masklinn)
Date: Tue, 22 Sep 2009 16:25:32 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909222316.17285.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909220918.55558.steve@pearwood.info> <4AB83F05.1030702@gmx.net>
	<200909222316.17285.steve@pearwood.info>
Message-ID: <3BCBFD56-64B1-4D0A-90B4-39CDEC1C5D1C@masklinn.net>

On 22 Sep 2009, at 15:16 , Steven D'Aprano wrote:
> On Tue, 22 Sep 2009 01:05:41 pm Mathias Panzenb?ck wrote:
>
>> I don't think this is a valid test to determine how a language is
>> typed. Ok, C++ is more or less weakly typed (for other reasons), but
>> I think you could write something similar in C#, too. And C# is
>> strongly typed.
>
> Weak and strong typing are a matter of degree -- there's no definitive
> test for "weak" vs "strong" typing, only degrees of weakness. The
> classic test is whether you can add strings and ints together, but of
> course that's only one possible test out of many.
And it's a pretty bad one to boot: both Java and C# allow adding  
strings and ints (whether it's `3 + "5"` or `"5" + 3`) (in fact they  
allow adding *anything* to a string), but the operation is well  
defined: convert any non-string involved to a string (via #toString 
()/.ToString()) and concatenate.

> According to Wikipedia, C# is strongly typed. The only implicit
> conversions are "safe" conversions, such as widening integer types
> (e.g. convert 32-bit ints into 64-bit ints, but not the other way),  
> and
> some implicit conversions between derived types and their base types.
> The rules are relaxed a little for the int literal 0. I assume that,
> like most languages, it allows mixed int/float arithmetic.
>
See above: C#, much like Java, also allows concatenating anything to  
strings, and implicitly convert non-strings to strings.



From steve at pearwood.info  Tue Sep 22 17:46:20 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 23 Sep 2009 01:46:20 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <3BCBFD56-64B1-4D0A-90B4-39CDEC1C5D1C@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909222316.17285.steve@pearwood.info>
	<3BCBFD56-64B1-4D0A-90B4-39CDEC1C5D1C@masklinn.net>
Message-ID: <200909230146.21497.steve@pearwood.info>

On Wed, 23 Sep 2009 12:25:32 am Masklinn wrote:
> On 22 Sep 2009, at 15:16 , Steven D'Aprano wrote:
> > On Tue, 22 Sep 2009 01:05:41 pm Mathias Panzenb?ck wrote:
> >> I don't think this is a valid test to determine how a language is
> >> typed. Ok, C++ is more or less weakly typed (for other reasons),
> >> but I think you could write something similar in C#, too. And C#
> >> is strongly typed.
> >
> > Weak and strong typing are a matter of degree -- there's no
> > definitive test for "weak" vs "strong" typing, only degrees of
> > weakness. The classic test is whether you can add strings and ints
> > together, but of course that's only one possible test out of many.
>
> And it's a pretty bad one to boot: both Java and C# allow adding
> strings and ints (whether it's `3 + "5"` or `"5" + 3`) (in fact they
> allow adding *anything* to a string), but the operation is well
> defined: convert any non-string involved to a string (via #toString
> ()/.ToString()) and concatenate.

I don't see why you say it's a bad test. To me, it's a good test, and 
Java and C# pass it.

If you're only criterion is that an operation is well-defined, 
then "weak typing" becomes meaningless: I could define addition of 
dicts and strings to be the sum of the length of the dict with the 
number of hyphens in the string, and declare that 

{'foo':'a', 'bar':'b'} + "12-34-56-78-90"

returns 6, and by your criterion my language would be strongly typed. I 
think that makes a mockery of the whole concept.


[...]
> See above: C#, much like Java, also allows concatenating anything to
> strings, and implicitly convert non-strings to strings.

Which hints that (at least when it comes to strings) C# and Java are 
weakly typed and that people consider them "strongly typed" is a 
triumph of marketing over reality.

For any typed language, you ask how the language deals with operations 
on mixed types. If you have to explicitly convert the values to a 
common type, the language is strongly typed. If the language implicitly 
does the conversion for you, it is weakly typed. If, as is usually the 
case, the language does some conversions automatically, and others 
requires you to do explicitly, then the language combines some strong 
typing with some weak typing, and it becomes a matter of degree whether 
you call it strongly or weakly typed. If we insist in sticking every 
language in a binary state of "weak" or "strong", then we need a 
heuristic to decide. The heuristic in common use is to allow implicit 
numeric coercions in strongly typed languages, but usually not to allow 
implicit string to int conversions.

This heuristic is not arbitrary. Automatically converting ints to floats 
is mathematically reasonable, because we consider e.g. 3 and 3.0 to be 
the same number. But automatically converting strings to ints is 
somewhat dubious. Although the intent of "1"+1 may be obvious, what is 
the intent of "foo"+1? Should "foo" convert to 0, or should "foo" be 
treated equivalent to a 24-bit integer, or what? There's no objective 
reason for preferring one behaviour over another. The same applies 
for "1"&123 -- should we treat the int 123 as the string "123", or the 
string "\01\02\03", or what? Of course a language designer is free to 
arbitrarily choose one behaviour over the other, but that is weak 
typing.

"Strong typing" carries connotations of strength and security, and "weak 
typing" sounds soft and risky, but neither of these are necessarily 
correct. Perl is weakly typed but it's very hard to cause it to crash, 
while C++ is strongly typed but easy to cause it to core-dump. Neither 
strategy is objectively better than the other in *all* cases, although 
in my opinion strong typing is probably *usually* better.


-- 
Steven D'Aprano


From masklinn at masklinn.net  Tue Sep 22 18:35:49 2009
From: masklinn at masklinn.net (Masklinn)
Date: Tue, 22 Sep 2009 18:35:49 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909230146.21497.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909222316.17285.steve@pearwood.info>
	<3BCBFD56-64B1-4D0A-90B4-39CDEC1C5D1C@masklinn.net>
	<200909230146.21497.steve@pearwood.info>
Message-ID: <DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>

On 22 Sep 2009, at 17:46 , Steven D'Aprano wrote:
> On Wed, 23 Sep 2009 12:25:32 am Masklinn wrote:
>> On 22 Sep 2009, at 15:16 , Steven D'Aprano wrote:
>>> On Tue, 22 Sep 2009 01:05:41 pm Mathias Panzenb?ck wrote:
>>>> I don't think this is a valid test to determine how a language is
>>>> typed. Ok, C++ is more or less weakly typed (for other reasons),
>>>> but I think you could write something similar in C#, too. And C#
>>>> is strongly typed.
>>>
>>> Weak and strong typing are a matter of degree -- there's no
>>> definitive test for "weak" vs "strong" typing, only degrees of
>>> weakness. The classic test is whether you can add strings and ints
>>> together, but of course that's only one possible test out of many.
>>
>> And it's a pretty bad one to boot: both Java and C# allow adding
>> strings and ints (whether it's `3 + "5"` or `"5" + 3`) (in fact they
>> allow adding *anything* to a string), but the operation is well
>> defined: convert any non-string involved to a string (via #toString
>> ()/.ToString()) and concatenate.
>
> I don't see why you say it's a bad test. To me, it's a good test, and
> Java and C# pass it.
>
Uh no, by your criterion they fail it: both java and C# do add strings  
and integers without peeping.

> If you're only criterion is that an operation is well-defined,
> then "weak typing" becomes meaningless: I could define addition of
> dicts and strings to be the sum of the length of the dict with the
> number of hyphens in the string, and declare that
>
> {'foo':'a', 'bar':'b'} + "12-34-56-78-90"
>
> returns 6, and by your criterion my language would be strongly  
> typed. I
> think that makes a mockery of the whole concept.
I don't think I defined any criterion of strong/weak typing. As far as  
I'm concerned, and as I've already mentioned in this thread, the whole  
weak/strong axis is meaningless and laughable.

> This heuristic is not arbitrary.
Of course it is.

> Automatically converting ints to floats
> is mathematically reasonable, because we consider e.g. 3 and 3.0 to be
> the same number.
Do we? Given 3/2 and 3.0/2 don't necessarily give the same answer  
(some languages don't even consider the first operation valid), I'm  
not sure we do.

> Perl is weakly typed but it's very hard to cause it to crash,
See the link I previously gave, you might consider Perl weakly typed,  
not everybody does.

> while C++ is strongly typed but easy to cause it to core-dump.
See my response to your previous declaration.



From debatem1 at gmail.com  Tue Sep 22 18:44:07 2009
From: debatem1 at gmail.com (CTO)
Date: Tue, 22 Sep 2009 09:44:07 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <30736.1253583453@parc.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <h98s78$ebk$1@ger.gmane.org>
	<30736.1253583453@parc.com>
Message-ID: <b51c01bc-d1d3-4346-8466-5d396a1bdc3f@l34g2000vba.googlegroups.com>



On Sep 21, 9:37?pm, Bill Janssen <jans... at parc.com> wrote:
> Robert Kern <robert.k... at gmail.com> wrote:
> > On 2009-09-21 16:37 PM, Bill Janssen wrote:
>
> > > Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> > > else; I was suggesting that providing easy-to-use APIs to a couple of
> > > commonly-requested crypto features, for use by non-cryptographers,
> > > wouldn't be a bad idea.
>
> > Going back to CTO's original reply, I would say that he agrees with
> > you. Where he (and I, for that matter) diverge is that we don't think
> > they should go into hashlib. The name is inappropriate and
> > misleading.
>
> OK, so let's not do that, then. ?Greg commented that the underlying C
> implementation of access to EVP can be shared, which eliminates the only
> real functional justification for adding it to hashlib, which is to
> avoid duplicating code.
>

Seems reasonable.

> Suppose we added, then, a simple-minded API to the EVP functions:
>
> ? EVP_Seal... and EVP_Open... provide public key encryption
> ? EVP_Sign... and EVP_Verify... provide digital signatures
> ? EVP_Encrypt and EVP_Decrypt provide symmetric key encryption
>
> (The EVP_Digest... API is already brought out by hashlib.)

Since we're doing the rest of it, we might as well do the
EVP_PKEY stuff too.

> Let's call this new module "evp".

Not a big fan of that, although as long as everything in it
is clearly marked as to what its purpose and limitations are,
I don't really care about the name...

> (Or perhaps there should be a
> "crypto" package, with "hashes", "encryption", and "signature"
> submodules.)

...except that it probably shouldn't conflict with existing
third-party modules, and Crypto is already in use. I'll send
an email and see if there are any plans to change the
capitalization on that.

> Let's look at symmetric encryption. ?You'd want to be able to create a
> new encryptor:
>
> ? import evp
> ? e = evp.encryptor(key, cipher="AES256", padding=True)
>
> "cipher" defaults to AES256, the constructor raises an exception if that
> isn't available (or the specified cipher isn't available), or for a bad
> key (wrong length).

I'm personally against the idea of default ciphers, etc.
Since difference ciphers, keylengths, and padding choices
have immediate consequences for what kinds of security
you're going to have, I would rather be explicit than
implicit here.

> ? e.update(plaintext) ? ? ? ? ? # repeat as needed
> ? ciphertext = e.result()
>
> Very similar for decryption.

Most ciphers are not stream ciphers, so it doesn't make a lot of
sense in the case of, say, RSA or AES, but again- bikeshedding.

> What can be done to make something like this foolproof?

Not a whole lot, but, that's kind of the way security works.

Geremy Condra


From janssen at parc.com  Tue Sep 22 19:00:04 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 22 Sep 2009 10:00:04 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <b51c01bc-d1d3-4346-8466-5d396a1bdc3f@l34g2000vba.googlegroups.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <h98s78$ebk$1@ger.gmane.org>
	<30736.1253583453@parc.com>
	<b51c01bc-d1d3-4346-8466-5d396a1bdc3f@l34g2000vba.googlegroups.com>
Message-ID: <31704.1253638804@parc.com>

CTO <debatem1 at gmail.com> wrote:

> > Let's look at symmetric encryption. ?You'd want to be able to create a
> > new encryptor:
> >
> > ? import evp
> > ? e = evp.encryptor(key, cipher="AES256", padding=True)
> >
> > "cipher" defaults to AES256, the constructor raises an exception if that
> > isn't available (or the specified cipher isn't available), or for a bad
> > key (wrong length).
>
> I'm personally against the idea of default ciphers, etc.
> Since difference ciphers, keylengths, and padding choices
> have immediate consequences for what kinds of security
> you're going to have, I would rather be explicit than
> implicit here.

Sure, your privilege.

Unfortunately, most users won't be able to make those choices sanely,
and will rely on some sort of external advice about it.  So I think it
makes sense to try to build some such advice into the code, by adding a
reasonably strong encryption standard as a default, and by adding some
code to do sanity/compatibility checks on the user-selected keys, if
possible.

> > ? e.update(plaintext) ? ? ? ? ? # repeat as needed
> > ? ciphertext = e.result()
> >
> > Very similar for decryption.
> 
> Most ciphers are not stream ciphers, so it doesn't make a lot of
> sense in the case of, say, RSA or AES, but again- bikeshedding.

Still, good point.  Multiple calls to update() should raise an exception
if the chosen cipher is not a stream cipher.  Or, allow multiple calls,
and buffer the input until result() is called.

Bill


From ilya.nikokoshev at gmail.com  Tue Sep 22 20:00:44 2009
From: ilya.nikokoshev at gmail.com (ilya)
Date: Tue, 22 Sep 2009 22:00:44 +0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909222316.17285.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909220918.55558.steve@pearwood.info> <4AB83F05.1030702@gmx.net>
	<200909222316.17285.steve@pearwood.info>
Message-ID: <d8cc6f9d0909221100j75b42ad4gae539281c9f4288a@mail.gmail.com>

> Weak and strong typing are a matter of degree -- there's no definitive
> test for "weak" vs "strong" typing, only degrees of weakness. The

Indeed, there certainly different places where language can enforce
types. One of them is operators, but I want to point out other places
as well. Some languages require explicit type in collections.

I believe Pascal and to some extent C#, while certainly not current
Python, fall it the category of languages which require containers to
declare explicit type of elements.

This case is especially relevant to Python, since BFDL considered
adding parametrized types
(http://www.artima.com/weblogs/viewpost.jsp?thread=86641) though later
dropped this idea
(http://www.artima.com/weblogs/viewpost.jsp?thread=86641); others,
e.g. the original poster, often suggest something similar.

I personally continue to be on the side of "strong testing" rather
than "strong typing" -- Bruce Eckel said it better than I could do at
http://mindview.net/WebLog/log-0025.

ilya n.


From debatem1 at gmail.com  Tue Sep 22 21:08:01 2009
From: debatem1 at gmail.com (CTO)
Date: Tue, 22 Sep 2009 12:08:01 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <31704.1253638804@parc.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <h98s78$ebk$1@ger.gmane.org>
	<30736.1253583453@parc.com> 
	<b51c01bc-d1d3-4346-8466-5d396a1bdc3f@l34g2000vba.googlegroups.com> 
	<31704.1253638804@parc.com>
Message-ID: <d4491297-5cf8-443c-8f11-0757b5ca93fc@y20g2000vbk.googlegroups.com>



On Sep 22, 1:00?pm, Bill Janssen <jans... at parc.com> wrote:
> CTO <debat... at gmail.com> wrote:
> > > Let's look at symmetric encryption. ?You'd want to be able to create a
> > > new encryptor:
>
> > > ? import evp
> > > ? e = evp.encryptor(key, cipher="AES256", padding=True)
>
> > > "cipher" defaults to AES256, the constructor raises an exception if that
> > > isn't available (or the specified cipher isn't available), or for a bad
> > > key (wrong length).
>
> > I'm personally against the idea of default ciphers, etc.
> > Since difference ciphers, keylengths, and padding choices
> > have immediate consequences for what kinds of security
> > you're going to have, I would rather be explicit than
> > implicit here.
>
> Sure, your privilege.
>
> Unfortunately, most users won't be able to make those choices sanely,
> and will rely on some sort of external advice about it. ?So I think it
> makes sense to try to build some such advice into the code, by adding a
> reasonably strong encryption standard as a default, and by adding some
> code to do sanity/compatibility checks on the user-selected keys, if
> possible.

If you don't know what the application is, you don't know what's
secure
and what isn't. We have no way of knowing, and so should resist the
temptation to guess.

It's also worth pointing out that hashlib as currently implemented
makes users do exactly this: you have to specify the hash you want,
with no default provided. I've never heard anybody describe that
as an onerous level of difficulty.

> > > ? e.update(plaintext) ? ? ? ? ? # repeat as needed
> > > ? ciphertext = e.result()
>
> > > Very similar for decryption.
>
> > Most ciphers are not stream ciphers, so it doesn't make a lot of
> > sense in the case of, say, RSA or AES, but again- bikeshedding.
>
> Still, good point. ?Multiple calls to update() should raise an exception
> if the chosen cipher is not a stream cipher. ?Or, allow multiple calls,
> and buffer the input until result() is called.

AFAIK, AES and RSA are the most commonly used algorithms in EVP.
Maybe it would make more sense to take the more traditional
keygen-encrypt-decrypt approach?

Geremy Condra


From janssen at parc.com  Tue Sep 22 21:23:21 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 22 Sep 2009 12:23:21 PDT
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <d4491297-5cf8-443c-8f11-0757b5ca93fc@y20g2000vbk.googlegroups.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <h98s78$ebk$1@ger.gmane.org>
	<30736.1253583453@parc.com>
	<b51c01bc-d1d3-4346-8466-5d396a1bdc3f@l34g2000vba.googlegroups.com>
	<31704.1253638804@parc.com>
	<d4491297-5cf8-443c-8f11-0757b5ca93fc@y20g2000vbk.googlegroups.com>
Message-ID: <36201.1253647401@parc.com>

CTO <debatem1 at gmail.com> wrote:

> If you don't know what the application is, you don't know what's
> secure and what isn't. We have no way of knowing, and so should resist
> the temptation to guess.

"secure" is not the same as "strongly encrypted".  I'm looking at
providing a simple way to do encryption here, not security.  Let's just
focus on that, first.  I think defaulting to Blowfish or AES256 would be
a reasonable tack to take there.  I suggested AES256 because it seems
to me more likely to be widely available.

> AFAIK, AES and RSA are the most commonly used algorithms in EVP.
> Maybe it would make more sense to take the more traditional
> keygen-encrypt-decrypt approach?

Sure, maybe so.  What would a proposed interface look like, then?

Bill


From steve at pearwood.info  Tue Sep 22 22:17:04 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 23 Sep 2009 06:17:04 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
Message-ID: <200909230617.04840.steve@pearwood.info>

On Wed, 23 Sep 2009 02:35:49 am Masklinn wrote:
> On 22 Sep 2009, at 17:46 , Steven D'Aprano wrote:
> > On Wed, 23 Sep 2009 12:25:32 am Masklinn wrote:
> >> On 22 Sep 2009, at 15:16 , Steven D'Aprano wrote:
> >>> On Tue, 22 Sep 2009 01:05:41 pm Mathias Panzenb?ck wrote:
> >>>> I don't think this is a valid test to determine how a language
> >>>> is typed. Ok, C++ is more or less weakly typed (for other
> >>>> reasons), but I think you could write something similar in C#,
> >>>> too. And C# is strongly typed.
> >>>
> >>> Weak and strong typing are a matter of degree -- there's no
> >>> definitive test for "weak" vs "strong" typing, only degrees of
> >>> weakness. The classic test is whether you can add strings and
> >>> ints together, but of course that's only one possible test out of
> >>> many.
> >>
> >> And it's a pretty bad one to boot: both Java and C# allow adding
> >> strings and ints (whether it's `3 + "5"` or `"5" + 3`) (in fact
> >> they allow adding *anything* to a string), but the operation is
> >> well defined: convert any non-string involved to a string (via
> >> #toString ()/.ToString()) and concatenate.
> >
> > I don't see why you say it's a bad test. To me, it's a good test,
> > and Java and C# pass it.
>
> Uh no, by your criterion they fail it: both java and C# do add
> strings and integers without peeping.

What are you talking about? Using Python syntax, we might write:

assert "2"+2 == 4

This test will FAIL for Python, Pascal and other strongly typed 
languages, and PASS for weakly typed languages. (For some languages, 
like Pascal, you can't even compile the test!)


> > If you're only criterion is that an operation is well-defined,
> > then "weak typing" becomes meaningless...
>
> I don't think I defined any criterion of strong/weak typing. 

You conceded that C# adds strings and ints, but disputed that this fact 
makes C# weakly typed on the basis that (I quote) "the operation is 
well defined". There's nothing about the definition of weakly typed 
languages that requires the implicit conversions to be random, 
arbitrary or badly defined, ONLY that they are implicit, and by that 
definition, C# is weakly typed with regard to strings+ints.

> As far 
> as I'm concerned, and as I've already mentioned in this thread, the
> whole weak/strong axis is meaningless and laughable.

I agree that treating weak/strong as a binary state is an 
over-simplification, but a weak/strong axis is perfectly reasonable. 
Count the number of possible mixed-type operations permitted by the 
language (for simplicity, limit it to built-in or fundamental types).
What percentage of them succeed without explicit casts or conversions?
If that percentage is 0%, then the language is entirely strong. If it is 
100%, then the language is entirely weak. In practice, languages will 
likely fall somewhere in the middle rather at the ends. This is an 
objective test for degree of type strength.


> > This heuristic is not arbitrary.
>
> Of course it is.

Now you're just being irrational.


> > Automatically converting ints to floats
> > is mathematically reasonable, because we consider e.g. 3 and 3.0 to
> > be the same number.
>
> Do we? Given 3/2 and 3.0/2 don't necessarily give the same answer
> (some languages don't even consider the first operation valid), I'm
> not sure we do.

Ask a mathematician, and he'll say that they are the same. The 
underlying concept of number treats 3 and 3.0 as the same thing (until 
you get to some extremely hairy mathematics, by which time the 
mathematician you ask will say that the question doesn't even make 
sense). In mathematics, the difference between 3 and 3+0/10 is, not 
surprisingly, 0.



-- 
Steven D'Aprano


From fuzzyman at gmail.com  Tue Sep 22 22:37:01 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Tue, 22 Sep 2009 21:37:01 +0100
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909222316.17285.steve@pearwood.info>
	<3BCBFD56-64B1-4D0A-90B4-39CDEC1C5D1C@masklinn.net>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
Message-ID: <6f4025010909221337q7f3a7fdco8b3f112677fff90a@mail.gmail.com>

2009/9/22 Masklinn <masklinn at masklinn.net>

> On 22 Sep 2009, at 17:46 , Steven D'Aprano wrote:
>
>> On Wed, 23 Sep 2009 12:25:32 am Masklinn wrote:
>>
>>> On 22 Sep 2009, at 15:16 , Steven D'Aprano wrote:
>>>
>>>> On Tue, 22 Sep 2009 01:05:41 pm Mathias Panzenb?ck wrote:
>>>>
>>>>> I don't think this is a valid test to determine how a language is
>>>>> typed. Ok, C++ is more or less weakly typed (for other reasons),
>>>>> but I think you could write something similar in C#, too. And C#
>>>>> is strongly typed.
>>>>>
>>>>
>>>> Weak and strong typing are a matter of degree -- there's no
>>>> definitive test for "weak" vs "strong" typing, only degrees of
>>>> weakness. The classic test is whether you can add strings and ints
>>>> together, but of course that's only one possible test out of many.
>>>>
>>>
>>> And it's a pretty bad one to boot: both Java and C# allow adding
>>> strings and ints (whether it's `3 + "5"` or `"5" + 3`) (in fact they
>>> allow adding *anything* to a string), but the operation is well
>>> defined: convert any non-string involved to a string (via #toString
>>> ()/.ToString()) and concatenate.
>>>
>>
>> I don't see why you say it's a bad test. To me, it's a good test, and
>> Java and C# pass it.
>>
>>  Uh no, by your criterion they fail it: both java and C# do add strings
> and integers without peeping.


C# will not allow you to add strings to numbers, this is nonsense. If you
call ToString() then this is an explicit operation to produce a string
representation - and it is this string that you add. It is *not* at all the
same as adding arbitrary objects on strings. You can't compile a C# program
that attempts to add strings and numbers.

I'm also pretty sure you can't override the default behavior on integers etc
(C# does have operator overloading but doesn't allow you to redefine
operators on the fundamental types - Java doesn't even have operator
overloading).

Michael


>
>
>  If you're only criterion is that an operation is well-defined,
>> then "weak typing" becomes meaningless: I could define addition of
>> dicts and strings to be the sum of the length of the dict with the
>> number of hyphens in the string, and declare that
>>
>> {'foo':'a', 'bar':'b'} + "12-34-56-78-90"
>>
>> returns 6, and by your criterion my language would be strongly typed. I
>> think that makes a mockery of the whole concept.
>>
> I don't think I defined any criterion of strong/weak typing. As far as I'm
> concerned, and as I've already mentioned in this thread, the whole
> weak/strong axis is meaningless and laughable.
>
>  This heuristic is not arbitrary.
>>
> Of course it is.
>
>  Automatically converting ints to floats
>> is mathematically reasonable, because we consider e.g. 3 and 3.0 to be
>> the same number.
>>
> Do we? Given 3/2 and 3.0/2 don't necessarily give the same answer (some
> languages don't even consider the first operation valid), I'm not sure we
> do.
>
>  Perl is weakly typed but it's very hard to cause it to crash,
>>
> See the link I previously gave, you might consider Perl weakly typed, not
> everybody does.
>
>  while C++ is strongly typed but easy to cause it to core-dump.
>>
> See my response to your previous declaration.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090922/489719a3/attachment.html>

From masklinn at masklinn.net  Tue Sep 22 22:55:09 2009
From: masklinn at masklinn.net (Masklinn)
Date: Tue, 22 Sep 2009 22:55:09 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909230617.04840.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<200909230617.04840.steve@pearwood.info>
Message-ID: <EAF20930-2696-449D-9A32-DDE884499209@masklinn.net>

On 22 Sep 2009, at 22:17 , Steven D'Aprano wrote:
> On Wed, 23 Sep 2009 02:35:49 am Masklinn wrote:
>> On 22 Sep 2009, at 17:46 , Steven D'Aprano wrote:
>>> On Wed, 23 Sep 2009 12:25:32 am Masklinn wrote:
>>>> On 22 Sep 2009, at 15:16 , Steven D'Aprano wrote:
>>>>> On Tue, 22 Sep 2009 01:05:41 pm Mathias Panzenb?ck wrote:
>>>>>> I don't think this is a valid test to determine how a language
>>>>>> is typed. Ok, C++ is more or less weakly typed (for other
>>>>>> reasons), but I think you could write something similar in C#,
>>>>>> too. And C# is strongly typed.
>>>>>
>>>>> Weak and strong typing are a matter of degree -- there's no
>>>>> definitive test for "weak" vs "strong" typing, only degrees of
>>>>> weakness. The classic test is whether you can add strings and
>>>>> ints together, but of course that's only one possible test out of
>>>>> many.
>>>>
>>>> And it's a pretty bad one to boot: both Java and C# allow adding
>>>> strings and ints (whether it's `3 + "5"` or `"5" + 3`) (in fact
>>>> they allow adding *anything* to a string), but the operation is
>>>> well defined: convert any non-string involved to a string (via
>>>> #toString ()/.ToString()) and concatenate.
>>>
>>> I don't see why you say it's a bad test. To me, it's a good test,
>>> and Java and C# pass it.
>>
>> Uh no, by your criterion they fail it: both java and C# do add
>> strings and integers without peeping.
>
> What are you talking about? Using Python syntax, we might write:
>
> assert "2"+2 == 4
>
> This test will FAIL for Python, Pascal and other strongly typed
> languages, and PASS for weakly typed languages. (For some languages,
> like Pascal, you can't even compile the test!)
>
Ah I see, we used different meanings for "fail" here. I was thinking  
of "failing the test" by accepting to run this piece of code (which I  
find obviously incorrect).

>
>>> If you're only criterion is that an operation is well-defined,
>>> then "weak typing" becomes meaningless...
>>
>> I don't think I defined any criterion of strong/weak typing.
>
> You conceded that C# adds strings and ints, but disputed that this  
> fact
> makes C# weakly typed on the basis that (I quote) "the operation is
> well defined".
I didn't dispute C#'s strong or weak typing (again, I consider this  
line of inquiry utterly worthless). I merely noted that the operation  
was clearly defined in the documentation, and am sorry if it came out  
as anything but a "note of interest".

> There's nothing about the definition of weakly typed
> languages
There is not definition of weak typing.

>> As far
>> as I'm concerned, and as I've already mentioned in this thread, the
>> whole weak/strong axis is meaningless and laughable.
>
> I agree that treating weak/strong as a binary state is an
> over-simplification, but a weak/strong axis is perfectly reasonable.
I really don't think so. Once again, because there is nothing formal  
about the concept, and everybody just make up their own definition of  
the axis as they go.

From masklinn at masklinn.net  Tue Sep 22 23:08:06 2009
From: masklinn at masklinn.net (Masklinn)
Date: Tue, 22 Sep 2009 23:08:06 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <6f4025010909221337q7f3a7fdco8b3f112677fff90a@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909222316.17285.steve@pearwood.info>
	<3BCBFD56-64B1-4D0A-90B4-39CDEC1C5D1C@masklinn.net>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<6f4025010909221337q7f3a7fdco8b3f112677fff90a@mail.gmail.com>
Message-ID: <29568095-C10E-4C7F-8690-45EB8070D7D5@masklinn.net>

On 22 Sep 2009, at 22:37 , Michael Foord wrote:
>
> C# will not allow you to add strings to numbers, this is nonsense.
I fear you're wrong. In C#, the operation `"foo " + 3` is perfectly
legal and returns `"foo 3"` (and the integer can, of course, be the
left hand of the operator). No need for a ToString, that's implicit.

In fact, this is quite clearly specified in the C# language
specification ?7.4.4. "The addition operator"
(http://msdn.microsoft.com/en-us/library/aa691375.aspx):

 > The binary + operator performs string concatenation when one or both
 > operands are of type string. If an operand of string concatenation is
 > null, an empty string is substituted. Otherwise, any non-string
 > argument is converted to its string representation by invoking the
 > virtual ToString method inherited from type object. If ToString
 > returns null, an empty string is substituted.
 >
 >     using System;
 >     class Test
 >     {
 >        static void Main() {
 >           string s = null;
 >           Console.WriteLine("s = >" + s + "<"); // displays s = ><
 >           int i = 1;
 >           Console.WriteLine("i = " + i);        // displays i = 1
 >           float f = 1.2300E+15F;
 >           Console.WriteLine("f = " + f);        // displays f =  
1.23+E15
 >           decimal d = 2.900m;
 >           Console.WriteLine("d = " + d);        // displays d = 2.900
 >        }
 >     }
> If you
> call ToString() then this is an explicit operation to produce a string
> representation - and it is this string that you add. It is *not* at  
> all the
> same as adding arbitrary objects on strings. You can't compile a C#  
> program
> that attempts to add strings and numbers.
You might have wanted to test out this theory.

> I'm also pretty sure you can't override the default behavior on  
> integers etc
> (C# does have operator overloading but doesn't allow you to redefine
> operators on the fundamental types - Java doesn't even have operator
> overloading).
Java somewhat does, since "+" is overloaded on String. What Java doesn't
provide is user-defined operator overloading.



From stephen at xemacs.org  Wed Sep 23 06:39:38 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 23 Sep 2009 13:39:38 +0900
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909230617.04840.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<200909230617.04840.steve@pearwood.info>
Message-ID: <87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>

Steven D'Aprano writes:

 > I agree that treating weak/strong as a binary state is an 
 > over-simplification, but a weak/strong axis is perfectly reasonable. 
 > Count the number of possible mixed-type operations permitted by the 
 > language (for simplicity, limit it to built-in or fundamental types).
 > What percentage of them succeed without explicit casts or conversions?
 > If that percentage is 0%, then the language is entirely strong. If it is 
 > 100%, then the language is entirely weak. In practice, languages will 
 > likely fall somewhere in the middle rather at the ends. This is an 
 > objective test for degree of type strength.

Sure, but I think Masklinn's point here is that it's a partial order.
I might very well consider a language with a D'Aprano index of 10%
more strongly typed than one with an index of 5% (eg, if the 10% are
all numeric coercions based on embeddings, while the 5% is various
combinations).

That said, I think Masklinn is being unreasonable.  Although there
surely are more folks like him who refuse to accept any notion of
"strength of typing", I think most people would be in rough agreement
as to which direction the axis points.

 > > > Automatically converting ints to floats is mathematically
 > > > reasonable, because we consider e.g. 3 and 3.0 to be the same
 > > > number.

I don't think we do consider them to be the *same*; substitutability
is one-way.  Yes, 3 can be used in place of 3.0 because the integers
can be embedded in the reals, but in general not vice versa.  We
prefer counters (eg in loops) to *not* automatically convert floats to
ints.  Supplying a float where an int is expected is generally a logic
error, not a notational convenience.

This notational convenience is very great, however.  It's not just a
matter of eliding the ".0" from "3.0"; it's also used in contexts like

    # enumerate the labels on the y-axis
    y-labels = list(0.50 + 0.05*i for i in range(10))

and in the cake-division problem below.  (A hairy mathematician would
point out that this can be justified as a notation for repeated
addition rather than coercion to float for multiplication, but I'm too
bald to bother, besides being an economist anyway.)  Note that you
cannot write "list(range(0.5,1.0,0.05))" to compute y-labels, though
that spelling seems very plausible to me.

I would argue that a language that coerces integer to float (or the
singleton 'nil' to list, to give another common example) is only
slightly more weakly typed than one that doesn't, because of the
embedding.  But one that coerces float to integer is much more weakly
typed than one that doesn't, because there is no embedding.

 > > Do we? Given 3/2 and 3.0/2 don't necessarily give the same answer
 > > (some languages don't even consider the first operation valid), I'm
 > > not sure we do.
 > 
 > Ask a mathematician, and he'll say that they are the same. The 
 > underlying concept of number treats 3 and 3.0 as the same thing (until 
 > you get to some extremely hairy mathematics,

No, even naive non-mathematicians may tell you they're different.  If
you ask any reasonably competent (but non-programmer) sixth grader,
they will tell you that 3/2 is "1 with a remainder of 1" (and we have
to play scissor-paper-stone to decide who gets the last piece of hard
candy), while 3.0/2 is "1.5" (and we split the third piece of cake in
half with a fork).



From masklinn at masklinn.net  Wed Sep 23 11:04:05 2009
From: masklinn at masklinn.net (Masklinn)
Date: Wed, 23 Sep 2009 11:04:05 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<200909230617.04840.steve@pearwood.info>
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <6FDD6AAA-8D93-45A2-8A81-A39162A41AC7@masklinn.net>

On 23 Sep 2009, at 06:39 , Stephen J. Turnbull wrote:
>
> That said, I think Masklinn is being unreasonable.  Although there
> surely are more folks like him who refuse to accept any notion of
> "strength of typing", I think most people would be in rough agreement
> as to which direction the axis points.
I might very well be unreasonable, but I've seen too many discussions  
of "strong" & "weak" typing degenerate into uselessness (all of them,  
really) to still consider them worth having, or still consider the  
concept of weak/strong typing worth talking about until somebody comes  
up with a precise and formal taxonomy which people will be able to use  
when discussing the matter.

Until then, discussion on the subject will be as enlightening and  
relevant as discussing which of hydrogen plasma and U-235 tastes the  
best.


From gerald.britton at gmail.com  Wed Sep 23 15:25:45 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Wed, 23 Sep 2009 09:25:45 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com> 
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net> 
	<200909230617.04840.steve@pearwood.info>
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com>

> ?> Ask a mathematician, and he'll say that they are the same. The
> ?> underlying concept of number treats 3 and 3.0 as the same thing (until
> ?> you get to some extremely hairy mathematics,
>
> No, even naive non-mathematicians may tell you they're different. ?If
> you ask any reasonably competent (but non-programmer) sixth grader,
> they will tell you that 3/2 is "1 with a remainder of 1" (and we have
> to play scissor-paper-stone to decide who gets the last piece of hard
> candy), while 3.0/2 is "1.5" (and we split the third piece of cake in
> half with a fork).

Naive non-mathematicians may indeed tell you that they are different,
but they are wrong.  Hopefully most readers of this thread, if not
professional mathematicians per se, are not naive.  I am neither naive
nor a mathematician by trade (though I have had healthy doses of maths
of all sorts), but if you ask me what three divided by two is, I'll
say one-and-a-half, every time, _unless_ you specify that the answer
must be an integer, in which case I would answer, "One!"

Ironically, since this is a Python list:

>>> 3/2
1.5

I have to be explicit to get integer division:

>>> 3//2
1

which is precisely my point


From bborcic at gmail.com  Wed Sep 23 15:45:19 2009
From: bborcic at gmail.com (Boris Borcic)
Date: Wed, 23 Sep 2009 15:45:19 +0200
Subject: [Python-ideas] wild idea : target decorators
Message-ID: <h9d8rt$ufn$1@ger.gmane.org>


Simply put, augmented assignment of the form

x op= expr

invites pythonistas to a particular intuition of the DRY principle
which feels denied whenever the need is encountered to write code of the
form

x = f(x,y)

or even, more simply

x = f(x)


on another hand, Python already admits an implied x = f(x) with decorators,
since by definition of decorators

@f
def x(...) : suite

means the same as

def x(...) : suite
x=f(x)

the embryonic proposal is to extend decorator syntax to arbitrary assignment 
targets, to permit use of it to formulate x=f(x) DRY-ly, e.g.

@f
x

together with a further syntax extension allowing to write the above on a single 
line, by postfixing the assignment target with the decorator, e.g.

x @f

or perhaps

x @= f

to be more in line with other augmented assignment operators, by analogy, say, 
with how

x *= 2

can replace

x = 2*x

while removing the need to repeat x

ok, this is clearly an completely embryonic idea shown (and motivated) only by 
(and through) how it would apply to the simplest imaginable use case. The 
displaying of it is intended to stimulate community discussion on whether and 
how it might extend to a more useful wider and consistent extension of the 
python language, and not to invite approval ratings over its current, well, egg.

IOW, does anybody feel like me there is a challenge to see better whether/how 
these two disjoint python corners, e.g. decorators on the one hand, and 
augmented assignment on the other hand, may surprisingly reveal they can fit a 
unifying extension of both ?

Cheers, BB



From g.brandl at gmx.net  Wed Sep 23 16:05:52 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 23 Sep 2009 16:05:52 +0200
Subject: [Python-ideas] wild idea : target decorators
In-Reply-To: <h9d8rt$ufn$1@ger.gmane.org>
References: <h9d8rt$ufn$1@ger.gmane.org>
Message-ID: <h9d9tu$2s9$1@ger.gmane.org>

Boris Borcic schrieb:

[...]

Note that it is *not* required to prefix each thread on this list
with "Wild idea".

Georg



From masklinn at masklinn.net  Wed Sep 23 16:16:54 2009
From: masklinn at masklinn.net (Masklinn)
Date: Wed, 23 Sep 2009 16:16:54 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<200909230617.04840.steve@pearwood.info>
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
	<5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com>
Message-ID: <1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>

On 23 Sep 2009, at 15:25 , Gerald Britton wrote:
>
> Ironically, since this is a Python list:
>
>>>> 3/2
> 1.5
>
> I have to be explicit to get integer division:
>
>>>> 3//2
> 1
>
> which is precisely my point

Unless you're using Python:

 >>> 3/2
1

You have to be explicit to get true division:

 >>> 3./2
1.5




From gerald.britton at gmail.com  Wed Sep 23 16:21:07 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Wed, 23 Sep 2009 10:21:07 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com> 
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net> 
	<200909230617.04840.steve@pearwood.info>
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp> 
	<5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com> 
	<1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>
Message-ID: <5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com>

wrong!  I did use Python:

$ python3
Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3/2
1.5
>>> 3//2
1
>>>

Surely we're not discussing an idea just for Python 2.x, are we?

On Wed, Sep 23, 2009 at 10:16 AM, Masklinn <masklinn at masklinn.net> wrote:
> On 23 Sep 2009, at 15:25 , Gerald Britton wrote:
>>
>> Ironically, since this is a Python list:
>>
>>>>> 3/2
>>
>> 1.5
>>
>> I have to be explicit to get integer division:
>>
>>>>> 3//2
>>
>> 1
>>
>> which is precisely my point
>
> Unless you're using Python:
>
>>>> 3/2
> 1
>
> You have to be explicit to get true division:
>
>>>> 3./2
> 1.5
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From masklinn at masklinn.net  Wed Sep 23 16:23:17 2009
From: masklinn at masklinn.net (Masklinn)
Date: Wed, 23 Sep 2009 16:23:17 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<200909230617.04840.steve@pearwood.info>
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
	<5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com>
	<1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>
	<5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com>
Message-ID: <9AB96BD8-24F3-4072-86E4-D9F3AEC43E59@masklinn.net>

On 23 Sep 2009, at 16:21 , Gerald Britton wrote:
> wrong!  I did use Python:
>
I know. So did I. That was my point.

> Surely we're not discussing an idea just for Python 2.x, are we?
I fail to see how this matters.


From gerald.britton at gmail.com  Wed Sep 23 16:32:50 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Wed, 23 Sep 2009 10:32:50 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <9AB96BD8-24F3-4072-86E4-D9F3AEC43E59@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com> 
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net> 
	<200909230617.04840.steve@pearwood.info>
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp> 
	<5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com> 
	<1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>
	<5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com> 
	<9AB96BD8-24F3-4072-86E4-D9F3AEC43E59@masklinn.net>
Message-ID: <5d1a32000909230732s2dfa1e6ch930554d82af69dc4@mail.gmail.com>

Your point is off-point, to say the least.  Python Ideas is used to
discuss possible new features to the language.  Few of these ideas
ever go beyond the discussion (this one certainly won't) and fewer
still are back-ported to 2.x

As to discussing an issue where there is a difference in behavior
between Python 2.x and 3.x, it matters -- a lot.

On Wed, Sep 23, 2009 at 10:23 AM, Masklinn <masklinn at masklinn.net> wrote:
> On 23 Sep 2009, at 16:21 , Gerald Britton wrote:
>>
>> wrong! ?I did use Python:
>>
> I know. So did I. That was my point.
>
>> Surely we're not discussing an idea just for Python 2.x, are we?
>
> I fail to see how this matters.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From masklinn at masklinn.net  Wed Sep 23 16:51:09 2009
From: masklinn at masklinn.net (Masklinn)
Date: Wed, 23 Sep 2009 16:51:09 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5d1a32000909230732s2dfa1e6ch930554d82af69dc4@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<200909230617.04840.steve@pearwood.info>
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
	<5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com>
	<1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>
	<5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com>
	<9AB96BD8-24F3-4072-86E4-D9F3AEC43E59@masklinn.net>
	<5d1a32000909230732s2dfa1e6ch930554d82af69dc4@mail.gmail.com>
Message-ID: <8845ECF4-C38D-432E-AAFD-CC4441ABA616@masklinn.net>

On 23 Sep 2009, at 16:32 , Gerald Britton wrote:
> Your point is off-point, to say the least.  Python Ideas is used to
> discuss possible new features to the language.
My point might be off-topic or off-list, but I don't think the current  
discussions of the identity between 3 and 3.0 and whether or not  
strong typing exists (and what it is) have much to do with "new  
features of the language". They've branched off and are discussions of  
their own and for discussion's sake.

I therefore don't think my point is off-point. The current lines of  
discussion are not about Python features.



From gerald.britton at gmail.com  Wed Sep 23 16:55:44 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Wed, 23 Sep 2009 10:55:44 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <8845ECF4-C38D-432E-AAFD-CC4441ABA616@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com> 
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<200909230617.04840.steve@pearwood.info> 
	<87ws3quved.fsf@uwakimon.sk.tsukuba.ac.jp>
	<5d1a32000909230625x62696a0fjdd4ab1e8e01a3189@mail.gmail.com> 
	<1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>
	<5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com> 
	<9AB96BD8-24F3-4072-86E4-D9F3AEC43E59@masklinn.net>
	<5d1a32000909230732s2dfa1e6ch930554d82af69dc4@mail.gmail.com> 
	<8845ECF4-C38D-432E-AAFD-CC4441ABA616@masklinn.net>
Message-ID: <5d1a32000909230755u678b292cj26951ba39f339222@mail.gmail.com>

On Wed, Sep 23, 2009 at 10:51 AM, Masklinn <masklinn at masklinn.net> wrote:
> On 23 Sep 2009, at 16:32 , Gerald Britton wrote:
>>
>> Your point is off-point, to say the least. ?Python Ideas is used to
>> discuss possible new features to the language.
>
> My point might be off-topic or off-list, but I don't think the current
> discussions of the identity between 3 and 3.0 and whether or not strong
> typing exists (and what it is) have much to do with "new features of the
> language". They've branched off and are discussions of their own and for
> discussion's sake.
>
> I therefore don't think my point is off-point. The current lines of
> discussion are not about Python features.

Well then, I think your discussion group has just shrunk to a memberhip of one.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From steve at pearwood.info  Thu Sep 24 01:40:23 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Thu, 24 Sep 2009 09:40:23 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <EAF20930-2696-449D-9A32-DDE884499209@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230617.04840.steve@pearwood.info>
	<EAF20930-2696-449D-9A32-DDE884499209@masklinn.net>
Message-ID: <200909240940.23776.steve@pearwood.info>

On Wed, 23 Sep 2009 06:55:09 am Masklinn wrote:
> > There's nothing about the definition of weakly typed
> > languages
>
> There is not definition of weak typing.

The world disagrees with you:

http://www.google.co.uk/search?q=define%3A%22weak+typing%22
http://dictionary.reference.com/browse/weak typing
http://en.wikipedia.org/wiki/Weak_typing

The distinction between weak and strong typing is as useful as that 
between large and small, and like the later, the lack of a precise 
distinction doesn't prevent the distinction being useful. (A large 
virus and a large star are not the same size.)



-- 
Steven D'Aprano


From steve at pearwood.info  Thu Sep 24 02:03:24 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Thu, 24 Sep 2009 10:03:24 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<1F8FEE67-A34B-4AB7-925E-5800FBDFBF35@masklinn.net>
	<5d1a32000909230721q4d652dacv221e6fc237c62fee@mail.gmail.com>
Message-ID: <200909241003.24512.steve@pearwood.info>

On Thu, 24 Sep 2009 12:21:07 am Gerald Britton wrote:
> wrong!  I did use Python:
>
> $ python3
> Python 3.0.1+ (r301:69556, Apr 15 2009, 15:59:22)
> [GCC 4.3.3] on linux2
> Type "help", "copyright", "credits" or "license" for more
> information.
>
> >>> 3/2
>
> 1.5
>
> >>> 3//2
>
> 1
>
>
> Surely we're not discussing an idea just for Python 2.x, are we?

Furthermore, classic division in Python 1.x and 2.x is harmful. Guido 
has publicly stated that defaulting to integer division in Python 1.x 
and 2.x was a mistake. In PEP 238 he calls it "a design bug".

http://www.python.org/dev/peps/pep-0238/

If anyone doubts that "ordinary people" treat 3 and 3.0 the same, or 
that 3/2 is 1.5 rather than 1 + 1 remainder, I recommend you do a 
mini-survey of your family, friends and workmates. Obviously if you ask 
small children before they have learned about fractions, or 
mathematicians who have immersed themselves entirely into some field of 
study using only integers, you may get different results, but 6000-odd 
years of common practice is to treat "whole numbers" as identical 
to "decimal numbers where the fraction part is zero"[1]. The *lack* of 
distinction is so strong that we don't have a simple term to 
distinguish 3 from 3.0 -- both are "whole numbers".



[1] I'm aware that decimal notation doesn't go back 6000 years. But the 
ancient Greeks and Egyptians were perfectly capable of dealing with 
fractions, and they too failed to distinguish between a whole number 
plus a fractional part of zero and a whole number on its own.


-- 
Steven D'Aprano


From masklinn at masklinn.net  Thu Sep 24 11:04:46 2009
From: masklinn at masklinn.net (Masklinn)
Date: Thu, 24 Sep 2009 11:04:46 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909240940.23776.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909230617.04840.steve@pearwood.info>
	<EAF20930-2696-449D-9A32-DDE884499209@masklinn.net>
	<200909240940.23776.steve@pearwood.info>
Message-ID: <2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>

On 24 Sep 2009, at 01:40 , Steven D'Aprano wrote:
> The world disagrees with you:
>
> [?]
> http://en.wikipedia.org/wiki/Weak_typing
Not really:

 > It is the opposite of strong typing, and consequently the term weak  
typing has as many different meanings as strong typing does

Go to "strong typing" and you have a list of 9 different (and not  
necessarily compatible) definitions of "strong typing".

From fuzzyman at gmail.com  Thu Sep 24 12:12:12 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 24 Sep 2009 11:12:12 +0100
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <29568095-C10E-4C7F-8690-45EB8070D7D5@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909222316.17285.steve@pearwood.info>
	<3BCBFD56-64B1-4D0A-90B4-39CDEC1C5D1C@masklinn.net>
	<200909230146.21497.steve@pearwood.info>
	<DFF25712-A317-43C6-9F08-E81919C05709@masklinn.net>
	<6f4025010909221337q7f3a7fdco8b3f112677fff90a@mail.gmail.com>
	<29568095-C10E-4C7F-8690-45EB8070D7D5@masklinn.net>
Message-ID: <6f4025010909240312i129e1ecp405008f97525bf6e@mail.gmail.com>

2009/9/22 Masklinn <masklinn at masklinn.net>

> On 22 Sep 2009, at 22:37 , Michael Foord wrote:
>
>>
>> C# will not allow you to add strings to numbers, this is nonsense.
>>
> I fear you're wrong. In C#, the operation `"foo " + 3` is perfectly
> legal and returns `"foo 3"` (and the integer can, of course, be the
> left hand of the operator). No need for a ToString, that's implicit.
>
>
Heh, you're right. How very odd.

Michael


> In fact, this is quite clearly specified in the C# language
> specification ?7.4.4. "The addition operator"
> (http://msdn.microsoft.com/en-us/library/aa691375.aspx):
>
> > The binary + operator performs string concatenation when one or both
> > operands are of type string. If an operand of string concatenation is
> > null, an empty string is substituted. Otherwise, any non-string
> > argument is converted to its string representation by invoking the
> > virtual ToString method inherited from type object. If ToString
> > returns null, an empty string is substituted.
> >
> >     using System;
> >     class Test
> >     {
> >        static void Main() {
> >           string s = null;
> >           Console.WriteLine("s = >" + s + "<"); // displays s = ><
> >           int i = 1;
> >           Console.WriteLine("i = " + i);        // displays i = 1
> >           float f = 1.2300E+15F;
> >           Console.WriteLine("f = " + f);        // displays f = 1.23+E15
> >           decimal d = 2.900m;
> >           Console.WriteLine("d = " + d);        // displays d = 2.900
> >        }
> >     }
>
>> If you
>> call ToString() then this is an explicit operation to produce a string
>> representation - and it is this string that you add. It is *not* at all
>> the
>> same as adding arbitrary objects on strings. You can't compile a C#
>> program
>> that attempts to add strings and numbers.
>>
> You might have wanted to test out this theory.
>
>  I'm also pretty sure you can't override the default behavior on integers
>> etc
>> (C# does have operator overloading but doesn't allow you to redefine
>> operators on the fundamental types - Java doesn't even have operator
>> overloading).
>>
> Java somewhat does, since "+" is overloaded on String. What Java doesn't
> provide is user-defined operator overloading.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090924/b590f75d/attachment.html>

From steve at pearwood.info  Fri Sep 25 00:54:08 2009
From: steve at pearwood.info (Steven D'Aprano)
Date: Fri, 25 Sep 2009 08:54:08 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
Message-ID: <200909250854.10218.steve@pearwood.info>

On Thu, 24 Sep 2009 07:04:46 pm Masklinn wrote:
> On 24 Sep 2009, at 01:40 , Steven D'Aprano wrote:
> > The world disagrees with you:
> >
> > [?]
> > http://en.wikipedia.org/wiki/Weak_typing
>
> Not really:
>  > It is the opposite of strong typing, and consequently the term
>  > weak
>
> typing has as many different meanings as strong typing does
>
> Go to "strong typing" and you have a list of 9 different (and not
> necessarily compatible) definitions of "strong typing".

How does Wikipedia stating that there are many definitions of weak 
typing support your assertion that "there is not [sic] definition of 
weak typing"? I think it is disingenuous of you to delete the text of 
yours I quoted. 

The terms weak and strong typing are very common use in the real world. 
If they don't have a single, formal, precise definition, that's too 
bad, but it doesn't prevent them from being useful so long as we 
remember that they are fuzzy terms. The English language is full of 
words and terms with multiple definitions and fuzzy gradings. We manage 
to communicate about relative differences in size quite well without a 
single objective and precise definition of "large", and we can 
communicate about relative differences in strength of the type system 
of languages quite well without a single objective and precise 
definition of type strength.




-- 
Steven D'Aprano


From gerald.britton at gmail.com  Fri Sep 25 02:06:22 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Thu, 24 Sep 2009 20:06:22 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <200909250854.10218.steve@pearwood.info>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com> 
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net> 
	<200909250854.10218.steve@pearwood.info>
Message-ID: <5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>

I think that the idea that there is a continuum from weak typing to
strong typing is useful.  At the weak end, the compiler lets you do
anything with anything without any declarations.  At the strong end,
you have to declare everything and explicitly code all type
conversions.  In practice I suppose, no compiler is completely weak or
completely strong in this regard.  It's probably possible to devise
some sort of metric to be able to place a given language on the
weak-strong scale.  That's not to say that one language is better than
another for being stronger or worse for being weaker.  They're just
different approaches and philosophies and target different sorts of
problems.

Where would Python fall?  Probably towards the weak end.  Is that bad?  No way!

On Thu, Sep 24, 2009 at 6:54 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Thu, 24 Sep 2009 07:04:46 pm Masklinn wrote:
>> On 24 Sep 2009, at 01:40 , Steven D'Aprano wrote:
>> > The world disagrees with you:
>> >
>> > [?]
>> > http://en.wikipedia.org/wiki/Weak_typing
>>
>> Not really:
>> ?> It is the opposite of strong typing, and consequently the term
>> ?> weak
>>
>> typing has as many different meanings as strong typing does
>>
>> Go to "strong typing" and you have a list of 9 different (and not
>> necessarily compatible) definitions of "strong typing".
>
> How does Wikipedia stating that there are many definitions of weak
> typing support your assertion that "there is not [sic] definition of
> weak typing"? I think it is disingenuous of you to delete the text of
> yours I quoted.
>
> The terms weak and strong typing are very common use in the real world.
> If they don't have a single, formal, precise definition, that's too
> bad, but it doesn't prevent them from being useful so long as we
> remember that they are fuzzy terms. The English language is full of
> words and terms with multiple definitions and fuzzy gradings. We manage
> to communicate about relative differences in size quite well without a
> single objective and precise definition of "large", and we can
> communicate about relative differences in strength of the type system
> of languages quite well without a single objective and precise
> definition of type strength.
>
>
>
>
> --
> Steven D'Aprano
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
Gerald Britton


From greg.ewing at canterbury.ac.nz  Fri Sep 25 02:38:23 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 25 Sep 2009 12:38:23 +1200
Subject: [Python-ideas] wild idea : target decorators
In-Reply-To: <h9d8rt$ufn$1@ger.gmane.org>
References: <h9d8rt$ufn$1@ger.gmane.org>
Message-ID: <4ABC10FF.30403@canterbury.ac.nz>

Boris Borcic wrote:

> @f
> x

I was thinking about something like this myself recently.
I have some custom property classes that I use extensively
in a couple of projects, declared like this:

   foo = fancy_property('foo', 'The fancy foo property')

It would be nice to be able to write this as something
like

   @fancy_property
   foo = 'The fancy foo property'

or perhaps

   @fancy_property('The fancy foo property')
   foo = default_foo_value

> x @= f

I think that would be going a bit too far.

-- 
Greg


From mwm-keyword-python.b4bdba at mired.org  Fri Sep 25 02:52:31 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Thu, 24 Sep 2009 20:52:31 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
	<200909250854.10218.steve@pearwood.info>
	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
Message-ID: <20090924205231.67c229e7@bhuda.mired.org>

On Thu, 24 Sep 2009 20:06:22 -0400
Gerald Britton <gerald.britton at gmail.com> wrote:

> I think that the idea that there is a continuum from weak typing to
> strong typing is useful.

I think it's fundamentally broken, at least as badly as the notion of
a political spectrum from liberal to conservative. The problem with
both of those is that there's more than one axis involved. Just as
people can have a liberal position on one issue while having a
conservative position on another, languages can have some features
that give them "weak typing" and others that give them "strong
typing".

This is different from the "large" vs. "small" distinction previously
mentioned, because size can be measured on a single axis, with the
large/small distinction depending on the context.

> At the weak end, the compiler lets you do anything with anything
> without any declarations.  At the strong end, you have to declare
> everything and explicitly code all type conversions.

See, you've just pointed out two axis: If declarations are optional
because the language does type inferencing, but the language does *no*
implicit conversion (ala at least some ML variants), is the typing
strong or weak?

Likewise, if I have to declare everything, but the language pretty
much lets me do anything with anything and will "fix" it (I think it
was Waterloo's PL/I that did this....), which end is it at?

What about if I have to declare everything, but not provide type
information, and you can do anything to anything (BCPL)?

By invoking the compiler, you actually referenced yet another type of
typing: checking done by the compiler is conventionally known as
"static" typing; checking done at run time is "dynamic" typing. This
one, at least, has a clearcut definition. But it's not really related
to strong .vs. weak.

Finally, Python is usually considered strongly - but dynamically -
because it doesn't do many implicit conversions. Perl is also
dynamically typed, but normally usually considered weekly typed,
because it does *lots* of implicit conversion.

But - Python will implicitly convert *anything* to a bool. Perl won't
do that. Now, which one is strongly typed again?

Axis so far: declarations: yes/no/optional. Variables have types:
(yes/no/optional). Implicit conversion: yes/no, with a different
answer possible for every operand and tuple of operators types in the
language.

> It's probably possible to devise some sort of metric to be able to
> place a given language on the weak-strong scale.

I don't think it's possible, because your scale is really a space.

> Where would Python fall?  Probably towards the weak end.  Is that bad?  No way!

Like I said, it's usually considered to be near the strong end,
because it does few implicit conversion. When compared to other
dynamically typed languages, it's *definitely* towards the strong
end. But dynamic typing by it's very nature includes things that make
typing look weak (types are tied to objects, not variables; no
declarations), so people may be tempted to tag it as weakly typed
because of those.

       <mike 
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From guido at python.org  Fri Sep 25 03:19:28 2009
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Sep 2009 18:19:28 -0700
Subject: [Python-ideas] wild idea : target decorators
In-Reply-To: <4ABC10FF.30403@canterbury.ac.nz>
References: <h9d8rt$ufn$1@ger.gmane.org> <4ABC10FF.30403@canterbury.ac.nz>
Message-ID: <ca471dc20909241819i4baebf2bj6dc6044d0761a74b@mail.gmail.com>

On Thu, Sep 24, 2009 at 5:38 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> I was thinking about something like this myself recently.
> I have some custom property classes that I use extensively
> in a couple of projects, declared like this:
>
> ?foo = fancy_property('foo', 'The fancy foo property')
>
> It would be nice to be able to write this as something
> like
>
> ?@fancy_property
> ?foo = 'The fancy foo property'

How did one occurrence of 'foo' suddenly turn into foo (without
quotes)? That's not how decorators behave elsewhere.

> or perhaps
>
> ?@fancy_property('The fancy foo property')
> ?foo = default_foo_value

I think the interpretation for decorators on things other than classes
and functions should be derived by carefully reinterpreting what a
decorator does for a function or class.

We already have the rule that

  @fancy
  def foo.........  # or class foo..........

is equivalent to

  def foo..........  # or class foo..........
  foo = fancy(foo)

Now in addition we know that

  def foo........  # or class foo...........

means

  foo = <create something>

so we have

  @fancy
  def foo........  # or class foo.........

as a shorthand for

  foo = fancy(<create something>)

>From this we can conclude that

  @fancy
  foo = <expression>

just means

  foo = fancy(<expression>)

which is (IMO) an utterly unattractive violation of TOOWTDI.

If you were going to object "but def foo and class foo also pass the
string 'foo' into <create something>", my counter-objection is that
those semantics are implied by the def/class keywords and not by the
@decorator syntax.

Ergo, -1.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From grosser.meister.morti at gmx.net  Fri Sep 25 03:31:15 2009
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Fri, 25 Sep 2009 03:31:15 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <20090924205231.67c229e7@bhuda.mired.org>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<200909240940.23776.steve@pearwood.info>	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>	<200909250854.10218.steve@pearwood.info>	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
	<20090924205231.67c229e7@bhuda.mired.org>
Message-ID: <4ABC1D63.4030902@gmx.net>

On 09/25/2009 02:52 AM, Mike Meyer wrote:
> On Thu, 24 Sep 2009 20:06:22 -0400
> Gerald Britton <gerald.britton at gmail.com> wrote:
> 
>> I think that the idea that there is a continuum from weak typing to
>> strong typing is useful.
> 
> I think it's fundamentally broken, at least as badly as the notion of
> a political spectrum from liberal to conservative. The problem with
> both of those is that there's more than one axis involved. 

Yes, we learned at the university:
strong <-> weak
static <-> dynamic
complete <-> with holes

However, these axis aren't completely independent. At one slide our professor
showed us a complex diagram of this not really 3D space that included merks for
some languages as examples.

	-panzi


From greg.ewing at canterbury.ac.nz  Fri Sep 25 04:20:06 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 25 Sep 2009 14:20:06 +1200
Subject: [Python-ideas] wild idea : target decorators
In-Reply-To: <ca471dc20909241819i4baebf2bj6dc6044d0761a74b@mail.gmail.com>
References: <h9d8rt$ufn$1@ger.gmane.org> <4ABC10FF.30403@canterbury.ac.nz>
	<ca471dc20909241819i4baebf2bj6dc6044d0761a74b@mail.gmail.com>
Message-ID: <4ABC28D6.7040603@canterbury.ac.nz>

Guido van Rossum wrote:
> On Thu, Sep 24, 2009 at 5:38 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
 >
>>  @fancy_property
>>  foo = 'The fancy foo property'
> 
> How did one occurrence of 'foo' suddenly turn into foo (without
> quotes)? That's not how decorators behave elsewhere.

Decorators on assignments would have to be defined slightly
differently, since as you point out, they wouldn't gain
you anything otherwise.

If you would prefer to use some syntax other than @ for
this, that would be fine with me. All I'm asking for is
*some* way to write things like this without having to
repeat the name of the thing being defined. There doesn't
seem to be any way to do that at the moment without
abusing some other construct, such as using a 'def'
when you aren't really defining a function.

-- 
Greg


From guido at python.org  Fri Sep 25 05:38:24 2009
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Sep 2009 20:38:24 -0700
Subject: [Python-ideas] wild idea : target decorators
In-Reply-To: <4ABC28D6.7040603@canterbury.ac.nz>
References: <h9d8rt$ufn$1@ger.gmane.org> <4ABC10FF.30403@canterbury.ac.nz> 
	<ca471dc20909241819i4baebf2bj6dc6044d0761a74b@mail.gmail.com> 
	<4ABC28D6.7040603@canterbury.ac.nz>
Message-ID: <ca471dc20909242038o76d8ea5co70cbae0bd8e29aa1@mail.gmail.com>

On Thu, Sep 24, 2009 at 7:20 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
>>
>> On Thu, Sep 24, 2009 at 5:38 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
>> wrote:
>
>>
>>>
>>> ?@fancy_property
>>> ?foo = 'The fancy foo property'
>>
>> How did one occurrence of 'foo' suddenly turn into foo (without
>> quotes)? That's not how decorators behave elsewhere.
>
> Decorators on assignments would have to be defined slightly
> differently, since as you point out, they wouldn't gain
> you anything otherwise.
>
> If you would prefer to use some syntax other than @ for
> this, that would be fine with me. All I'm asking for is
> *some* way to write things like this without having to
> repeat the name of the thing being defined. There doesn't
> seem to be any way to do that at the moment without
> abusing some other construct, such as using a 'def'
> when you aren't really defining a function.

So, you don't care abut the repetition of x in "x = f(x)" but you'd
like to have a way to implicitly pass an argument giving the string
name of the target variable, like "x = f('x')" ? (Or "x = f('x', x)";
it's the same thing really.) That certainly has nothing to do with
decorators. I'm not sure that it's common enough to warrant special
syntax; certainly "x = f(x)" must be a lot more common without also
needing to pass in the string 'x'.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From stephen at xemacs.org  Fri Sep 25 05:57:41 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 25 Sep 2009 12:57:41 +0900
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4ABC1D63.4030902@gmx.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
	<200909250854.10218.steve@pearwood.info>
	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
	<20090924205231.67c229e7@bhuda.mired.org>
	<4ABC1D63.4030902@gmx.net>
Message-ID: <87eipvoeve.fsf@uwakimon.sk.tsukuba.ac.jp>

Mathias Panzenb?ck writes:

 > However, these axis aren't completely independent. At one slide our
 > professor showed us a complex diagram of this not really 3D space
 > that included merks for some languages as examples.

Any chance you could find a link to that diagram?



From stephen at xemacs.org  Fri Sep 25 06:44:00 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 25 Sep 2009 13:44:00 +0900
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <20090924205231.67c229e7@bhuda.mired.org>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
	<200909250854.10218.steve@pearwood.info>
	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
	<20090924205231.67c229e7@bhuda.mired.org>
Message-ID: <87d45focq7.fsf@uwakimon.sk.tsukuba.ac.jp>

Mike Meyer writes:
 > On Thu, 24 Sep 2009 20:06:22 -0400
 > Gerald Britton <gerald.britton at gmail.com> wrote:
 > 
 > > I think that the idea that there is a continuum from weak typing to
 > > strong typing is useful.
 > 
 > I think it's fundamentally broken, at least as badly as the notion of
 > a political spectrum from liberal to conservative. The problem with
 > both of those is that there's more than one axis involved.

The notion that you can't order multidimensional sets (where each
dimension is ordered) is simply wrong.  You do it every day when you
decide to have "a Big Mac with coffee" instead of "a QuarterPounder
with a vanilla shake".

It is always possible to approximately reduce a multidimensional set
to a one-dimensional "spectrum" by use of a mechanical procedure
called principal components analysis (the "direction" of the spectrum
is the principal eigenvector, in fact).  This procedure provides
measures of the quality of the approximation as well (eg, the ratio of
the principal eigenvalue to the second eigenvalue).

The question here then is simply "what is the quality of the
approximation, and are there structural shifts to account for?"

 > Just as people can have a liberal position on one issue while
 > having a conservative position on another, languages can have some
 > features that give them "weak typing" and others that give them
 > "strong typing".

They can take such positions, but historically the correlations were
generally high.  What has happened in politics in many countries is
that there has been a structural realignment such that the component
axis traditionally labeled "liberal to conservative" is no longer so
much stronger than other components of variation.  That doesn't mean
that the traditional axis was never useful, nor that a new principal
axis hasn't been established (although I don't think it has been
established yet in American politics).

 > Axis so far: declarations: yes/no/optional. Variables have types:
 > (yes/no/optional). Implicit conversion: yes/no, with a different
 > answer possible for every operand and tuple of operators types in the
 > language.

My personal resolution of strong vs. weak typing is that it's useful
to help explain which languages I like (strongly typed ones) vs. those
I don't.  In this, only the implicit conversion axis matters much.
Whether variables have types, or declarations are needed, are
implementation details related to when type checking takes place (and
thus compile-time vs. runtime efficiency), and the tradeoff between
translator complexity and burden on the developer to specify things.
There are also issues of discoverability and readability which may
make it desirable to be somewhat explicit even though a high degree of
translator complexity is acceptable to me.

 > > It's probably possible to devise some sort of metric to be able to
 > > place a given language on the weak-strong scale.
 > 
 > I don't think it's possible, because your scale is really a space.

It's always possible.  Proving that is why Georg Cantor is so famous.
The question is whether it's compatible with "what people think", and
the answer is "if you must cover all corner cases, no" (ditto, Kenneth
Arrow).  Can you achieve something usable?  I don't know, which is why
I'd like to see Mathias's professor's slide!

 > > Where would Python fall?  Probably towards the weak end.  Is that
 > > bad?  No way!
 > 
 > Like I said, it's usually considered to be near the strong end,
 > because it does few implicit conversion.

+1

Furthermore, Python's builtin implicit conversions (with the exception
of the nearly universal conversion to Boolean, which is a special case
anyway) are mostly natural embeddings.  Even in cases like
"range(10.0)" Python refuses to guess.



From greg.ewing at canterbury.ac.nz  Fri Sep 25 11:57:00 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 25 Sep 2009 21:57:00 +1200
Subject: [Python-ideas] wild idea : target decorators
In-Reply-To: <ca471dc20909242038o76d8ea5co70cbae0bd8e29aa1@mail.gmail.com>
References: <h9d8rt$ufn$1@ger.gmane.org> <4ABC10FF.30403@canterbury.ac.nz>
	<ca471dc20909241819i4baebf2bj6dc6044d0761a74b@mail.gmail.com>
	<4ABC28D6.7040603@canterbury.ac.nz>
	<ca471dc20909242038o76d8ea5co70cbae0bd8e29aa1@mail.gmail.com>
Message-ID: <4ABC93EC.6010709@canterbury.ac.nz>

Guido van Rossum wrote:

> So, you don't care abut the repetition of x in "x = f(x)" but you'd
> like to have a way to implicitly pass an argument giving the string
> name of the target variable, like "x = f('x')" ?

Yes. I'm defining a property, and the descriptor happens
to need to know the name of the property being defined,
but that's an implementation detail. The user shouldn't
be required, or even allowed, to specify it as an
independent parameter.

 > I'm not sure that it's common enough to warrant special
> syntax;

Probably not very common in general, but I find myself
doing this very intensively in some of my projects. I
have two GUI libraries in which nearly every externally
visible attribute is one of these properties.

-- 
Greg


From solipsis at pitrou.net  Fri Sep 25 13:44:28 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Fri, 25 Sep 2009 11:44:28 +0000 (UTC)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com>
Message-ID: <loom.20090925T133504-900@post.gmane.org>

Bill Janssen <janssen at ...> writes:
> 
> Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> else; I was suggesting that providing easy-to-use APIs to a couple of
> commonly-requested crypto features, for use by non-cryptographers,
> wouldn't be a bad idea.

I think it would be good indeed. Since we already wrapping OpenSSL, let's give
access to more of its features instead of having people find additional binary
packages (of varying quality) for their platform.

As for some of the points which have been raised here:
- Putting non-hash functions in "hashlib" would look strange.
- Please don't call the package "evp", it's cryptic (;-)) and tied to a specific
implementation. "crypto" would be fine and obvious.
- I don't think there should be a default argument. People shouldn't try to do
any crypto at all if they aren't able to choose an algorithm. Documenting
(perhaps recommending) a couple of them (AES, RSA) would be more helpful than
supporting a silent default.
- The API needn't (and shouldn't) be the same as for hashing objects. A digest()
method doesn't make sense. Ideally some of the {en,de}crypting objects could be
file-like objects, but it's not really necessary IMO (and it can always be done
in pure Python on top of a lower-level C extension, assuming the extension does
provide a streaming interface).

Regards

Antoine.




From p.f.moore at gmail.com  Fri Sep 25 14:31:28 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 25 Sep 2009 13:31:28 +0100
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <loom.20090925T133504-900@post.gmane.org>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <loom.20090925T133504-900@post.gmane.org>
Message-ID: <79990c6b0909250531x41610198xec9e1f8e0da00a13@mail.gmail.com>

2009/9/25 Antoine Pitrou <solipsis at pitrou.net>:
> Bill Janssen <janssen at ...> writes:
>>
>> Again, I wasn't proposing to replace m2cryto or pycrypto or anything
>> else; I was suggesting that providing easy-to-use APIs to a couple of
>> commonly-requested crypto features, for use by non-cryptographers,
>> wouldn't be a bad idea.
>
> I think it would be good indeed. Since we already wrapping OpenSSL, let's give
> access to more of its features instead of having people find additional binary
> packages (of varying quality) for their platform.

+1.

> As for some of the points which have been raised here:
> - Putting non-hash functions in "hashlib" would look strange.
> - Please don't call the package "evp", it's cryptic (;-)) and tied to a specific
> implementation. "crypto" would be fine and obvious.
> - I don't think there should be a default argument. People shouldn't try to do
> any crypto at all if they aren't able to choose an algorithm. Documenting
> (perhaps recommending) a couple of them (AES, RSA) would be more helpful than
> supporting a silent default.
> - The API needn't (and shouldn't) be the same as for hashing objects. A digest()
> method doesn't make sense. Ideally some of the {en,de}crypting objects could be
> file-like objects, but it's not really necessary IMO (and it can always be done
> in pure Python on top of a lower-level C extension, assuming the extension does
> provide a streaming interface).

Again, +1.

Paul


From fuzzyman at gmail.com  Fri Sep 25 15:42:24 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Fri, 25 Sep 2009 14:42:24 +0100
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
	<200909250854.10218.steve@pearwood.info>
	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
Message-ID: <6f4025010909250642h236aa412w9563e380485abfad@mail.gmail.com>

2009/9/25 Gerald Britton <gerald.britton at gmail.com>

> I think that the idea that there is a continuum from weak typing to
> strong typing is useful.  At the weak end, the compiler lets you do
> anything with anything without any declarations.  At the strong end,
> you have to declare everything and explicitly code all type
> conversions.  In practice I suppose, no compiler is completely weak or
> completely strong in this regard.  It's probably possible to devise
> some sort of metric to be able to place a given language on the
> weak-strong scale.  That's not to say that one language is better than
> another for being stronger or worse for being weaker.  They're just
> different approaches and philosophies and target different sorts of
> problems.
>


The issue of type *declarations* is completely unrelated to strong or weak
typing. Haskell is one of the strongest typed languages there is - but the
types are usually inferred rather than declared. The compiler has a very
strong notion of types internally. Strong and weak typing are to do with the
way language treats 'objects' not how they are expressed in code (semantics
rather than syntax). Even C# these days has a very limited form of type
inferencing.

Michael


>
> Where would Python fall?  Probably towards the weak end.  Is that bad?  No
> way!
>
> On Thu, Sep 24, 2009 at 6:54 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
> > On Thu, 24 Sep 2009 07:04:46 pm Masklinn wrote:
> >> On 24 Sep 2009, at 01:40 , Steven D'Aprano wrote:
> >> > The world disagrees with you:
> >> >
> >> > [?]
> >> > http://en.wikipedia.org/wiki/Weak_typing
> >>
> >> Not really:
> >>  > It is the opposite of strong typing, and consequently the term
> >>  > weak
> >>
> >> typing has as many different meanings as strong typing does
> >>
> >> Go to "strong typing" and you have a list of 9 different (and not
> >> necessarily compatible) definitions of "strong typing".
> >
> > How does Wikipedia stating that there are many definitions of weak
> > typing support your assertion that "there is not [sic] definition of
> > weak typing"? I think it is disingenuous of you to delete the text of
> > yours I quoted.
> >
> > The terms weak and strong typing are very common use in the real world.
> > If they don't have a single, formal, precise definition, that's too
> > bad, but it doesn't prevent them from being useful so long as we
> > remember that they are fuzzy terms. The English language is full of
> > words and terms with multiple definitions and fuzzy gradings. We manage
> > to communicate about relative differences in size quite well without a
> > single objective and precise definition of "large", and we can
> > communicate about relative differences in strength of the type system
> > of languages quite well without a single objective and precise
> > definition of type strength.
> >
> >
> >
> >
> > --
> > Steven D'Aprano
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > http://mail.python.org/mailman/listinfo/python-ideas
> >
>
>
>
> --
> Gerald Britton
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090925/dddbb681/attachment.html>

From anfedorov at gmail.com  Fri Sep 25 16:34:34 2009
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Fri, 25 Sep 2009 10:34:34 -0400
Subject: [Python-ideas] Why is there a callable predicate, but no iterable?
Message-ID: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>

So there was a discussion back in April [0] about the lack of an "iterable"
predicate, which Pascal pointing out that the intention may be to use
"isinstance(obj, Iterable)" instead. That seems inconsistent with the
existence of collections.Callable (so, isinstance(obj, Callable) instead of
callable(obj)).

Which direction is this more likely to be resolved? Should I write
iterable(obj) or expect callable(obj) to be deprecated?

- Andrey

0. http://mail.python.org/pipermail/python-ideas/2009-April/004382.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090925/d0d8c5ea/attachment.html>

From gerald.britton at gmail.com  Fri Sep 25 16:39:44 2009
From: gerald.britton at gmail.com (Gerald Britton)
Date: Fri, 25 Sep 2009 10:39:44 -0400
Subject: [Python-ideas] Why is there a callable predicate,
	but no 	iterable?
In-Reply-To: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>
References: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>
Message-ID: <5d1a32000909250739y69a43da0jc8aa80b6bab776dc@mail.gmail.com>

I think callable() was removed in 3.x:

http://docs.python.org/3.1/whatsnew/3.0.html?highlight=callable

On Fri, Sep 25, 2009 at 10:34 AM, Andrey Fedorov <anfedorov at gmail.com> wrote:
> So there was a discussion back in April [0] about the lack of an "iterable"
> predicate, which Pascal pointing out that the intention may be to use
> "isinstance(obj, Iterable)" instead. That seems inconsistent with the
> existence of collections.Callable (so, isinstance(obj, Callable) instead of
> callable(obj)).
>
> Which direction is this more likely to be resolved? Should I write
> iterable(obj) or expect callable(obj) to be deprecated?
>
> - Andrey
>
> 0. http://mail.python.org/pipermail/python-ideas/2009-April/004382.html
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>



-- 
Gerald Britton


From guido at python.org  Fri Sep 25 16:41:55 2009
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Sep 2009 07:41:55 -0700
Subject: [Python-ideas] wild idea : target decorators
In-Reply-To: <4ABC93EC.6010709@canterbury.ac.nz>
References: <h9d8rt$ufn$1@ger.gmane.org> <4ABC10FF.30403@canterbury.ac.nz> 
	<ca471dc20909241819i4baebf2bj6dc6044d0761a74b@mail.gmail.com> 
	<4ABC28D6.7040603@canterbury.ac.nz>
	<ca471dc20909242038o76d8ea5co70cbae0bd8e29aa1@mail.gmail.com> 
	<4ABC93EC.6010709@canterbury.ac.nz>
Message-ID: <ca471dc20909250741k5fe4da11oa317d67944dd2ca9@mail.gmail.com>

On Fri, Sep 25, 2009 at 2:57 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
>
>> So, you don't care abut the repetition of x in "x = f(x)" but you'd
>> like to have a way to implicitly pass an argument giving the string
>> name of the target variable, like "x = f('x')" ?
>
> Yes. I'm defining a property, and the descriptor happens
> to need to know the name of the property being defined,
> but that's an implementation detail. The user shouldn't
> be required, or even allowed, to specify it as an
> independent parameter.
>
>> I'm not sure that it's common enough to warrant special
>>
>> syntax;
>
> Probably not very common in general, but I find myself
> doing this very intensively in some of my projects. I
> have two GUI libraries in which nearly every externally
> visible attribute is one of these properties.

A common pattern for this is to have a metaclass that walks over all
the properties in the class (which are easily recognized using
isinstance() or some other check) and calls them with an
initialization function that passed in their name.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


From anfedorov at gmail.com  Fri Sep 25 16:42:46 2009
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Fri, 25 Sep 2009 10:42:46 -0400
Subject: [Python-ideas] Why is there a callable predicate,
	but no 	iterable?
In-Reply-To: <5d1a32000909250739y69a43da0jc8aa80b6bab776dc@mail.gmail.com>
References: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com> 
	<5d1a32000909250739y69a43da0jc8aa80b6bab776dc@mail.gmail.com>
Message-ID: <7659cab30909250742na2e3917i71a90dbc5ec7f93e@mail.gmail.com>

Aha, indeed!

Removed callable(). Instead of callable(f) you can use hasattr(f,
> '__call__'). The operator.isCallable() function is also gone.
>

What is the tradeoff between hasattr(f, '__call__') and isinstance(f,
Callable)?

- Andrey

On Fri, Sep 25, 2009 at 10:39 AM, Gerald Britton
<gerald.britton at gmail.com>wrote:

> I think callable() was removed in 3.x:
>
> http://docs.python.org/3.1/whatsnew/3.0.html?highlight=callable
>
> On Fri, Sep 25, 2009 at 10:34 AM, Andrey Fedorov <anfedorov at gmail.com>
> wrote:
> > So there was a discussion back in April [0] about the lack of an
> "iterable"
> > predicate, which Pascal pointing out that the intention may be to use
> > "isinstance(obj, Iterable)" instead. That seems inconsistent with the
> > existence of collections.Callable (so, isinstance(obj, Callable) instead
> of
> > callable(obj)).
> >
> > Which direction is this more likely to be resolved? Should I write
> > iterable(obj) or expect callable(obj) to be deprecated?
> >
> > - Andrey
> >
> > 0. http://mail.python.org/pipermail/python-ideas/2009-April/004382.html
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > http://mail.python.org/mailman/listinfo/python-ideas
> >
> >
>
>
>
> --
> Gerald Britton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090925/31a81170/attachment.html>

From qgallet at gmail.com  Fri Sep 25 16:43:18 2009
From: qgallet at gmail.com (Quentin Gallet-Gilles)
Date: Fri, 25 Sep 2009 16:43:18 +0200
Subject: [Python-ideas] Why is there a callable predicate,
	but no 	iterable?
In-Reply-To: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>
References: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>
Message-ID: <8b943f2b0909250743q28fd58a9ia3e85ca98367bd09@mail.gmail.com>

On Fri, Sep 25, 2009 at 4:34 PM, Andrey Fedorov <anfedorov at gmail.com> wrote:

> So there was a discussion back in April [0] about the lack of an "iterable"
> predicate, which Pascal pointing out that the intention may be to use
> "isinstance(obj, Iterable)" instead. That seems inconsistent with the
> existence of collections.Callable (so, isinstance(obj, Callable) instead of
> callable(obj)).
>
> Which direction is this more likely to be resolved? Should I write
> iterable(obj) or expect callable(obj) to be deprecated?
>

The latter : callable() has been removed in Python 3 and the new way is to
check the existence of the __call__() method => hasattr(obj, '__call__')


>
> - Andrey
>
> 0. http://mail.python.org/pipermail/python-ideas/2009-April/004382.html
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>

Cheers,
Quentin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090925/e2c9ea86/attachment.html>

From debatem1 at gmail.com  Fri Sep 25 17:40:40 2009
From: debatem1 at gmail.com (CTO)
Date: Fri, 25 Sep 2009 08:40:40 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <loom.20090925T133504-900@post.gmane.org>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <loom.20090925T133504-900@post.gmane.org>
Message-ID: <24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>



On Sep 25, 7:44?am, Antoine Pitrou <solip... at pitrou.net> wrote:
> Bill Janssen <janssen at ...> writes:
>
> > Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> > else; I was suggesting that providing easy-to-use APIs to a couple of
> > commonly-requested crypto features, for use by non-cryptographers,
> > wouldn't be a bad idea.
>
> I think it would be good indeed. Since we already wrapping OpenSSL, let's give
> access to more of its features instead of having people find additional binary
> packages (of varying quality) for their platform.

I've started putting the code together. It's very rough, but it does
vaguely what it's supposed to do. It only supports AES192 right now,
but it shouldn't be any harder to expand on that than it was to
write the existing code, and I'd appreciate the contributions of
anyone interested in seeing this in the standard library- it needs
the help.

You can find my code over at http://gitorious.org/cryptography-py/cryptography-py.

> As for some of the points which have been raised here:
...snip...
> - Please don't call the package "evp", it's cryptic (;-)) and tied to a specific
> implementation. "crypto" would be fine and obvious.

I know of at least one implementation that uses Crypto as its
name, and forgot to send them an email earlier this week. I'll
do that today, and if they don't seem bent on changing the
capitalization, I don't see any problem there.

A side note: the code I've posted is a little schizophrenic
since we haven't figured a name or toplevel structure out. That
can change whenever a consensus  emerges.

> - I don't think there should be a default argument. People shouldn't try to do
> any crypto at all if they aren't able to choose an algorithm. Documenting
> (perhaps recommending) a couple of them (AES, RSA) would be more helpful than
> supporting a silent default.

Right now it just divides one cryptosystem into each module.
For example, to use AES192, you can simply say:

import aes
ciphertext = aes.encrypt("this is a message", "this is my password")
plaintext = aes.decrypt(ciphertext, "this is my password")
assert plaintext == "this is a message"

and it handles salt generation, IV generation, bitlength selection,
and key strengthening for you.

Eventually, if crypto becomes the name of the package, it will
probably turn into "from crypto import aes".

> - The API needn't (and shouldn't) be the same as for hashing objects. A digest()
> method doesn't make sense. Ideally some of the {en,de}crypting objects could be
> file-like objects, but it's not really necessary IMO (and it can always be done
> in pure Python on top of a lower-level C extension, assuming the extension does
> provide a streaming interface).

I can provide the streaming interface if it's desired. It would in
some cases
be more efficient, but for most I think it's needless complexity.
Again,
others may disagree, and I'm sure there's fertile ground for
discussion
there.

Geremy Condra


From robert.kern at gmail.com  Fri Sep 25 18:20:55 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 25 Sep 2009 11:20:55 -0500
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>
References: <7922.1253233496@parc.com>	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>	<20862.1253466431@parc.com>	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>	<19693.1253547829@parc.com>	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>	<28161.1253569055@parc.com>
	<loom.20090925T133504-900@post.gmane.org>
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>
Message-ID: <h9iql8$h7e$1@ger.gmane.org>

On 2009-09-25 10:40 AM, CTO wrote:
>
> On Sep 25, 7:44 am, Antoine Pitrou<solip... at pitrou.net>  wrote:

>> As for some of the points which have been raised here:
> ...snip...
>> - Please don't call the package "evp", it's cryptic (;-)) and tied to a specific
>> implementation. "crypto" would be fine and obvious.
>
> I know of at least one implementation that uses Crypto as its
> name, and forgot to send them an email earlier this week. I'll
> do that today, and if they don't seem bent on changing the
> capitalization, I don't see any problem there.

I wouldn't rely on capitalization to differentiate between packages. I think 
that Python will be able to do so in most circumstances, even on Windows, but it 
makes it hard to talk about the different packages and ask questions about them 
on the mailing lists.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



From grosser.meister.morti at gmx.net  Fri Sep 25 18:22:21 2009
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Fri, 25 Sep 2009 18:22:21 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <87eipvoeve.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<200909240940.23776.steve@pearwood.info>	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>	<200909250854.10218.steve@pearwood.info>	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>	<20090924205231.67c229e7@bhuda.mired.org>	<4ABC1D63.4030902@gmx.net>
	<87eipvoeve.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4ABCEE3D.2010606@gmx.net>

On 09/25/2009 05:57 AM, Stephen J. Turnbull wrote:
> Mathias Panzenb?ck writes:
> 
>  > However, these axis aren't completely independent. At one slide our
>  > professor showed us a complex diagram of this not really 3D space
>  > that included merks for some languages as examples.
> 
> Any chance you could find a link to that diagram?
> 

I searched all the (pdf) slides and didn't find it. I found one diagram but that
isn't the one I meant. Thinking of it, I might be the case that the Prof. has
drawn it to the blackboard (because he forgot to include it in his slides). I'd
have to look through all my notes drawn/written onto the slide printouts of
several lectures to find it. I'm not sure if he showed us this diagram in "Type
Systems", "Programming Languages" or "Advanced Object Orientated Programming".

	-panzi


From masklinn at masklinn.net  Fri Sep 25 18:44:32 2009
From: masklinn at masklinn.net (Masklinn)
Date: Fri, 25 Sep 2009 18:44:32 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <4ABCEE3D.2010606@gmx.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<200909240940.23776.steve@pearwood.info>	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>	<200909250854.10218.steve@pearwood.info>	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>	<20090924205231.67c229e7@bhuda.mired.org>	<4ABC1D63.4030902@gmx.net>
	<87eipvoeve.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4ABCEE3D.2010606@gmx.net>
Message-ID: <75BB1D37-B1C3-4A1C-BFFE-617B48B90013@masklinn.net>

On 25 Sep 2009, at 18:22 , Mathias Panzenb?ck wrote:
> On 09/25/2009 05:57 AM, Stephen J. Turnbull wrote:
>> Mathias Panzenb?ck writes:
>>
>>> However, these axis aren't completely independent. At one slide our
>>> professor showed us a complex diagram of this not really 3D space
>>> that included merks for some languages as examples.
>>
>> Any chance you could find a link to that diagram?
>>
>
> I searched all the (pdf) slides and didn't find it. I found one  
> diagram but that
> isn't the one I meant. Thinking of it, I might be the case that the  
> Prof. has
> drawn it to the blackboard (because he forgot to include it in his  
> slides). I'd
> have to look through all my notes drawn/written onto the slide  
> printouts of
> several lectures to find it. I'm not sure if he showed us this  
> diagram in "Type
> Systems", "Programming Languages" or "Advanced Object Orientated  
> Programming".
>
> 	-panzi

One of the diagrams on C2's Typing Quadrant page (http://c2.com/cgi/wiki?TypingQuadrant 
) might correspond (about halfway down the page, after the comment  
"Perhaps we need a cube rather than a square")



From p.f.moore at gmail.com  Fri Sep 25 19:45:44 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 25 Sep 2009 18:45:44 +0100
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <h9iql8$h7e$1@ger.gmane.org>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <loom.20090925T133504-900@post.gmane.org>
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>
	<h9iql8$h7e$1@ger.gmane.org>
Message-ID: <79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>

2009/9/25 Robert Kern <robert.kern at gmail.com>:
> On 2009-09-25 10:40 AM, CTO wrote:
>>
>> On Sep 25, 7:44 am, Antoine Pitrou<solip... at pitrou.net> ?wrote:
>>>
>>> - Please don't call the package "evp", it's cryptic (;-)) and tied to a
>>> specific
>>> implementation. "crypto" would be fine and obvious.
>>
>> I know of at least one implementation that uses Crypto as its
>> name, and forgot to send them an email earlier this week. I'll
>> do that today, and if they don't seem bent on changing the
>> capitalization, I don't see any problem there.
>
> I wouldn't rely on capitalization to differentiate between packages. I think
> that Python will be able to do so in most circumstances, even on Windows,
> but it makes it hard to talk about the different packages and ask questions
> about them on the mailing lists.

Agreed. How about "encryption"?

Paul.


From tjreedy at udel.edu  Fri Sep 25 22:01:36 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 25 Sep 2009 16:01:36 -0400
Subject: [Python-ideas] Why is there a callable predicate,
	but no  iterable?
In-Reply-To: <7659cab30909250742na2e3917i71a90dbc5ec7f93e@mail.gmail.com>
References: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>
	<5d1a32000909250739y69a43da0jc8aa80b6bab776dc@mail.gmail.com>
	<7659cab30909250742na2e3917i71a90dbc5ec7f93e@mail.gmail.com>
Message-ID: <h9j7is$r3o$1@ger.gmane.org>

Andrey Fedorov wrote:

> What is the tradeoff between hasattr(f, '__call__')

I know about that ;-)

> and isinstance(f, Callable)?

New to me ;-)
I presume it needs an import.
I presume it also requires that something be registered as a Callable.

Terry Jan Reedy



From g.brandl at gmx.net  Fri Sep 25 23:42:34 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 25 Sep 2009 23:42:34 +0200
Subject: [Python-ideas] Why is there a callable predicate,
	but no  iterable?
In-Reply-To: <h9j7is$r3o$1@ger.gmane.org>
References: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>	<5d1a32000909250739y69a43da0jc8aa80b6bab776dc@mail.gmail.com>	<7659cab30909250742na2e3917i71a90dbc5ec7f93e@mail.gmail.com>
	<h9j7is$r3o$1@ger.gmane.org>
Message-ID: <h9jdkg$eqa$1@ger.gmane.org>

Terry Reedy schrieb:
> Andrey Fedorov wrote:
> 
>> What is the tradeoff between hasattr(f, '__call__')
> 
> I know about that ;-)
> 
>> and isinstance(f, Callable)?
> 
> New to me ;-)
> I presume it needs an import.
> I presume it also requires that something be registered as a Callable.

Nope; it uses the new instance/subclass inquiry hooks to pretend all objects
having a __call__ attribute are instances of Callable.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From debatem1 at gmail.com  Fri Sep 25 23:07:41 2009
From: debatem1 at gmail.com (CTO)
Date: Fri, 25 Sep 2009 14:07:41 -0700 (PDT)
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>
References: <7922.1253233496@parc.com>
	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>
	<20862.1253466431@parc.com>
	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>
	<19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <loom.20090925T133504-900@post.gmane.org> 
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com> 
	<h9iql8$h7e$1@ger.gmane.org>
	<79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>
Message-ID: <e3d004ea-7db4-4bc0-9ea4-2ae458798ecb@s6g2000vbp.googlegroups.com>



On Sep 25, 1:45?pm, Paul Moore <p.f.mo... at gmail.com> wrote:
> 2009/9/25 Robert Kern <robert.k... at gmail.com>:
>
>
>
> > On 2009-09-25 10:40 AM, CTO wrote:
>
> >> On Sep 25, 7:44 am, Antoine Pitrou<solip... at pitrou.net> ?wrote:
>
> >>> - Please don't call the package "evp", it's cryptic (;-)) and tied to a
> >>> specific
> >>> implementation. "crypto" would be fine and obvious.
>
> >> I know of at least one implementation that uses Crypto as its
> >> name, and forgot to send them an email earlier this week. I'll
> >> do that today, and if they don't seem bent on changing the
> >> capitalization, I don't see any problem there.
>
> > I wouldn't rely on capitalization to differentiate between packages. I think
> > that Python will be able to do so in most circumstances, even on Windows,
> > but it makes it hard to talk about the different packages and ask questions
> > about them on the mailing lists.
>
> Agreed. How about "encryption"?

EVP covers hashing, signatures, and encryption/decryption. If we're
going
to go for a longer name, maybe "cryptography" would be more
appropriate?

Geremy Condra


From grosser.meister.morti at gmx.net  Sat Sep 26 00:31:36 2009
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Sat, 26 Sep 2009 00:31:36 +0200
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <75BB1D37-B1C3-4A1C-BFFE-617B48B90013@masklinn.net>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<200909240940.23776.steve@pearwood.info>	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>	<200909250854.10218.steve@pearwood.info>	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>	<20090924205231.67c229e7@bhuda.mired.org>	<4ABC1D63.4030902@gmx.net>	<87eipvoeve.fsf@uwakimon.sk.tsukuba.ac.jp>	<4ABCEE3D.2010606@gmx.net>
	<75BB1D37-B1C3-4A1C-BFFE-617B48B90013@masklinn.net>
Message-ID: <4ABD44C8.8020508@gmx.net>

On 09/25/2009 06:44 PM, Masklinn wrote:
> 
> One of the diagrams on C2's Typing Quadrant page
> (http://c2.com/cgi/wiki?TypingQuadrant) might correspond (about halfway
> down the page, after the comment "Perhaps we need a cube rather than a
> square")
> 

Well, they all miss the complete <-> with holes axis. Because languages like
C/C++ have something like a reinterpret cast or no bound checks on arrays they
have holes. That might not be that of an important axis, but it was represented
in this diagram. Whatever.

	-panzi


From mwm-keyword-python.b4bdba at mired.org  Sat Sep 26 01:07:59 2009
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Fri, 25 Sep 2009 19:07:59 -0400
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <87d45focq7.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
	<200909250854.10218.steve@pearwood.info>
	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
	<20090924205231.67c229e7@bhuda.mired.org>
	<87d45focq7.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20090925190759.3d817a15@bhuda.mired.org>

On Fri, 25 Sep 2009 13:44:00 +0900
"Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> Mike Meyer writes:
>  > On Thu, 24 Sep 2009 20:06:22 -0400
>  > Gerald Britton <gerald.britton at gmail.com> wrote:
>  > 
>  > > I think that the idea that there is a continuum from weak typing to
>  > > strong typing is useful.
>  > 
>  > I think it's fundamentally broken, at least as badly as the notion of
>  > a political spectrum from liberal to conservative. The problem with
>  > both of those is that there's more than one axis involved.
> 
> The notion that you can't order multidimensional sets (where each
> dimension is ordered) is simply wrong.  You do it every day when you
> decide to have "a Big Mac with coffee" instead of "a QuarterPounder
> with a vanilla shake".

The idea that ordering multidimensional sets matters is simply
wrong. Obviously, you can impose an order - and probably many - on any
countable set - or any space with a countable number of axis.

That leaves three problems, in increasing order of pain:

1) It's not clear the resulting object can be described as a continuum.
2) It's not clear that any of the orders are meaningful.
3) Unless everyone agrees on the order, it's still useless.

#3 is the critical one. You've basically moved the problem from
selecting one from a set of axis to selecting one from a set of
possible orders of a set of axis. Which starts with selecting the set
of meaningful axis from the power set - which is noticeably larger
than set of axis.  The number of meaningful orderings may well
approach the power set in size.

> The question here then is simply "what is the quality of the
> approximation, and are there structural shifts to account for?"

*After* you've agreed on which axis matter, and that the PCA is the
 ordering you want to use. 

>  > Just as people can have a liberal position on one issue while
>  > having a conservative position on another, languages can have some
>  > features that give them "weak typing" and others that give them
>  > "strong typing".
> 
> They can take such positions, but historically the correlations were
> generally high.  What has happened in politics in many countries is
> that there has been a structural realignment such that the component
> axis traditionally labeled "liberal to conservative" is no longer so
> much stronger than other components of variation.  That doesn't mean
> that the traditional axis was never useful, nor that a new principal
> axis hasn't been established (although I don't think it has been
> established yet in American politics).

I've seen people using two political axis for the last couple of
decades: financially conservative/liberal and personally
conservative/liberal. You can of course collapse that to one axis.
You can also describe the solar system with epicycles. But using two
axes - or ellipses - is a more powerful model to work with.

Which is the point - until we can agree


>  > Axis so far: declarations: yes/no/optional. Variables have types:
>  > (yes/no/optional). Implicit conversion: yes/no, with a different
>  > answer possible for every operand and tuple of operators types in the
>  > language.
> 
> My personal resolution of strong vs. weak typing is that it's useful
> to help explain which languages I like (strongly typed ones) vs. those
> I don't.

This, of course, tells me pretty nearly *nothing* about which
languages you like.

> In this, only the implicit conversion axis matters much.

I suspect you care about more than that - or do you weigh Python
converting everything to a bool in a boolean context as equivalent to
some language that will convert everything to a string if there's a
string in the expression?

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


From ncoghlan at gmail.com  Sat Sep 26 03:49:27 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Sep 2009 11:49:27 +1000
Subject: [Python-ideas] adding digital signature and encryption "hashes"
 to hashlib?
In-Reply-To: <e3d004ea-7db4-4bc0-9ea4-2ae458798ecb@s6g2000vbp.googlegroups.com>
References: <7922.1253233496@parc.com>	<6b2ca13a-e09e-4cc1-b738-a7e2a4a5a127@r36g2000vbn.googlegroups.com>	<20862.1253466431@parc.com>	<9780d7c2-e532-455a-851f-04f812e464b1@f10g2000vbf.googlegroups.com>	<19693.1253547829@parc.com>	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>	<28161.1253569055@parc.com>
	<loom.20090925T133504-900@post.gmane.org>
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>
	<h9iql8$h7e$1@ger.gmane.org>	<79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>
	<e3d004ea-7db4-4bc0-9ea4-2ae458798ecb@s6g2000vbp.googlegroups.com>
Message-ID: <4ABD7327.6090206@gmail.com>

CTO wrote:
> EVP covers hashing, signatures, and encryption/decryption. If we're
> going
> to go for a longer name, maybe "cryptography" would be more
> appropriate?

Something to keep in mind while working on this is your threat model for
the library. If you aren't going to do anything to guard against
side-channel attacks (which are rather hard to avoid in a cross platform
algorithm on a general purpose PC) or against attacks which grab
unencrypted messages and keys from released-but-not-overwritten computer
memory or (worse) the swap file, then this should be mentioned in the
documentation.

That way application developers that are looking for that extra level of
security will know they need to look elsewhere.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From debatem1 at gmail.com  Sat Sep 26 04:16:25 2009
From: debatem1 at gmail.com (geremy condra)
Date: Fri, 25 Sep 2009 22:16:25 -0400
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <4ABD7327.6090206@gmail.com>
References: <7922.1253233496@parc.com> <19693.1253547829@parc.com>
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>
	<28161.1253569055@parc.com> <loom.20090925T133504-900@post.gmane.org>
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>
	<h9iql8$h7e$1@ger.gmane.org>
	<79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>
	<e3d004ea-7db4-4bc0-9ea4-2ae458798ecb@s6g2000vbp.googlegroups.com>
	<4ABD7327.6090206@gmail.com>
Message-ID: <f3cc57c60909251916g31eaa67en37022995563652da@mail.gmail.com>

On Fri, Sep 25, 2009 at 9:49 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> CTO wrote:
> > EVP covers hashing, signatures, and encryption/decryption. If we're
> > going
> > to go for a longer name, maybe "cryptography" would be more
> > appropriate?
>
> Something to keep in mind while working on this is your threat model for
> the library. If you aren't going to do anything to guard against
> side-channel attacks (which are rather hard to avoid in a cross platform
> algorithm on a general purpose PC) or against attacks which grab
> unencrypted messages and keys from released-but-not-overwritten computer
> memory or (worse) the swap file, then this should be mentioned in the
> documentation.
>
> That way application developers that are looking for that extra level of
> security will know they need to look elsewhere.
>
> Regards,
> Nick.
>

I can make a note of it, although I'm unsure what concrete steps I could
take to prevent such attacks from succeeding. Any ideas?

Geremy Condra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090925/b53c9375/attachment.html>

From ncoghlan at gmail.com  Sat Sep 26 04:35:23 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Sep 2009 12:35:23 +1000
Subject: [Python-ideas] adding digital signature and encryption "hashes"
 to hashlib?
In-Reply-To: <f3cc57c60909251916g31eaa67en37022995563652da@mail.gmail.com>
References: <7922.1253233496@parc.com> <19693.1253547829@parc.com>	
	<65cae9b9-3417-4f46-a7bb-fdd127c93387@v2g2000vbb.googlegroups.com>	
	<28161.1253569055@parc.com>
	<loom.20090925T133504-900@post.gmane.org>	
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>	
	<h9iql8$h7e$1@ger.gmane.org>	
	<79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>	
	<e3d004ea-7db4-4bc0-9ea4-2ae458798ecb@s6g2000vbp.googlegroups.com>	
	<4ABD7327.6090206@gmail.com>
	<f3cc57c60909251916g31eaa67en37022995563652da@mail.gmail.com>
Message-ID: <4ABD7DEB.3050700@gmail.com>

geremy condra wrote:
> 
> 
> On Fri, Sep 25, 2009 at 9:49 PM, Nick Coghlan <ncoghlan at gmail.com
> <mailto:ncoghlan at gmail.com>> wrote:
> 
>     CTO wrote:
>     > EVP covers hashing, signatures, and encryption/decryption. If we're
>     > going
>     > to go for a longer name, maybe "cryptography" would be more
>     > appropriate?
> 
>     Something to keep in mind while working on this is your threat model for
>     the library. If you aren't going to do anything to guard against
>     side-channel attacks (which are rather hard to avoid in a cross platform
>     algorithm on a general purpose PC) or against attacks which grab
>     unencrypted messages and keys from released-but-not-overwritten computer
>     memory or (worse) the swap file, then this should be mentioned in the
>     documentation.
> 
>     That way application developers that are looking for that extra level of
>     security will know they need to look elsewhere.
> 
>     Regards,
>     Nick.
> 
> 
> I can make a note of it, although I'm unsure what concrete steps I could
> take to prevent such attacks from succeeding. Any ideas?

OpenSSL may actually guard against of the first part already. I'm unsure
about the second part though. And I don't know enough about the problems
to know how to fix them either - I just know when I'm theoretically
leaving these attack vectors open and make sure to defend them by other
means (such as physically securing the affected networks).

But it's this kind of stuff that people are talking about when they
point out that practical crypto is harder than just using good algorithms.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From debatem1 at gmail.com  Sat Sep 26 06:01:49 2009
From: debatem1 at gmail.com (geremy condra)
Date: Sat, 26 Sep 2009 00:01:49 -0400
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <4ABD7DEB.3050700@gmail.com>
References: <7922.1253233496@parc.com> <28161.1253569055@parc.com>
	<loom.20090925T133504-900@post.gmane.org>
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>
	<h9iql8$h7e$1@ger.gmane.org>
	<79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>
	<e3d004ea-7db4-4bc0-9ea4-2ae458798ecb@s6g2000vbp.googlegroups.com>
	<4ABD7327.6090206@gmail.com>
	<f3cc57c60909251916g31eaa67en37022995563652da@mail.gmail.com>
	<4ABD7DEB.3050700@gmail.com>
Message-ID: <f3cc57c60909252101l242749f0maa5b72b6223fd1c8@mail.gmail.com>

On Fri, Sep 25, 2009 at 10:35 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> geremy condra wrote:
> >
> >
> > On Fri, Sep 25, 2009 at 9:49 PM, Nick Coghlan <ncoghlan at gmail.com
> > <mailto:ncoghlan at gmail.com>> wrote:
> >
> >     CTO wrote:
> >     > EVP covers hashing, signatures, and encryption/decryption. If we're
> >     > going
> >     > to go for a longer name, maybe "cryptography" would be more
> >     > appropriate?
> >
> >     Something to keep in mind while working on this is your threat model
> for
> >     the library. If you aren't going to do anything to guard against
> >     side-channel attacks (which are rather hard to avoid in a cross
> platform
> >     algorithm on a general purpose PC) or against attacks which grab
> >     unencrypted messages and keys from released-but-not-overwritten
> computer
> >     memory or (worse) the swap file, then this should be mentioned in the
> >     documentation.
> >
> >     That way application developers that are looking for that extra level
> of
> >     security will know they need to look elsewhere.
> >
> >     Regards,
> >     Nick.
> >
> >
> > I can make a note of it, although I'm unsure what concrete steps I could
> > take to prevent such attacks from succeeding. Any ideas?
>
> OpenSSL may actually guard against of the first part already. I'm unsure
> about the second part though. And I don't know enough about the problems
> to know how to fix them either - I just know when I'm theoretically
> leaving these attack vectors open and make sure to defend them by other
> means (such as physically securing the affected networks).
>
> But it's this kind of stuff that people are talking about when they
> point out that practical crypto is harder than just using good algorithms.
>
> Cheers,
> Nick.


It seems to me that most timing attacks should already be out, so I'm not
*too* worried about that- but I have literally no idea how to stop the
secrets
from being dropped into swap in this context. I think what I'm going to do
is just make a note of it in the docs for the module and make sure that
there's enough contact info in there to ensure that anybody reviewing the
code can let me know if we're doing something stupid.

And on that note: since most of my knowledge of crypto is theoretical
in nature, I'm going to be leaning a lot on those of you with more
practical experience as we go forward with this.
Therefore, for everybody reading this list- please,
*review the code*! If you think there's a problem, assume
you're right and let me know- we really, really, really do not want
half-baked crypto in the standard lib. Assuming that's even
where this is headed.

Geremy Condra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090926/b5fe74cb/attachment.html>

From debatem1 at gmail.com  Sat Sep 26 07:06:52 2009
From: debatem1 at gmail.com (geremy condra)
Date: Sat, 26 Sep 2009 01:06:52 -0400
Subject: [Python-ideas] adding digital signature and encryption "hashes"
	to hashlib?
In-Reply-To: <f3cc57c60909252101l242749f0maa5b72b6223fd1c8@mail.gmail.com>
References: <7922.1253233496@parc.com>
	<loom.20090925T133504-900@post.gmane.org>
	<24a3074e-0860-496b-8062-cf467b4ffddc@r31g2000vbi.googlegroups.com>
	<h9iql8$h7e$1@ger.gmane.org>
	<79990c6b0909251045w67643731j93bf8f694ae1bb32@mail.gmail.com>
	<e3d004ea-7db4-4bc0-9ea4-2ae458798ecb@s6g2000vbp.googlegroups.com>
	<4ABD7327.6090206@gmail.com>
	<f3cc57c60909251916g31eaa67en37022995563652da@mail.gmail.com>
	<4ABD7DEB.3050700@gmail.com>
	<f3cc57c60909252101l242749f0maa5b72b6223fd1c8@mail.gmail.com>
Message-ID: <f3cc57c60909252206y33252ce1kb0f23c5ae50759bc@mail.gmail.com>

On Sat, Sep 26, 2009 at 12:01 AM, geremy condra <debatem1 at gmail.com> wrote:

>
>
> On Fri, Sep 25, 2009 at 10:35 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> geremy condra wrote:
>> >
>> >
>> > On Fri, Sep 25, 2009 at 9:49 PM, Nick Coghlan <ncoghlan at gmail.com
>> > <mailto:ncoghlan at gmail.com>> wrote:
>> >
>> >     CTO wrote:
>> >     > EVP covers hashing, signatures, and encryption/decryption. If
>> we're
>> >     > going
>> >     > to go for a longer name, maybe "cryptography" would be more
>> >     > appropriate?
>> >
>> >     Something to keep in mind while working on this is your threat model
>> for
>> >     the library. If you aren't going to do anything to guard against
>> >     side-channel attacks (which are rather hard to avoid in a cross
>> platform
>> >     algorithm on a general purpose PC) or against attacks which grab
>> >     unencrypted messages and keys from released-but-not-overwritten
>> computer
>> >     memory or (worse) the swap file, then this should be mentioned in
>> the
>> >     documentation.
>> >
>> >     That way application developers that are looking for that extra
>> level of
>> >     security will know they need to look elsewhere.
>> >
>> >     Regards,
>> >     Nick.
>> >
>> >
>> > I can make a note of it, although I'm unsure what concrete steps I could
>> > take to prevent such attacks from succeeding. Any ideas?
>>
>> OpenSSL may actually guard against of the first part already. I'm unsure
>> about the second part though. And I don't know enough about the problems
>> to know how to fix them either - I just know when I'm theoretically
>> leaving these attack vectors open and make sure to defend them by other
>> means (such as physically securing the affected networks).
>>
>> But it's this kind of stuff that people are talking about when they
>> point out that practical crypto is harder than just using good algorithms.
>>
>> Cheers,
>> Nick.
>
>
> It seems to me that most timing attacks should already be out, so I'm not
> *too* worried about that- but I have literally no idea how to stop the
> secrets
> from being dropped into swap in this context. I think what I'm going to do
> is just make a note of it in the docs for the module and make sure that
> there's enough contact info in there to ensure that anybody reviewing the
> code can let me know if we're doing something stupid.
>
> And on that note: since most of my knowledge of crypto is theoretical
> in nature, I'm going to be leaning a lot on those of you with more
> practical experience as we go forward with this.
> Therefore, for everybody reading this list- please,
> *review the code*! If you think there's a problem, assume
> you're right and let me know- we really, really, really do not want
> half-baked crypto in the standard lib. Assuming that's even
> where this is headed.
>
> Geremy Condra
>

Added the notice to the top of aes.c.

Geremy Condra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090926/89841da4/attachment.html>

From stephen at xemacs.org  Sat Sep 26 08:32:06 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 26 Sep 2009 15:32:06 +0900
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <20090925190759.3d817a15@bhuda.mired.org>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
	<200909250854.10218.steve@pearwood.info>
	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
	<20090924205231.67c229e7@bhuda.mired.org>
	<87d45focq7.fsf@uwakimon.sk.tsukuba.ac.jp>
	<20090925190759.3d817a15@bhuda.mired.org>
Message-ID: <87r5tumd21.fsf@uwakimon.sk.tsukuba.ac.jp>

Mike Meyer writes:

 > The idea that ordering multidimensional sets matters is simply
 > wrong.

Urk, I replied to this off-list.  Just as well, we're way off-topic,
and I can't see how to get back to it from here.  Suffice it to say
that I stand by what I wrote and I disagree with the above (and most
of the following discussion which depends on it).

The detailed reply is available to anybody who cares to ask for it.
Don't crash my MX, please. :-)



From lie.1296 at gmail.com  Sat Sep 26 18:15:23 2009
From: lie.1296 at gmail.com (Lie Ryan)
Date: Sun, 27 Sep 2009 02:15:23 +1000
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <e9764b730909220418v3e2bcb2ch92975252145ef3aa@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>	<200909201000.34945.steve@pearwood.info>	<e9764b730909191733k5bf9f023x1cf30b7cec26634e@mail.gmail.com>	<200909221019.51549.steve@pearwood.info>
	<e9764b730909220418v3e2bcb2ch92975252145ef3aa@mail.gmail.com>
Message-ID: <h9len4$p7v$1@ger.gmane.org>

Dj Gilcrease wrote:
> On Mon, Sep 21, 2009 at 6:19 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> It sounds like what you want is a framework for hiding the complexity of
>> runtime type checkers from the developer. I don't think there's any
>> need for new syntax beyond decorators and the type annotations added to
>> Python 3. Type annotations give you a way of declaring types of
>> arguments and return results. Although such declarations are currently
>> ignored by Python, you can write code to enforce them, and decorators
>> give you a neat syntax for applying that code to your functions without
>> having to explicitly include the type checks inside the function body.
>> You can also do the same with metaclasses.
> 
> Ya but decorators, metaclasses and annotations dont address class
> attributes, or module level variables, which you should be able to
> type check on assignment, but you need to do it on use.

property()?



From arnodel at googlemail.com  Sat Sep 26 22:12:35 2009
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Sat, 26 Sep 2009 21:12:35 +0100
Subject: [Python-ideas] [Wild Idea] Static Ducks
In-Reply-To: <5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
References: <e9764b730909190119x4cad141fmb0a03f32ed415cc5@mail.gmail.com>
	<200909240940.23776.steve@pearwood.info>
	<2F4E9EDF-421F-4E94-91FC-D2EDAB964472@masklinn.net>
	<200909250854.10218.steve@pearwood.info>
	<5d1a32000909241706s3de08344xb471dbb99d31953e@mail.gmail.com>
Message-ID: <9447140F-FD13-497B-B0F9-2BCE7D28BFDF@googlemail.com>


On 25 Sep 2009, at 01:06, Gerald Britton wrote:

> I think that the idea that there is a continuum from weak typing to
> strong typing is useful.  At the weak end, the compiler lets you do
> anything with anything without any declarations.  At the strong end,
> you have to declare everything and explicitly code all type
> conversions.

IIRC (15+ years...), in some ML variants you need no type declaration  
but there are no implicit type conversions either.

-- 
Arnaud




From tjreedy at udel.edu  Sun Sep 27 03:58:24 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 26 Sep 2009 21:58:24 -0400
Subject: [Python-ideas] Why is there a callable predicate,
	but no  iterable?
In-Reply-To: <h9jdkg$eqa$1@ger.gmane.org>
References: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>	<5d1a32000909250739y69a43da0jc8aa80b6bab776dc@mail.gmail.com>	<7659cab30909250742na2e3917i71a90dbc5ec7f93e@mail.gmail.com>	<h9j7is$r3o$1@ger.gmane.org>
	<h9jdkg$eqa$1@ger.gmane.org>
Message-ID: <h9mgs2$9l6$1@ger.gmane.org>

Georg Brandl wrote:
> Terry Reedy schrieb:
>> Andrey Fedorov wrote:
>>
>>> What is the tradeoff between hasattr(f, '__call__')
>> I know about that ;-)
>>
>>> and isinstance(f, Callable)?
>> New to me ;-)
>> I presume it needs an import.

I checked, and it does.

>> I presume it also requires that something be registered as a Callable.
> 
> Nope; it uses the new instance/subclass inquiry hooks to pretend all objects
> having a __call__ attribute are instances of Callable.

Ok. I doubt 'instance inquiry hook' appears in the docs. I presume the 
documentation for the behavior is LibRef 8.3.1 and the table therein. It 
took me a few minutes to realize that "Abstract Methods" are the methods 
looked for in an isinstance enquiry and that "Mixin Methods" are the 
methods provided for 'free' when the ABC is used as a mixin (while the 
Abstract Methods must be explicitly instantiated). (Correct?) Perhaps 
this could be stated more directly just below the table.

There is no mention of ABC usage with issubclass, so I no idea what you 
mean there.

tjr



From g.brandl at gmx.net  Sun Sep 27 10:20:12 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 27 Sep 2009 10:20:12 +0200
Subject: [Python-ideas] Why is there a callable predicate,
	but no  iterable?
In-Reply-To: <h9mgs2$9l6$1@ger.gmane.org>
References: <7659cab30909250734v15d87064u4d797d9a61e3ec2a@mail.gmail.com>	<5d1a32000909250739y69a43da0jc8aa80b6bab776dc@mail.gmail.com>	<7659cab30909250742na2e3917i71a90dbc5ec7f93e@mail.gmail.com>	<h9j7is$r3o$1@ger.gmane.org>	<h9jdkg$eqa$1@ger.gmane.org>
	<h9mgs2$9l6$1@ger.gmane.org>
Message-ID: <h9n7c5$hel$1@ger.gmane.org>

Terry Reedy schrieb:
> Georg Brandl wrote:
>> Terry Reedy schrieb:
>>> Andrey Fedorov wrote:
>>>
>>>> What is the tradeoff between hasattr(f, '__call__')
>>> I know about that ;-)
>>>
>>>> and isinstance(f, Callable)?
>>> New to me ;-)
>>> I presume it needs an import.
> 
> I checked, and it does.
> 
>>> I presume it also requires that something be registered as a Callable.
>> 
>> Nope; it uses the new instance/subclass inquiry hooks to pretend all objects
>> having a __call__ attribute are instances of Callable.
> 
> Ok. I doubt 'instance inquiry hook' appears in the docs. I presume the 
> documentation for the behavior is LibRef 8.3.1 and the table therein. It 
> took me a few minutes to realize that "Abstract Methods" are the methods 
> looked for in an isinstance enquiry and that "Mixin Methods" are the 
> methods provided for 'free' when the ABC is used as a mixin (while the 
> Abstract Methods must be explicitly instantiated). (Correct?) Perhaps 
> this could be stated more directly just below the table.

Yes, that's correct, and it should indeed be noted there.

> There is no mention of ABC usage with issubclass, so I no idea what you 
> mean there.

It's best described in the PEP:
http://www.python.org/dev/peps/pep-3119/#overloading-isinstance-and-issubclass

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.



From esg at unife.it  Mon Sep 28 01:20:30 2009
From: esg at unife.it (Josef Eschgfaeller)
Date: Mon, 28 Sep 2009 01:20:30 +0200
Subject: [Python-ideas] filter
Message-ID: <344aa0b10909271620u5cf13535vde11fed45b63e7a7@mail.gmail.com>

It would be nice to have a syntax like

    [f(x) for x in u and cond(x)]

instead of list(map(f,filter(cond,u))).

For avoiding interference with a common and it could be

    [f(x) for x in u andcond cond(x)]

or perhaps

    [f(x) for x in u with cond(x)]

if this is not interfering.

Josef Eschgfaeller


From daniel at stutzbachenterprises.com  Mon Sep 28 01:23:51 2009
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Sun, 27 Sep 2009 18:23:51 -0500
Subject: [Python-ideas] filter
In-Reply-To: <344aa0b10909271620u5cf13535vde11fed45b63e7a7@mail.gmail.com>
References: <344aa0b10909271620u5cf13535vde11fed45b63e7a7@mail.gmail.com>
Message-ID: <eae285400909271623w2919e4f7hf063e6a88e883771@mail.gmail.com>

On Sun, Sep 27, 2009 at 6:20 PM, Josef Eschgfaeller <esg at unife.it> wrote:

> It would be nice to have a syntax like
>
>    [f(x) for x in u and cond(x)]
>

If I understand what you're asking for, Python already supports this.  The
syntax is:

[f(x) for x in u if cond(x)]

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090927/d0a98a0f/attachment.html>

From adam at atlas.st  Mon Sep 28 01:24:10 2009
From: adam at atlas.st (Adam Atlas)
Date: Sun, 27 Sep 2009 19:24:10 -0400
Subject: [Python-ideas] filter
In-Reply-To: <344aa0b10909271620u5cf13535vde11fed45b63e7a7@mail.gmail.com>
References: <344aa0b10909271620u5cf13535vde11fed45b63e7a7@mail.gmail.com>
Message-ID: <B0283CEC-54A3-420A-BDB0-FF1872DD8038@atlas.st>

How would that be different from [f(x) for x in u if cond(x)]?

- Adam


On 27 Sep 2009, at 19:20, Josef Eschgfaeller wrote:

> It would be nice to have a syntax like
>
>    [f(x) for x in u and cond(x)]
>
> instead of list(map(f,filter(cond,u))).
>
> For avoiding interference with a common and it could be
>
>    [f(x) for x in u andcond cond(x)]
>
> or perhaps
>
>    [f(x) for x in u with cond(x)]
>
> if this is not interfering.
>
> Josef Eschgfaeller
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



From debatem1 at gmail.com  Wed Sep 30 02:39:18 2009
From: debatem1 at gmail.com (CTO)
Date: Tue, 29 Sep 2009 17:39:18 -0700 (PDT)
Subject: [Python-ideas] bump version of openssl (was "adding digital
	signature and encryption 'hashes' to hashlib?")
Message-ID: <a36d4b63-a889-4224-bcec-ba06087689e5@t32g2000yqj.googlegroups.com>

Right now the version of openssl shipping with python is 9.8, where
version 1.0 was released some months back and provides access to
EVP_PKEY_CTX, which is useful in interacting with the public key
interface now provided by evp. Would it be possible to bump it up to
1.0, or is that prohibitively difficult?

Geremy Condra


From debatem1 at gmail.com  Wed Sep 30 02:41:39 2009
From: debatem1 at gmail.com (CTO)
Date: Tue, 29 Sep 2009 17:41:39 -0700 (PDT)
Subject: [Python-ideas] bump version of openssl (was "adding digital
	signature and encryption 'hashes' to hashlib?")
In-Reply-To: <a36d4b63-a889-4224-bcec-ba06087689e5@t32g2000yqj.googlegroups.com>
References: <a36d4b63-a889-4224-bcec-ba06087689e5@t32g2000yqj.googlegroups.com>
Message-ID: <325b3c16-2d89-4270-a32c-f116a9924283@s31g2000yqs.googlegroups.com>



On Sep 29, 8:39?pm, CTO <debat... at gmail.com> wrote:
> Right now the version of openssl shipping with python is 9.8, where
> version 1.0 was released some months back and provides access to
> EVP_PKEY_CTX, which is useful in interacting with the public key
> interface now provided by evp. Would it be possible to bump it up to
> 1.0, or is that prohibitively difficult?
>
> Geremy Condra

Cancel that, 1.0beta3 was released some months ago. Sorry for the
spam.

Geremy Condra