From robmadole at gmail.com  Thu Apr  1 17:15:59 2010
From: robmadole at gmail.com (Robert Madole)
Date: Thu, 1 Apr 2010 10:15:59 -0500
Subject: [Python-ideas] "on" statement
Message-ID: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>

So I just wrote my 1-gazillionth "if hasattr('method', my_object):" and wanted badly to write this.

	if 'method' on my_object:

I'm not the most experienced Python user, but as far as I can tell hasattr is the preferred way of checking if a method exists.

Please correct me if there is a better way, otherwise I'd like to see what everyone thinks about an "on" statement being added to the Python language.

Thanks,

Rob Madole

From ncoghlan at gmail.com  Thu Apr  1 17:47:58 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 02 Apr 2010 01:47:58 +1000
Subject: [Python-ideas] "on" statement
In-Reply-To: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
Message-ID: <4BB4C02E.9080809@gmail.com>

Robert Madole wrote:
> So I just wrote my 1-gazillionth "if hasattr('method', my_object):"
> and wanted badly to write this.
> 
> if 'method' on my_object:
> 
> I'm not the most experienced Python user, but as far as I can tell
> hasattr is the preferred way of checking if a method exists.
> 
> Please correct me if there is a better way

Most Python code should just assume the method is present and let the
AttributeError fly if it isn't.

If you genuinely need to check for presence of a method, then either
catching the AttributeError or using hasattr is fine.

This is a relatively rare requirement though, so the chance of getting
dedicated syntax (and a new keyword, no less!) to support it is
basically nil.

Cheers,
Nick.

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


From tjreedy at udel.edu  Thu Apr  1 19:50:08 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 01 Apr 2010 13:50:08 -0400
Subject: [Python-ideas] "on" statement
In-Reply-To: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
Message-ID: <hp2mch$2d1$1@dough.gmane.org>

On 4/1/2010 11:15 AM, Robert Madole wrote:
> So I just wrote my 1-gazillionth "if hasattr('method', my_object):" and wanted badly to write this.
>
> 	if 'method' on my_object:

If you do not need the superclass search provided by hasattr,

   if 'method' in my_object.__dict__:

 >>> '__add__' in int.__dict__
True

But I otherwise agree with Nick.

Terry Jan Reedy



From bruce at leapyear.org  Thu Apr  1 20:54:53 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Thu, 1 Apr 2010 11:54:53 -0700
Subject: [Python-ideas] "on" statement
In-Reply-To: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
Message-ID: <q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>

I think this is a great idea, but I would not want to introduce a new
keyword. How about

    foo is in bar     = hasattr(foo,bar)
    foo is not in bar = not hasattr(foo,bar)

But there are other common checks I do all the time that I would really like
to have shortcuts for. Here are ways to do them without new keywords:

    foo is class bar = isinstance(foo,bar)
    foo is from bar  = issubclass(foo,bar)
    foo is with bar  = type(foo) == type(bar)

Can we make an exception to the moratorium, just for today?

--- Bruce
http://www.vroospeak.com


On Thu, Apr 1, 2010 at 8:15 AM, Robert Madole <robmadole at gmail.com> wrote:

> So I just wrote my 1-gazillionth "if hasattr('method', my_object):" and
> wanted badly to write this.
>
>        if 'method' on my_object:
>
> I'm not the most experienced Python user, but as far as I can tell hasattr
> is the preferred way of checking if a method exists.
>
> Please correct me if there is a better way, otherwise I'd like to see what
> everyone thinks about an "on" statement being added to the Python language.
>
> Thanks,
>
> Rob Madole
> _______________________________________________
> 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/20100401/55c5ef00/attachment.html>

From python at mrabarnett.plus.com  Thu Apr  1 21:37:01 2010
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 01 Apr 2010 20:37:01 +0100
Subject: [Python-ideas] "on" statement
In-Reply-To: <q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
Message-ID: <4BB4F5DD.5050305@mrabarnett.plus.com>

Bruce Leban wrote:
> I think this is a great idea, but I would not want to introduce a new 
> keyword. How about
> 
>     foo is in bar     = hasattr(foo,bar)
>     foo is not in bar = not hasattr(foo,bar)
> 
> But there are other common checks I do all the time that I would really 
> like to have shortcuts for. Here are ways to do them without new keywords:
> 
>     foo is class bar = isinstance(foo,bar)

To me, this is asking whether 'foo' is a class. Better would be:

     foo in class bar

>     foo is from bar  = issubclass(foo,bar)

Perhaps:

     foo from class bar

(although I'm not happy with it.)

>     foo is with bar  = type(foo) == type(bar)
> 
> Can we make an exception to the moratorium, just for today?
> 
Only for foolish ideas. :-)

> --- Bruce
> http://www.vroospeak.com
> 
> 
> On Thu, Apr 1, 2010 at 8:15 AM, Robert Madole <robmadole at gmail.com 
> <mailto:robmadole at gmail.com>> wrote:
> 
>     So I just wrote my 1-gazillionth "if hasattr('method', my_object):"
>     and wanted badly to write this.
> 
>            if 'method' on my_object:
> 
>     I'm not the most experienced Python user, but as far as I can tell
>     hasattr is the preferred way of checking if a method exists.
> 
>     Please correct me if there is a better way, otherwise I'd like to
>     see what everyone thinks about an "on" statement being added to the
>     Python language.
> 
>     Thanks,
> 
>     Rob Madole
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org <mailto: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



From robmadole at gmail.com  Thu Apr  1 21:46:30 2010
From: robmadole at gmail.com (Robert Madole)
Date: Thu, 1 Apr 2010 14:46:30 -0500
Subject: [Python-ideas] "on" statement
In-Reply-To: <q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
Message-ID: <A4067FBD-792D-49E3-BB31-554794F85891@gmail.com>

I'm new to the list, so give me some time to grok why "new statement/keyword" is a Bad Idea.  I'll refrain from the usual, "It's just a new statement, what's so bad about that" so you guys don't have to scold me.  I suspect the reason relates to bloating the core language :D

I think the in statement already hooks into __contains__.  So I don't think using "foo is in bar" would work.  That already exists and means something else.

I forgot about the try / catch approach.  I will use this, as I think it's more Pythonic?

As far as using class, from, or with; overloading existing keywords seems a bit dangerous.

At this point and the more I think about it, I feel pretty convinced it's a bad idea.

On Apr 1, 2010, at 1:54 PM, Bruce Leban wrote:

> I think this is a great idea, but I would not want to introduce a new keyword. How about
> 
>     foo is in bar     = hasattr(foo,bar)
>     foo is not in bar = not hasattr(foo,bar)
> 
> But there are other common checks I do all the time that I would really like to have shortcuts for. Here are ways to do them without new keywords:
> 
>     foo is class bar = isinstance(foo,bar)
>     foo is from bar  = issubclass(foo,bar)
>     foo is with bar  = type(foo) == type(bar)
> 
> Can we make an exception to the moratorium, just for today?
> 
> --- Bruce
> http://www.vroospeak.com
> 
> 
> On Thu, Apr 1, 2010 at 8:15 AM, Robert Madole <robmadole at gmail.com> wrote:
> So I just wrote my 1-gazillionth "if hasattr('method', my_object):" and wanted badly to write this.
> 
>        if 'method' on my_object:
> 
> I'm not the most experienced Python user, but as far as I can tell hasattr is the preferred way of checking if a method exists.
> 
> Please correct me if there is a better way, otherwise I'd like to see what everyone thinks about an "on" statement being added to the Python language.
> 
> Thanks,
> 
> Rob Madole
> _______________________________________________
> 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/20100401/0d3fe165/attachment.html>

From phd at phd.pp.ru  Thu Apr  1 21:04:54 2010
From: phd at phd.pp.ru (Oleg Broytman)
Date: Thu, 1 Apr 2010 23:04:54 +0400
Subject: [Python-ideas] "on" statement
In-Reply-To: <q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
Message-ID: <20100401190454.GA21398@phd.pp.ru>

On Thu, Apr 01, 2010 at 11:54:53AM -0700, Bruce Leban wrote:
>     foo is in bar     = hasattr(foo,bar)

   foo is in bar

is currently a valid and widely used expression. It means
bar.__contains__(foo).

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.


From robert.kern at gmail.com  Thu Apr  1 22:06:18 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 01 Apr 2010 15:06:18 -0500
Subject: [Python-ideas] "on" statement
In-Reply-To: <20100401190454.GA21398@phd.pp.ru>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
	<20100401190454.GA21398@phd.pp.ru>
Message-ID: <hp2ubr$av$1@dough.gmane.org>

On 2010-04-01 14:04 PM, Oleg Broytman wrote:
> On Thu, Apr 01, 2010 at 11:54:53AM -0700, Bruce Leban wrote:
>>      foo is in bar     = hasattr(foo,bar)
>
>     foo is in bar
>
> is currently a valid and widely used expression. It means
> bar.__contains__(foo).

No, it's not.

 >>> 1 is in range(5)
   File "<stdin>", line 1
     1 is in range(5)
           ^
SyntaxError: invalid syntax

-- 
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 phd at phd.pp.ru  Thu Apr  1 22:29:45 2010
From: phd at phd.pp.ru (Oleg Broytman)
Date: Fri, 2 Apr 2010 00:29:45 +0400
Subject: [Python-ideas] "on" statement
In-Reply-To: <hp2ubr$av$1@dough.gmane.org>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
	<20100401190454.GA21398@phd.pp.ru> <hp2ubr$av$1@dough.gmane.org>
Message-ID: <20100401202945.GB21398@phd.pp.ru>

On Thu, Apr 01, 2010 at 03:06:18PM -0500, Robert Kern wrote:
> On 2010-04-01 14:04 PM, Oleg Broytman wrote:
>> On Thu, Apr 01, 2010 at 11:54:53AM -0700, Bruce Leban wrote:
>>>      foo is in bar     = hasattr(foo,bar)
>>
>>     foo is in bar
>>
>> is currently a valid and widely used expression. It means
>> bar.__contains__(foo).
>
> No, it's not.
>
> >>> 1 is in range(5)
>   File "<stdin>", line 1
>     1 is in range(5)
>           ^
> SyntaxError: invalid syntax

   Ah, sorry, you are right. But that shows why the proposed syntax is bad
- it's too similar to an existing one.

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.


From george.sakkis at gmail.com  Thu Apr  1 22:54:53 2010
From: george.sakkis at gmail.com (George Sakkis)
Date: Thu, 1 Apr 2010 22:54:53 +0200
Subject: [Python-ideas] "on" statement
In-Reply-To: <q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
Message-ID: <i2y91ad5bf81004011354n7af01793x86348fe66660231a@mail.gmail.com>

On Thu, Apr 1, 2010 at 8:54 PM, Bruce Leban <bruce at leapyear.org> wrote:

> I think this is a great idea, but I would not want to introduce a new
> keyword. How about
> ?? ?foo is in bar ? ? = hasattr(foo,bar)
> ?? ?foo is not in bar = not hasattr(foo,bar)
> But there are other common checks I do all the time that I would really like
> to have shortcuts for. Here are ways to do them without new keywords:
> ?? ?foo is class bar = isinstance(foo,bar)
> ?? ?foo is from bar ?= issubclass(foo,bar)
> ?? ?foo is with bar ?= type(foo) == type(bar)
> Can we make an exception to the moratorium, just for today?

I hope so! I'm tossing in a few more suggestions that would make some
idioms more intuitive:

* iterable except for item  := (x for x in iterable if x!=item)

* pass from iterable := for i in iterable: pass

* global return value := sys.exit(value)

* import obj in module as name

   import module
   setattr(module, name, obj)
   del module

* not raise:
      BLOCK

     try: BLOCK
     except: pass

* with x as is:
        BLOCK

    _x = deepcopy(x)
    try:
        BLOCK
    finally:
        x = _x; del _x

*  try for i in iterable:
        BLOCK1
    else:
        BLOCK2

    for i in iterable:
        try: BLOCK1; break
        except: pass
    else:
        BLOCK2


George


From tjreedy at udel.edu  Fri Apr  2 00:34:27 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 01 Apr 2010 18:34:27 -0400
Subject: [Python-ideas] "on" statement
In-Reply-To: <A4067FBD-792D-49E3-BB31-554794F85891@gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
	<A4067FBD-792D-49E3-BB31-554794F85891@gmail.com>
Message-ID: <hp371i$qpo$1@dough.gmane.org>

On 4/1/2010 3:46 PM, Robert Madole wrote:
> I'm new to the list, so give me some time to grok why "new
> statement/keyword" is a Bad Idea. I'll refrain from the usual, "It's
> just a new statement, what's so bad about that" so you guys don't have
> to scold me. I suspect the reason relates to bloating the core language :D

Yes, plus any keyword we would like to add is almost surely already 
being using as an indentifier by some code, which would almost surely be 
broken.



From g.brandl at gmx.net  Fri Apr  2 09:25:04 2010
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 02 Apr 2010 09:25:04 +0200
Subject: [Python-ideas] "on" statement
In-Reply-To: <i2y91ad5bf81004011354n7af01793x86348fe66660231a@mail.gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
	<i2y91ad5bf81004011354n7af01793x86348fe66660231a@mail.gmail.com>
Message-ID: <hp467k$37o$1@dough.gmane.org>

Am 01.04.2010 22:54, schrieb George Sakkis:

> I hope so! I'm tossing in a few more suggestions that would make some
> idioms more intuitive:


> * import obj in module as name
> 
>    import module
>    setattr(module, name, obj)
>    del module

My favorite!

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 greg.ewing at canterbury.ac.nz  Sun Apr  4 11:35:52 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 04 Apr 2010 21:35:52 +1200
Subject: [Python-ideas] "on" statement
In-Reply-To: <q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
Message-ID: <4BB85D78.202@canterbury.ac.nz>

Bruce Leban wrote:

>     foo is in bar     = hasattr(foo,bar)
>     foo is not in bar = not hasattr(foo,bar)
>     foo is class bar = isinstance(foo,bar)
>     foo is from bar  = issubclass(foo,bar)
>     foo is with bar  = type(foo) == type(bar)

+1. Also we must absolutely have

   foo is totally bar

for those *$&@*&(*@& moments we all experience while coding.

-- 
Greg


From tlesher at gmail.com  Sun Apr  4 16:55:10 2010
From: tlesher at gmail.com (Tim Lesher)
Date: Sun, 4 Apr 2010 10:55:10 -0400
Subject: [Python-ideas] "on" statement
In-Reply-To: <4BB85D78.202@canterbury.ac.nz>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>
	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
	<4BB85D78.202@canterbury.ac.nz>
Message-ID: <z2l9613db601004040755o70eccee1h580b6c60ed3148bd@mail.gmail.com>

On Sun, Apr 4, 2010 at 05:35, Greg Ewing <greg.ewing at canterbury.ac.nz>wrote:

> +1. Also we must absolutely have
>
>  foo is totally bar
>
> for those *$&@*&(*@& moments we all experience while coding.
>
>
Indeed.  On that note, I think I'm going to start implementing Google's
recently-announced Google Annotations Gallery as Python decorators.  I
actually did once implement their @noop...

http://google-opensource.blogspot.com/2010/03/google-annotations-gallery.html

-- 
Tim Lesher <tlesher at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100404/1be4e50a/attachment.html>

From cool-rr at cool-rr.com  Sun Apr  4 18:58:33 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Sun, 4 Apr 2010 18:58:33 +0200
Subject: [Python-ideas] generator.__add__
Message-ID: <w2ua422b72d1004040958hc9af6c0eyb29fa1a78e64134b@mail.gmail.com>

I'm still a bit confused by generators and generator expressions, but what
about making a `generator.__add__` method, that'll act like
`itertools.chain`?

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100404/fa205b55/attachment.html>

From masklinn at masklinn.net  Sun Apr  4 19:20:25 2010
From: masklinn at masklinn.net (Masklinn)
Date: Sun, 4 Apr 2010 19:20:25 +0200
Subject: [Python-ideas] generator.__add__
In-Reply-To: <w2ua422b72d1004040958hc9af6c0eyb29fa1a78e64134b@mail.gmail.com>
References: <w2ua422b72d1004040958hc9af6c0eyb29fa1a78e64134b@mail.gmail.com>
Message-ID: <073484EF-E7F6-47C9-A592-D6B3A309D634@masklinn.net>

On 4 Apr 2010, at 18:58 , cool-RR wrote:
> 
> I'm still a bit confused by generators and generator expressions, but what
> about making a `generator.__add__` method, that'll act like
> `itertools.chain`?
What would the use case be, and why couldn't you use itertools.chain or
generator.send for that?


From cool-rr at cool-rr.com  Sun Apr  4 19:34:15 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Sun, 4 Apr 2010 19:34:15 +0200
Subject: [Python-ideas] generator.__add__
In-Reply-To: <073484EF-E7F6-47C9-A592-D6B3A309D634@masklinn.net>
References: <w2ua422b72d1004040958hc9af6c0eyb29fa1a78e64134b@mail.gmail.com>
	<073484EF-E7F6-47C9-A592-D6B3A309D634@masklinn.net>
Message-ID: <z2ya422b72d1004041034y1f6eb0b0ybe92f7d0b26e4cae@mail.gmail.com>

On Sun, Apr 4, 2010 at 7:20 PM, Masklinn <masklinn at masklinn.net> wrote:

> On 4 Apr 2010, at 18:58 , cool-RR wrote:
> >
> > I'm still a bit confused by generators and generator expressions, but
> what
> > about making a `generator.__add__` method, that'll act like
> > `itertools.chain`?
>


> What would the use case be,


I'm not sure I understand your question. The same use case as for
`itertools,chain`: When you have several generators you want to iterate
over, one after another. (True, it might be not as good when you have more
than 2.)


> and why couldn't you use itertools.chain or
> generator.send for that?
>

I could use `itertools.chain`, but why type so much? I think if you have two
generators, g1 and g2, then it makes sense that g1 + g2 will be an iterator
that goes over the elements of both of them.

About `generator.send`, I don't understand how it's related. But I'm still
new to this.

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100404/1b91104f/attachment.html>

From stefan_ml at behnel.de  Sun Apr  4 21:17:59 2010
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 Apr 2010 21:17:59 +0200
Subject: [Python-ideas] "on" statement
In-Reply-To: <i2y91ad5bf81004011354n7af01793x86348fe66660231a@mail.gmail.com>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>
	<i2y91ad5bf81004011354n7af01793x86348fe66660231a@mail.gmail.com>
Message-ID: <hpaooj$m01$1@dough.gmane.org>

George Sakkis, 01.04.2010 22:54:
> * with x as is:
>          BLOCK
>
>      _x = deepcopy(x)
>      try:
>          BLOCK
>      finally:
>          x = _x; del _x

I think this use case is important enough to implement it immediately. 
However, since the moratorium is currently in place for Python, would it be 
ok to fork Python 3 to integrate it into the language? I propose Mython as 
the name of the fork. I also propose to drop the entire Subversion history, 
so that we can start using Mercurial instantaneously. That will greatly 
improve the freedom of Mython as a language.

Stefan



From robert.kern at gmail.com  Mon Apr  5 00:06:56 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Sun, 04 Apr 2010 17:06:56 -0500
Subject: [Python-ideas] "on" statement
In-Reply-To: <hpaooj$m01$1@dough.gmane.org>
References: <6F3D7915-78A9-4070-92D0-C9C6B6CE8A91@gmail.com>	<q2icf5b87741004011154w74670028i1bbb10bba6dee10d@mail.gmail.com>	<i2y91ad5bf81004011354n7af01793x86348fe66660231a@mail.gmail.com>
	<hpaooj$m01$1@dough.gmane.org>
Message-ID: <hpb2j1$fjt$2@dough.gmane.org>

On 2010-04-04 14:17 , Stefan Behnel wrote:
> George Sakkis, 01.04.2010 22:54:
>> * with x as is:
>> BLOCK
>>
>> _x = deepcopy(x)
>> try:
>> BLOCK
>> finally:
>> x = _x; del _x
>
> I think this use case is important enough to implement it immediately.
> However, since the moratorium is currently in place for Python, would it
> be ok to fork Python 3 to integrate it into the language? I propose
> Mython as the name of the fork. I also propose to drop the entire
> Subversion history, so that we can start using Mercurial
> instantaneously. That will greatly improve the freedom of Mython as a
> language.

The name Mython is taken:

   http://mython.org/

However, you can use the existing Mython to implement this syntax pretty easily.

-- 
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 guido at python.org  Mon Apr  5 01:00:58 2010
From: guido at python.org (Guido van Rossum)
Date: Sun, 4 Apr 2010 16:00:58 -0700
Subject: [Python-ideas] generator.__add__
In-Reply-To: <w2ua422b72d1004040958hc9af6c0eyb29fa1a78e64134b@mail.gmail.com>
References: <w2ua422b72d1004040958hc9af6c0eyb29fa1a78e64134b@mail.gmail.com>
Message-ID: <k2ica471dc21004041600y16db9c01u77b6ba7171a21c40@mail.gmail.com>

On Sun, Apr 4, 2010 at 9:58 AM, cool-RR <cool-rr at cool-rr.com> wrote:
> I'm still a bit confused by generators and generator expressions, but what
> about making a `generator.__add__` method, that'll act like
> `itertools.chain`?

This gets proposed several times a year. We always shoot it down for
the same reasons: iterators are an abstract API and we don't want to
burden every iterator implementation with having to implement various
operations.

-- 
--Guido van Rossum (python.org/~guido)


From ncoghlan at gmail.com  Mon Apr  5 14:59:23 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 05 Apr 2010 22:59:23 +1000
Subject: [Python-ideas] generator.__add__
In-Reply-To: <k2ica471dc21004041600y16db9c01u77b6ba7171a21c40@mail.gmail.com>
References: <w2ua422b72d1004040958hc9af6c0eyb29fa1a78e64134b@mail.gmail.com>
	<k2ica471dc21004041600y16db9c01u77b6ba7171a21c40@mail.gmail.com>
Message-ID: <4BB9DEAB.7010409@gmail.com>

Guido van Rossum wrote:
> On Sun, Apr 4, 2010 at 9:58 AM, cool-RR <cool-rr at cool-rr.com> wrote:
>> I'm still a bit confused by generators and generator expressions, but what
>> about making a `generator.__add__` method, that'll act like
>> `itertools.chain`?
> 
> This gets proposed several times a year. We always shoot it down for
> the same reasons: iterators are an abstract API and we don't want to
> burden every iterator implementation with having to implement various
> operations.

I actually messed around with writing a FlexIter class once that wrapped
an arbitrary iterator and mapped __add__ to itertools.chain, __mul__ to
itertools.repeat and a few other things. It actually turned out to get
really ugly, really fast, so I abandoned the idea.

Making arbitrary iterators as easy to manipulate as lists is an
appealing idea, but a lot harder than it sounds given the deliberately
limited definition of the iterator protocol.

Cheers,
Nick.

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


From greg.ewing at canterbury.ac.nz  Tue Apr  6 02:15:59 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 06 Apr 2010 12:15:59 +1200
Subject: [Python-ideas] [Python-Dev] Scope object (Re: nonlocals()
	function?)
In-Reply-To: <loom.20100406T013348-190@post.gmane.org>
References: <w2mc44b91a81004030416ja6eaa225x23b9c91e16555513@mail.gmail.com>
	<loom.20100405T141421-155@post.gmane.org>
	<4BBA7427.8030601@canterbury.ac.nz>
	<loom.20100406T013348-190@post.gmane.org>
Message-ID: <4BBA7D3F.7050401@canterbury.ac.nz>

Antoine Pitrou wrote:

> It is useful to distinguish between globals (i.e., module-level variables) and
> locals, so replacing them with scope() would not be better IMO.

You have a point about globals(), so it probably makes
sense for it to stay.

I still think that it wouldn't hurt to subsume locals()
and the proposed nonlocals() into a single function
returning some kind of view object, though. But I
suppose we'd have to examine use cases before deciding
that.

The main use case I can think of is things like

   print "Your %(vehicle)s is full of %(fish)s" % locals()

where I can't see a good reason for restricting the
lookup to locals but not nonlocals, or even globals.

> If you can prove that making locals() (or its replacement) writable doesn't
> complicate the interpreter core too much, then why not. Otherwise -1 :-)

It shouldn't be hard to support changing the values
of *existing* names, which all that I really meant.
I wouldn't expect to be able to create new local
names through it.

-- 
Greg


From ysj.ray at gmail.com  Tue Apr  6 06:27:23 2010
From: ysj.ray at gmail.com (Ray Allen)
Date: Tue, 6 Apr 2010 12:27:23 +0800
Subject: [Python-ideas]  The 'instruction' event of python debugger
Message-ID: <s2g797c8cbd1004052127l4b9ada93l625ed70eea61d84f@mail.gmail.com>

Hi, all:

    I've been studying into python for a time. When I'm using the python
debugger, I found for the python code run step, the smallest granularity is
one single python source line(corresponding to the 'line' event in the
debugger implementation), that means we can stop at every python source line
and do something, for example, print an object, watch the stack, and so on.

    Sometimes I feel it's not small enough, I need another trace event:
instruction. This event occurs at every instruction execution, which means I
can stop my python program at every python instruction. I think it's useful
for software developers to debug their program at a very low level, and for
python learner to study how every python instruction works.

    How about adding this 'instruction' event type for python debugger? I
have implemented it in the python source, not difficult, only small changes.

-- 
Ray Allen
Best wishes!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100406/b2d4aca9/attachment.html>

From floris.bruynooghe at gmail.com  Thu Apr  8 22:47:46 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Thu, 8 Apr 2010 21:47:46 +0100
Subject: [Python-ideas] Testcase.assertsequenceequal() suggestion
Message-ID: <20100408204746.GA32050@laurie.devork>

Hi

I've found myself modifying the
unittest.TestCase.assertSequenceEqual() method to suppress the diff of
the two sequences if the diff is more then a few lines and was
wondering if this was something worth considering in the stdlib in
some form or another.  The resulting message still contains useful
information since it still prints the first differing elements, and it
avoids flooding the screen with lots of data for long sequences.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From fuzzyman at gmail.com  Fri Apr  9 00:15:32 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 8 Apr 2010 23:15:32 +0100
Subject: [Python-ideas] Testcase.assertsequenceequal() suggestion
In-Reply-To: <20100408204746.GA32050@laurie.devork>
References: <20100408204746.GA32050@laurie.devork>
Message-ID: <x2z6f4025011004081515k3f2f3dc0u16e5f66d6501090a@mail.gmail.com>

On 8 April 2010 21:47, Floris Bruynooghe <floris.bruynooghe at gmail.com>wrote:

> Hi
>
> I've found myself modifying the
> unittest.TestCase.assertSequenceEqual() method to suppress the diff of
> the two sequences if the diff is more then a few lines and was
> wondering if this was something worth considering in the stdlib in
> some form or another.  The resulting message still contains useful
> information since it still prints the first differing elements, and it
> avoids flooding the screen with lots of data for long sequences.
>


That sounds useful. Please post a feature request on the bug tracker -
preferably with a patch including tests.

All the best,

Michael Foord


>
> Regards
> Floris
>
> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> _______________________________________________
> 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/20100408/95ea1bad/attachment.html>

From raymond.hettinger at gmail.com  Fri Apr  9 00:33:53 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Thu, 8 Apr 2010 15:33:53 -0700
Subject: [Python-ideas] Testcase.assertsequenceequal() suggestion
In-Reply-To: <x2z6f4025011004081515k3f2f3dc0u16e5f66d6501090a@mail.gmail.com>
References: <20100408204746.GA32050@laurie.devork>
	<x2z6f4025011004081515k3f2f3dc0u16e5f66d6501090a@mail.gmail.com>
Message-ID: <8345A0A3-7EBB-4DBE-A1FB-0486C41BB33C@gmail.com>


On Apr 8, 2010, at 3:15 PM, Michael Foord wrote:

> 
> 
> On 8 April 2010 21:47, Floris Bruynooghe <floris.bruynooghe at gmail.com> wrote:
> Hi
> 
> I've found myself modifying the
> unittest.TestCase.assertSequenceEqual() method to suppress the diff of
> the two sequences if the diff is more then a few lines and was
> wondering if this was something worth considering in the stdlib in
> some form or another.  The resulting message still contains useful
> information since it still prints the first differing elements, and it
> avoids flooding the screen with lots of data for long sequences.
> 
> 
> That sounds useful. Please post a feature request on the bug tracker - preferably with a patch including tests.
> 

+1

Perhaps this can be considered a bug fix -- spewing a core dump in the test summary not considered helpful.


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100408/ea4ca025/attachment.html>

From fuzzyman at gmail.com  Fri Apr  9 00:48:28 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 8 Apr 2010 23:48:28 +0100
Subject: [Python-ideas] Testcase.assertsequenceequal() suggestion
In-Reply-To: <8345A0A3-7EBB-4DBE-A1FB-0486C41BB33C@gmail.com>
References: <20100408204746.GA32050@laurie.devork>
	<x2z6f4025011004081515k3f2f3dc0u16e5f66d6501090a@mail.gmail.com>
	<8345A0A3-7EBB-4DBE-A1FB-0486C41BB33C@gmail.com>
Message-ID: <l2p6f4025011004081548ibf9ee0d0x54220a3569693dfa@mail.gmail.com>

On 8 April 2010 23:33, Raymond Hettinger <raymond.hettinger at gmail.com>wrote:

>
> On Apr 8, 2010, at 3:15 PM, Michael Foord wrote:
>
>
>
> On 8 April 2010 21:47, Floris Bruynooghe <floris.bruynooghe at gmail.com>wrote:
>
>> Hi
>>
>> I've found myself modifying the
>> unittest.TestCase.assertSequenceEqual() method to suppress the diff of
>> the two sequences if the diff is more then a few lines and was
>> wondering if this was something worth considering in the stdlib in
>> some form or another.  The resulting message still contains useful
>> information since it still prints the first differing elements, and it
>> avoids flooding the screen with lots of data for long sequences.
>>
>
>
> That sounds useful. Please post a feature request on the bug tracker -
> preferably with a patch including tests.
>
>
> +1
>
> Perhaps this can be considered a bug fix -- spewing a core dump in the test
> summary not considered helpful.
>
>

I agree. Failure messages should be useful...

Michael



>
> Raymond
>



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

From floris.bruynooghe at gmail.com  Fri Apr  9 01:39:26 2010
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Fri, 9 Apr 2010 00:39:26 +0100
Subject: [Python-ideas] Testcase.assertsequenceequal() suggestion
In-Reply-To: <x2z6f4025011004081515k3f2f3dc0u16e5f66d6501090a@mail.gmail.com>
References: <20100408204746.GA32050@laurie.devork>
	<x2z6f4025011004081515k3f2f3dc0u16e5f66d6501090a@mail.gmail.com>
Message-ID: <20100408233926.GA12988@laurie.devork>

On Thu, Apr 08, 2010 at 11:15:32PM +0100, Michael Foord wrote:
> On 8 April 2010 21:47, Floris Bruynooghe <floris.bruynooghe at gmail.com>wrote:
> > I've found myself modifying the
> > unittest.TestCase.assertSequenceEqual() method to suppress the diff of
> > the two sequences if the diff is more then a few lines and was
> > wondering if this was something worth considering in the stdlib in
> > some form or another.  The resulting message still contains useful
> > information since it still prints the first differing elements, and it
> > avoids flooding the screen with lots of data for long sequences.
> 
> That sounds useful. Please post a feature request on the bug tracker -
> preferably with a patch including tests.

http://bugs.python.org/issue8351

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


From deniskolodin at gmail.com  Sun Apr 11 12:28:16 2010
From: deniskolodin at gmail.com (Denis Kolodin)
Date: Sun, 11 Apr 2010 14:28:16 +0400
Subject: [Python-ideas] CSV api with conversion
Message-ID: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com>

Hello!
My name is Denis Kolodin. I live in Russia, Tambov.
I was developing much time with C, Java, C#, R. But two month ago I'm using
Python.
It's really cool. Now, I move ALL my projects to it fully and have some
ideas which API's
extensions may will be useful.
The first thing I want to say about is an extension of CSV api. In R
language I could to set types for
the every column in a csv file. I propose to add a same function to the
Python's standard library.
Here it is (Python 3 version):

import csv
def reader2(csvfile, frame, *delimiter**=**';'*, **fmtparams):
    reader = csv.reader(csvfile, delimiter=delimiter, **fmtparams)
    for row in reader:
        l = min(len(row), len(frame))
        yield [frame[idx](row[idx]) for idx in range(l)]

This's generator function which converts an every column to the associated
type.
In *frame *argument you must to set tuple/list of functions which will uses
to
convert values in same positions of row from csv file. Frame looks like list
of types )))
By default it uses ';' delimiter to make float values conversion are
possible.

As a sample you have the csv file like:
*Any spam...; 1; 2.0; 3*

I've saved it to "sample.csv" :)

If you are using function reader in the standard "csv" module you get rows
as a list of strings :(
*>>> reader = csv.reader(open("sample.csv"), delimiter=";")*
*>>> print(next(reader))*
*['Any spam...', ' 1', ' 2.0', ' 3']*
*
*
*
It's not bad in certan situatiuons. But with "reader2" function you can get
a list with necessary types:

>>> reader = reader2(open("foodstuffs.csv"), (str, int, float, int))
>>> print(next(reader))
['Any spam...', 1, 2.0, 3]

Now you can work with items without extra conversions. [?]
I think it's good to add this function to the standard library. I've already
used it many times.
This function can be useful for many people who works with csv files.
And I suppose it conforms to "batteries included" philosophy.

What do you think about this extension?
Is it possible to add this function to standard library or to add the same
behavior to
the standard "readed" function
in "csv" Python's module?

Best Regards,
Denis Kolodin
Russia, Tambov
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100411/77658113/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 360.gif
Type: image/gif
Size: 453 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100411/77658113/attachment.gif>

From merwok at netwok.org  Mon Apr 12 12:24:57 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Mon, 12 Apr 2010 12:24:57 +0200
Subject: [Python-ideas] CSV api with conversion
In-Reply-To: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com>
References: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com>
Message-ID: <4BC2F4F9.6050008@netwok.org>

Hello list

This API would be very useful. (I?m using Python right know to filter 
hundreds of spreadsheets records. Loving it.)

Suggestions:
1) Name the argument ?converters? (it?s an iterable);
2) Make it a positional argument.

Related wish: Add an argument for a row factory. Default would be list, 
and use cases include using tuple, a named tuple class, or any custom 
callable.

Adding converters and rowfactory would remove the need for looping over 
CSV reader objects and manually using row and cell converters.

Cheers


From thomaspinckney3 at gmail.com  Tue Apr 13 03:36:40 2010
From: thomaspinckney3 at gmail.com (Tom Pinckney)
Date: Mon, 12 Apr 2010 21:36:40 -0400
Subject: [Python-ideas] max() allowed to take empty list
Message-ID: <836911FA-8165-43DB-9CB4-1A53F45EBE85@gmail.com>

Many functions are happy to take empty lists:

>>> map(lambda x: x, [])
[]
>>> filter(lambda x: x == 1, [])
[]
>>> sum(a)
0
>>> reduce(lambda x,y: x+y, [], 0)
0

But not max():

>>> max([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: max() arg is an empty sequence

Allowing max to return None would make a lot of functional style programming easier, instead of explicitly having to check for empty lists or ignoring exceptions.

None makes sense as a return value in many contexts. For example, hypothetical code like:

if max(values) >= 90: return True   # works even if values is []

thought not every case:

a / max(values)   # can't divide by None if values is []

From pyideas at rebertia.com  Tue Apr 13 03:52:33 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Mon, 12 Apr 2010 18:52:33 -0700
Subject: [Python-ideas] max() allowed to take empty list
In-Reply-To: <836911FA-8165-43DB-9CB4-1A53F45EBE85@gmail.com>
References: <836911FA-8165-43DB-9CB4-1A53F45EBE85@gmail.com>
Message-ID: <j2n50697b2c1004121852qd1c4f28h5836e19f8e604b04@mail.gmail.com>

On Mon, Apr 12, 2010 at 6:36 PM, Tom Pinckney <thomaspinckney3 at gmail.com> wrote:
> Many functions are happy to take empty lists:
<snip>
> But not max():
>
>>>> max([])
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> ValueError: max() arg is an empty sequence
>
> Allowing max to return None would make a lot of functional style programming easier, instead of explicitly having to check for empty lists or ignoring exceptions.
>
> None makes sense as a return value in many contexts. For example, hypothetical code like:
>
> if max(values) >= 90: return True ? # works even if values is []

No, actually it *doesn't* work. It makes no sense to try and compare
None to a number, and Python 3.x rightfully complains:
Python 3.1.1 (r311:74480, Feb  1 2010, 23:08:45)
>>> if None >= 90: pass
Traceback (most recent call last):
  File "prog.py", line 1, in <module>
    if None >= 90: pass
TypeError: unorderable types: NoneType() >= int()


Errors should never pass silently unless explicitly silenced, so
having None as a default fails on those grounds too.

Adding a 'default value' parameter to max() to be returned when the
iterable is empty would make slightly more sense.

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


From stephen at xemacs.org  Tue Apr 13 04:58:03 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 13 Apr 2010 11:58:03 +0900
Subject: [Python-ideas]  max() allowed to take empty list
In-Reply-To: <836911FA-8165-43DB-9CB4-1A53F45EBE85@gmail.com>
References: <836911FA-8165-43DB-9CB4-1A53F45EBE85@gmail.com>
Message-ID: <87bpdo3vpg.fsf@uwakimon.sk.tsukuba.ac.jp>

Tom Pinckney writes:

 > None makes sense as a return value in many contexts. For example,
 > hypothetical code like:
 > 
 > if max(values) >= 90: return True   # works even if values is []

As Chris pointed out, this doesn't work at all in Python 3.  But even
in Python 2, one of "max([]) >= bound" and "min([]) >= bound" must
fail to work correctly in terms of the mathematical limits for max and
min.  ">=" cannot know whether the "None" it sees was derived from
"max([])", and should be interpreted as -infinity, or if it was
derived from "min([])" and should be interpreted as +infinity.  (And
in fact it failed to error in Python 2 only because the comparison was
done on the basis of the address of the object in memory, which is
obviously pretty arbitrary, and in theory could even change from one
invocation of Python to the next.)

Since Python's built-in numbers don't support infinity, there's no way
for those functions to return the appropriate mathematical objects, so
they should error when given an empty sequence.


From dickinsm at gmail.com  Tue Apr 13 11:05:52 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 13 Apr 2010 10:05:52 +0100
Subject: [Python-ideas] max() allowed to take empty list
In-Reply-To: <j2n50697b2c1004121852qd1c4f28h5836e19f8e604b04@mail.gmail.com>
References: <836911FA-8165-43DB-9CB4-1A53F45EBE85@gmail.com>
	<j2n50697b2c1004121852qd1c4f28h5836e19f8e604b04@mail.gmail.com>
Message-ID: <v2k5c6f2a5d1004130205u4f076ee0lb5fc5f5ad2c68a4b@mail.gmail.com>

On Tue, Apr 13, 2010 at 2:52 AM, Chris Rebert <pyideas at rebertia.com> wrote:
> Adding a 'default value' parameter to max() to be returned when the
> iterable is empty would make slightly more sense.

This has been proposed (and rejected) before:

http://bugs.python.org/issue7153

Previous python-ideas thread:

http://mail.python.org/pipermail/python-ideas/2009-April/004107.html

The main problems (opportunities!) were:

(1) the API for max and min is already complicated (single iterable
argument versus multiple scalar arguments; 'key' parameter), and it's
difficult to see how to clearly extend the API to take a default value

(2) it wasn't clear whether it would make more sense to have a
'default' value---i.e., something that would be returned if the
iterable is empty, and completely ignored otherwise, or a 'start'
value---something that's added in to the mix of values in the
iterable, so that the result is effectively the max of <iterable> +
<[start]>.

Mark


From ncoghlan at gmail.com  Tue Apr 13 14:37:15 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 13 Apr 2010 22:37:15 +1000
Subject: [Python-ideas] max() allowed to take empty list
In-Reply-To: <87bpdo3vpg.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <836911FA-8165-43DB-9CB4-1A53F45EBE85@gmail.com>
	<87bpdo3vpg.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4BC4657B.2030003@gmail.com>

Stephen J. Turnbull wrote:
> Since Python's built-in numbers don't support infinity, there's no way
> for those functions to return the appropriate mathematical objects, so
> they should error when given an empty sequence.

Small correction there: "not all of Python's built-in numbers".

The bigger problem is that when using max() and min() the *type* of
value you're dealing with will usually matter. Returning None is almost
certainly wrong, but the functions otherwise have no idea what to return
if an empty sequence is supplied, since they don't know what the program
expected it to be a list *of* if it contains no values.

In line with what Mark posted, the API extension that probably makes the
most sense is to allow a bound to be specified in the call. For example:

x = min(seq, upper_bound=0)
x = min(seq, upper_bound=float('inf'))
x = max(seq, lower_bound=0)
x = max(seq, lower_bound=float('-inf'))

where the stated bound is included in the values to be compared.

This has some minor advantages over the alternatives, but would need
some genuine real world use cases to justify complicating the core API.
It also runs afoul of the language moratorium, and hence is off the
table for the immediate future.

Cheers,
Nick.

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


From conrad.irwin at googlemail.com  Tue Apr 13 23:36:24 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Tue, 13 Apr 2010 22:36:24 +0100
Subject: [Python-ideas] @return?
Message-ID: <4BC4E3D8.4050206@googlemail.com>

Dear All,

I have an idea, though the acceptability of it is a matter for debate.
It seems that this would be the appropriate place to post, but if not,
or if you've already tired of this proposal, sorry.

A common pattern when creating decorators is something of the form:

    def decorator(func):
        def wrapper(*args):
            func(modulate(args))
        return wrapper

This is surprisingly reminiscent of the kind of code decorators were
introduced to avoid:

    class Example(object):
        def method(cls, *args):
            modulate(args)
        method = classmethod(method)

The proposal is thus to introduce "@return" that returns the decorated
object, a hybrid of the behavior of the return statement and decorators.
I think the intended semantics are clear, providing you know the basics
of how decorators work:

    def decorator(func):
        @return
        def wrapper(*args):
            func(modulate(args))

Much as the class declaration was beautified to:

    def Example(object):
        @classmethod
        def method(cls, *args):
            modulate(args)

An alternative I considered, and rejected through ugliness, was allowing
a funcdef in a return statement:

    def decorator(func):
        return def wrapper(*args):
            func(modulate(args))

The syntax of "@return" has the advantage of matching the decorator
syntax, particularly beneficial given its most obvious use-case.

There are uglinesses though, a simplistic reading of "@return" would
imply the existence of a function called "return", and while the return
statement can be used with brackets, it certainly should not be turned
into a function. Also:

    from functools import wraps

    def decorator1(func):
        @return
        @wraps(func)
        def wrapper(*args):
            func(modulate(args))

    def decorator2(func):
        @wraps(func)  # Yuck! (not called, I think)
        @return
        def wrapper(*args):
            func(modulate(args))

Obviously, as this is currently a syntax error, there are few
backward-compatibility concerns, and many forward-compatibility issues.
If it were to be added, then a case might be made for allowing "@yield"
"@throw" (class decorator) and (along with yield, eventually, maybe)
"@continue".

Does anyone have thoughts they'd like to share, or shall I return to the
depths of obscurity from whence I came?

Yours
Conrad


From masklinn at masklinn.net  Tue Apr 13 23:51:30 2010
From: masklinn at masklinn.net (Masklinn)
Date: Tue, 13 Apr 2010 23:51:30 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC4E3D8.4050206@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
Message-ID: <8793C0BE-51CD-4BD4-9ACC-497286280EEA@masklinn.net>

On 13 Apr 2010, at 23:36 , Conrad Irwin wrote:
> 
> There are uglinesses though, a simplistic reading of "@return" would
> imply the existence of a function called "return", and while the return
> statement can be used with brackets, it certainly should not be turned
> into a function. Also:

So now there are two completely different language elements with the
exact same syntax and used in the exact same context?

Strangely enough, I don't see that working too well.

Trying to find a way to get anonymous functions ("full", in the defs
sense) into the language would probably be a better way to pass time.


From pyideas at rebertia.com  Wed Apr 14 00:18:11 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Tue, 13 Apr 2010 15:18:11 -0700
Subject: [Python-ideas] @return?
In-Reply-To: <4BC4E3D8.4050206@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
Message-ID: <s2m50697b2c1004131518sd576fe14n3346eec5067ef136@mail.gmail.com>

On Tue, Apr 13, 2010 at 2:36 PM, Conrad Irwin
<conrad.irwin at googlemail.com> wrote:
> Dear All,
>
> I have an idea, though the acceptability of it is a matter for debate.
> It seems that this would be the appropriate place to post, but if not,
> or if you've already tired of this proposal, sorry.
>
> A common pattern when creating decorators is something of the form:
>
> ? ?def decorator(func):
> ? ? ? ?def wrapper(*args):
> ? ? ? ? ? ?func(modulate(args))
> ? ? ? ?return wrapper
>
> This is surprisingly reminiscent of the kind of code decorators were
> introduced to avoid:
>
> ? ?class Example(object):
> ? ? ? ?def method(cls, *args):
> ? ? ? ? ? ?modulate(args)
> ? ? ? ?method = classmethod(method)
>
> The proposal is thus to introduce "@return" that returns the decorated
> object, a hybrid of the behavior of the return statement and decorators.
> I think the intended semantics are clear, providing you know the basics
> of how decorators work:
>
> ? ?def decorator(func):
> ? ? ? ?@return
> ? ? ? ?def wrapper(*args):
> ? ? ? ? ? ?func(modulate(args))
>
> Much as the class declaration was beautified to:
>
> ? ?def Example(object):
> ? ? ? ?@classmethod
> ? ? ? ?def method(cls, *args):
> ? ? ? ? ? ?modulate(args)
>
> An alternative I considered, and rejected through ugliness, was allowing
> a funcdef in a return statement:
>
> ? ?def decorator(func):
> ? ? ? ?return def wrapper(*args):
> ? ? ? ? ? ?func(modulate(args))
>
> The syntax of "@return" has the advantage of matching the decorator
> syntax, particularly beneficial given its most obvious use-case.
>
> There are uglinesses though, a simplistic reading of "@return" would
> imply the existence of a function called "return", and while the return
> statement can be used with brackets, it certainly should not be turned
> into a function. Also:
>
> ? ?from functools import wraps
>
> ? ?def decorator1(func):
> ? ? ? ?@return
> ? ? ? ?@wraps(func)
> ? ? ? ?def wrapper(*args):
> ? ? ? ? ? ?func(modulate(args))
>
> ? ?def decorator2(func):
> ? ? ? ?@wraps(func) ?# Yuck! (not called, I think)
> ? ? ? ?@return
> ? ? ? ?def wrapper(*args):
> ? ? ? ? ? ?func(modulate(args))
>
> Obviously, as this is currently a syntax error, there are few
> backward-compatibility concerns, and many forward-compatibility issues.
> If it were to be added, then a case might be made for allowing "@yield"
> "@throw" (class decorator) and (along with yield, eventually, maybe)
> "@continue".
>
> Does anyone have thoughts they'd like to share, or shall I return to the
> depths of obscurity from whence I came?

-0.75; Zen problems I see:

* Explicit is better than implicit.
    I for one prefer the explicit `return wrapper` and
    find it clearer than the proposed magical decorator.

* Special cases aren't special enough to break the rules.
    You're allowing keyword(s) where it/they would otherwise be illegal,
    which (1) looks strange and (2) begs the question of why keywords couldn't
    be used elsewhere (e.g. def if(...): ...), [and of course, as for allowing
    keywords everywhere, down that path lies madness!; not that that's
    part of your proposal, I'm just pointing out the slippery slope.]

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


From daniel at stutzbachenterprises.com  Wed Apr 14 00:41:53 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Tue, 13 Apr 2010 17:41:53 -0500
Subject: [Python-ideas] @return?
In-Reply-To: <4BC4E3D8.4050206@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
Message-ID: <t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>

On Tue, Apr 13, 2010 at 4:36 PM, Conrad Irwin
<conrad.irwin at googlemail.com>wrote:

> A common pattern when creating decorators is something of the form:
>
>    def decorator(func):
>        def wrapper(*args):
>            func(modulate(args))
>        return wrapper
>

You might be interested in Michele Simionato's excellent decorator package.
The above could be written:

import decorator
def my_decorator(func):
    return decorator.decorator(func, lambda: func(modulate(args)))

If your pattern is very common, you could even create your own
meta-decorator, like this:

def args_modulator(func, modulator):
    return decorator.decorator(func, lambda: func(modulator(args)))

It's available on PyPi:  http://pypi.python.org/pypi/decorator

In a nutshell, whatever part of your pattern is common, abstract out.
--
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/20100413/2ba3b2f7/attachment.html>

From conrad.irwin at googlemail.com  Wed Apr 14 02:23:08 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Wed, 14 Apr 2010 01:23:08 +0100
Subject: [Python-ideas] @return?
In-Reply-To: <t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
Message-ID: <4BC50AEC.8000901@googlemail.com>



On 04/13/2010 11:41 PM, Daniel Stutzbach wrote:
> On Tue, Apr 13, 2010 at 4:36 PM, Conrad Irwin
> <conrad.irwin at googlemail.com>wrote:
> 
>> A common pattern when creating decorators is something of the form:
>>
>>    def decorator(func):
>>        def wrapper(*args):
>>            func(modulate(args))
>>        return wrapper
>>
> 
> You might be interested in Michele Simionato's excellent decorator package.
> The above could be written:
> 
> import decorator
> def my_decorator(func):
>     return decorator.decorator(func, lambda: func(modulate(args)))
> 

Of course, everything is more succinct when a lambda can be used instead
of defining a new function; my proposal was to deal with the times when
this shorthand is not available.

As Masklinn suggests, perhaps it would be better to try and get full
anonymous blocks into Python; though I think that that is a futile task.
Naming all functions is very helpful (as anyone who has tried to analyze
call stacks with more than a few anonymous functions can testify) and
most uses I have for passing blocks around can be done adequately, if
unstylishly, with decorators.

On 04/13/2010 11:18 PM, Chris Rebert wrote:
> * Special cases aren't special enough to break the rules.
>     You're allowing keyword(s) where it/they would otherwise be illegal,
>     which (1) looks strange and (2) begs the question of why keywords
couldn't
>     be used elsewhere (e.g. def if(...): ...), [and of course, as for
allowing
>     keywords everywhere, down that path lies madness!; not that that's
>     part of your proposal, I'm just pointing out the slippery slope.]

This is indeed an issue, whatever change is needed it is clear that
"@return" is something new, and probably dangerous.

There are two ways (as I see it) of thinking about "@return". Firstly it
may be a glorified "return" that works on the function/class defined on
the next line (instead of the optional testlist on the current line).
Secondly it may be as a normal decorator, with the intended intuition
being that after the function definition is completed, a return is
executed with the defined function (just as for a decorator).

Syntactically there seems to be a minor debate to be had between
creating a new keyword '@return' and allowing 'return' after an '@'.
Maybe the choice of which is preferred depends on the perceived utility
of the presented intuitions. In either case, it would cause less
confusion to restrict an @return to by the first in the decorator list:

keyword_decorator: '@' ( 'return' | 'yield' | 'throw' ) NEWLINE
decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE
decorators: [ keyword_decorator ] decorator+

Though this does somewhat highlight the fact that it is not a normal
decorator, and perhaps an alternative syntax that makes this clearer
should be considered. I am not sure I can find anything more elegant.

Conrad


From daniel at stutzbachenterprises.com  Wed Apr 14 02:32:48 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Tue, 13 Apr 2010 19:32:48 -0500
Subject: [Python-ideas] @return?
In-Reply-To: <4BC50AEC.8000901@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com>
Message-ID: <g2leae285401004131732pc372a005g151aac719663d413@mail.gmail.com>

On Tue, Apr 13, 2010 at 7:23 PM, Conrad Irwin
<conrad.irwin at googlemail.com>wrote:

> > import decorator
> > def my_decorator(func):
> >     return decorator.decorator(func, lambda: func(modulate(args)))
>
> Of course, everything is more succinct when a lambda can be used instead
> of defining a new function; my proposal was to deal with the times when
> this shorthand is not available.
>

Actually, I wasn't thinking clearly earlier.  The correct code would be
simply:

@decorator.decorator
def my_decorator(func, *args, **kw):
    return func(modulate(args))

No lamba is needed, and you can make the inside of the wrapper as
complicated as you wish.
--
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/20100413/98b5e7cf/attachment.html>

From denis.spir at gmail.com  Wed Apr 14 16:54:21 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Wed, 14 Apr 2010 16:54:21 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC50AEC.8000901@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com>
Message-ID: <20100414165421.4d97a595@o>

On Wed, 14 Apr 2010 01:23:08 +0100
Conrad Irwin <conrad.irwin at googlemail.com> wrote:

> > You might be interested in Michele Simionato's excellent decorator package.
> > The above could be written:
> > 
> > import decorator
> > def my_decorator(func):
> >     return decorator.decorator(func, lambda: func(modulate(args)))
> >   
> 
> Of course, everything is more succinct when a lambda can be used instead
> of defining a new function; my proposal was to deal with the times when
> this shorthand is not available.

Well, i'm not 100% sure of the point of view below, but let's take the risk ;-) (Gentle)critics welcome.

As I see it, the issue you raise is more general than the precise point of a decorator's return value. It is instead deeply rooted in Python's core syntax making func/method  definitions (and classes, too) somewhat different. One doesn't write:

f = function(): <body>

So that one cannot write neither:

return function(): <body>

This point (together with the unneeded 'return' in this case) also raises the need for a special inline syntax for func defs used in higher-order functions --say for programming in functional style. This a bit of a pity because Python also offers a third syntax for similar semantics with list comprehensions.

As a counter-example just for reference, Lua's function defs are normal definitions, so that there are no such issues; "return function() <body>" is perfectly valid and even common; there is no need for special inline syntax.
But:
* An alternate pattern (function f() <body>) is available for named functions, while unnecessary (I personly never use it).
* Mainly because of the useless 'return', I guess, some users still argue for a more compact anonymous pattern.


Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From conrad.irwin at googlemail.com  Wed Apr 14 18:41:43 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Wed, 14 Apr 2010 17:41:43 +0100
Subject: [Python-ideas] @return?
In-Reply-To: <20100414165421.4d97a595@o>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>
	<20100414165421.4d97a595@o>
Message-ID: <4BC5F047.8060306@googlemail.com>


On 04/14/2010 03:54 PM, spir ? wrote:
> On Wed, 14 Apr 2010 01:23:08 +0100
> Well, i'm not 100% sure of the point of view below, but let's take the risk ;-) (Gentle)critics welcome.
> 
> As I see it, the issue you raise is more general than the precise point of a decorator's return value. It is instead deeply rooted in Python's core syntax making func/method  definitions (and classes, too) somewhat different. One doesn't write:
> 
> f = function(): <body>
> 
> So that one cannot write neither:
> 
> return function(): <body>
> 
> This point (together with the unneeded 'return' in this case) also raises the need for a special inline syntax for func defs used in higher-order functions --say for programming in functional style. This a bit of a pity because Python also offers a third syntax for similar semantics with list comprehensions.
> 
> As a counter-example just for reference, Lua's function defs are normal definitions, so that there are no such issues; "return function() <body>" is perfectly valid and even common; there is no need for special inline syntax.
> But:
> * An alternate pattern (function f() <body>) is available for named functions, while unnecessary (I personly never use it).
> * Mainly because of the useless 'return', I guess, some users still argue for a more compact anonymous pattern.
> 
> 
> Denis

As I understand it, there is little desire to allow function definitions
to appear "just anywhere" in Python. It seems to be more of an
aesthetics issue than a technical problem:

    result = register_callback(def success(arg):
                                   print(arg)
                              )

Could "work" (with some jiggling of the lexer), but it's not hugely
pleasant to read, and it gets even worse if you want to decorate the
function, or pass multiple functions. That said, I think it is
significantly nicer than the decorator abuse:

    @register_callback
    def result(arg):
        print(arg)

Concentrating on returning functions exclusively, it seems possible that

    return def foo(bar):
        baz()

    return def(bar):
        baz()

    return foo(bar):
        baz()

Could all work, the last is the least ugly (I think) but also the worst
in terms of answering the "where was foo defined" question. In this
case, the decorator "abuse" is much less of an abuse, mainly because
assigning the return value to something isn't needed:

    @return
    def foo(bar):
        baz()

Changing things so that return isn't necessary at all would also solve
the problem, and quite nicely, but I think that's a far-too-drastic
change in semantics. I suppose one could create a decorator that causes
the last calculation in the function to be returned, it seems a bit too
much like magic though.

Conrad


From tjreedy at udel.edu  Wed Apr 14 18:41:59 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 14 Apr 2010 12:41:59 -0400
Subject: [Python-ideas] @return?
In-Reply-To: <4BC4E3D8.4050206@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
Message-ID: <hq4r8l$977$1@dough.gmane.org>

On 4/13/2010 5:36 PM, Conrad Irwin wrote:
> Dear All,
>
> I have an idea, though the acceptability of it is a matter for debate.
> It seems that this would be the appropriate place to post, but if not,
> or if you've already tired of this proposal, sorry.
>
> A common pattern when creating decorators is something of the form:
>
>      def decorator(func):
>          def wrapper(*args):
>              func(modulate(args))
>          return wrapper
>
> This is surprisingly reminiscent of the kind of code decorators were
> introduced to avoid:
>
>      class Example(object):
>          def method(cls, *args):
>              modulate(args)
>          method = classmethod(method)

Except that a) the decorator is written once and used many times and b) 
there is no need for a long name within the decorator. Def w and return 
w would suffice. One of the motivations for decorators was the need in 
certain applications to repeatedly wrap long names, with the consequent 
tedium and ease of misspelling and diffuculty of proof-reading. 
Something like

def some_required_to_be_long_name(): reutrn 1
some_required_to_be_long_name = wrapper(some_required_to_be_long_name).

Terry Jan Reedy



From masklinn at masklinn.net  Wed Apr 14 19:45:34 2010
From: masklinn at masklinn.net (Masklinn)
Date: Wed, 14 Apr 2010 19:45:34 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC5F047.8060306@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>
	<20100414165421.4d97a595@o> <4BC5F047.8060306@googlemail.com>
Message-ID: <BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>

On 14 Apr 2010, at 18:41 , Conrad Irwin wrote
> On 04/14/2010 03:54 PM, spir ? wrote:
>> On Wed, 14 Apr 2010 01:23:08 +0100
>> Well, i'm not 100% sure of the point of view below, but let's take the risk ;-) (Gentle)critics welcome.
>> 
>> As I see it, the issue you raise is more general than the precise point of a decorator's return value. It is instead deeply rooted in Python's core syntax making func/method  definitions (and classes, too) somewhat different. One doesn't write:
>> 
>> f = function(): <body>
>> 
>> So that one cannot write neither:
>> 
>> return function(): <body>
>> 
>> This point (together with the unneeded 'return' in this case) also raises the need for a special inline syntax for func defs used in higher-order functions --say for programming in functional style. This a bit of a pity because Python also offers a third syntax for similar semantics with list comprehensions.
>> 
>> As a counter-example just for reference, Lua's function defs are normal definitions, so that there are no such issues; "return function() <body>" is perfectly valid and even common; there is no need for special inline syntax.
>> But:
>> * An alternate pattern (function f() <body>) is available for named functions, while unnecessary (I personly never use it).
>> * Mainly because of the useless 'return', I guess, some users still argue for a more compact anonymous pattern.
>> 
>> 
>> Denis
> 
> As I understand it, there is little desire to allow function definitions
> to appear "just anywhere" in Python.

I don't believe that's true, but it is possible that people who express
 this desire are directed towards other languages.

I can only speak for myself when I say that I'd kill for full-fledged 
anonymous defs (uncrippled lambdas, whatever you call them) in Python,
but the desire is most definitely there.



From python at mrabarnett.plus.com  Wed Apr 14 20:41:58 2010
From: python at mrabarnett.plus.com (MRAB)
Date: Wed, 14 Apr 2010 19:41:58 +0100
Subject: [Python-ideas] @return?
In-Reply-To: <BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
Message-ID: <4BC60C76.9080107@mrabarnett.plus.com>

Masklinn wrote:
> On 14 Apr 2010, at 18:41 , Conrad Irwin wrote
>> On 04/14/2010 03:54 PM, spir ? wrote:
>>> On Wed, 14 Apr 2010 01:23:08 +0100
>>> Well, i'm not 100% sure of the point of view below, but let's take the risk ;-) (Gentle)critics welcome.
>>>
>>> As I see it, the issue you raise is more general than the precise point of a decorator's return value. It is instead deeply rooted in Python's core syntax making func/method  definitions (and classes, too) somewhat different. One doesn't write:
>>>
>>> f = function(): <body>
>>>
>>> So that one cannot write neither:
>>>
>>> return function(): <body>
>>>
>>> This point (together with the unneeded 'return' in this case) also raises the need for a special inline syntax for func defs used in higher-order functions --say for programming in functional style. This a bit of a pity because Python also offers a third syntax for similar semantics with list comprehensions.
>>>
>>> As a counter-example just for reference, Lua's function defs are normal definitions, so that there are no such issues; "return function() <body>" is perfectly valid and even common; there is no need for special inline syntax.
>>> But:
>>> * An alternate pattern (function f() <body>) is available for named functions, while unnecessary (I personly never use it).
>>> * Mainly because of the useless 'return', I guess, some users still argue for a more compact anonymous pattern.
>>>
>>>
>>> Denis
>> As I understand it, there is little desire to allow function definitions
>> to appear "just anywhere" in Python.
> 
> I don't believe that's true, but it is possible that people who express
>  this desire are directed towards other languages.
> 
> I can only speak for myself when I say that I'd kill for full-fledged 
> anonymous defs (uncrippled lambdas, whatever you call them) in Python,
> but the desire is most definitely there.
> 
Part of the problem is finding a suitable syntax. Python's use of
indentation makes it difficult, and we don't want to give that up, do
we? :-)


From masklinn at masklinn.net  Wed Apr 14 20:54:59 2010
From: masklinn at masklinn.net (Masklinn)
Date: Wed, 14 Apr 2010 20:54:59 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC60C76.9080107@mrabarnett.plus.com>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC60C76.9080107@mrabarnett.plus.com>
Message-ID: <73193102-8838-459A-80D2-23B8271C15BA@masklinn.net>

On 14 Apr 2010, at 20:41 , MRAB wrote:
> 
> Masklinn wrote:
>> On 14 Apr 2010, at 18:41 , Conrad Irwin wrote
>>> On 04/14/2010 03:54 PM, spir ? wrote:
>>>> On Wed, 14 Apr 2010 01:23:08 +0100
>>>> Well, i'm not 100% sure of the point of view below, but let's take the risk ;-) (Gentle)critics welcome.
>>>> 
>>>> As I see it, the issue you raise is more general than the precise point of a decorator's return value. It is instead deeply rooted in Python's core syntax making func/method  definitions (and classes, too) somewhat different. One doesn't write:
>>>> 
>>>> f = function(): <body>
>>>> 
>>>> So that one cannot write neither:
>>>> 
>>>> return function(): <body>
>>>> 
>>>> This point (together with the unneeded 'return' in this case) also raises the need for a special inline syntax for func defs used in higher-order functions --say for programming in functional style. This a bit of a pity because Python also offers a third syntax for similar semantics with list comprehensions.
>>>> 
>>>> As a counter-example just for reference, Lua's function defs are normal definitions, so that there are no such issues; "return function() <body>" is perfectly valid and even common; there is no need for special inline syntax.
>>>> But:
>>>> * An alternate pattern (function f() <body>) is available for named functions, while unnecessary (I personly never use it).
>>>> * Mainly because of the useless 'return', I guess, some users still argue for a more compact anonymous pattern.
>>>> 
>>>> 
>>>> Denis
>>> As I understand it, there is little desire to allow function definitions
>>> to appear "just anywhere" in Python.
>> I don't believe that's true, but it is possible that people who express
>> this desire are directed towards other languages.
>> I can only speak for myself when I say that I'd kill for full-fledged anonymous defs (uncrippled lambdas, whatever you call them) in Python,
>> but the desire is most definitely there.
> Part of the problem is finding a suitable syntax. Python's use of
> indentation makes it difficult, and we don't want to give that up, do
> we? :-)
Indeed, but there's no reason why it should be unsolvable, Haskell manages to have lambdas even using offside syntax (though it has a few properties which probably make it easier to handle than in Python)



From denis.spir at gmail.com  Wed Apr 14 23:51:57 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Wed, 14 Apr 2010 23:51:57 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC5F047.8060306@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
Message-ID: <20100414235157.3ad38e9d@o>

On Wed, 14 Apr 2010 17:41:43 +0100
Conrad Irwin <conrad.irwin at googlemail.com> wrote:

> Changing things so that return isn't necessary at all would also solve
> the problem, and quite nicely, but I think that's a far-too-drastic
> change in semantics.

Well actually, in _many_ languages the last expression is taken as return value.
(Not only Lisp & friends, also pure OO ones like Io.)

Python 9000 ;-)

factorial = function(n):
    if n <= 1:
        1
    else:
        factorial(n-1)

cubes = map(numbers, function(x) x*x*x)

Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From ncoghlan at gmail.com  Wed Apr 14 23:52:20 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 15 Apr 2010 07:52:20 +1000
Subject: [Python-ideas] @return?
In-Reply-To: <BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
Message-ID: <4BC63914.7060206@gmail.com>

Masklinn wrote:
> On 14 Apr 2010, at 18:41 , Conrad Irwin wrote
>> As I understand it, there is little desire to allow function definitions
>> to appear "just anywhere" in Python.
> 
> I don't believe that's true, but it is possible that people who express
>  this desire are directed towards other languages.

Limit the scope to "the core devs" and Conrad's statement is probably
true :)

The problem is that:

1. Whitespace is highly significant in delineating scope and separation
at a statement level

2. Whitespace is largely insignificant at the expression level

That means that anonymous functions that are not limited to a single
expression require either:

a. the introduction of significant whitespace into a particular kind of
expression (ugly, breaks the back of the deliberately created
statement/expression distinction noted above)

or

b. the introduction of a full statement syntax which isn't dependent on
significant whitespace (which grossly violates There's One Obvious Way
To Do It)

The course most likely to bear fruit is actually for people to identify
what tools they need in the functools module in order to make Python
expressions Turing complete (you should be able to use functional
programming tricks to attain that without needing to introduce embedded
assignments).

Cheers,
Nick.

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


From grosser.meister.morti at gmx.net  Thu Apr 15 00:07:57 2010
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Thu, 15 Apr 2010 00:07:57 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63914.7060206@gmail.com>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC63914.7060206@gmail.com>
Message-ID: <4BC63CBD.1050905@gmx.net>

On 04/14/2010 11:52 PM, Nick Coghlan wrote:
> Masklinn wrote:
>> On 14 Apr 2010, at 18:41 , Conrad Irwin wrote
>>> As I understand it, there is little desire to allow function definitions
>>> to appear "just anywhere" in Python.
>>
>> I don't believe that's true, but it is possible that people who express
>>   this desire are directed towards other languages.
>
> Limit the scope to "the core devs" and Conrad's statement is probably
> true :)
>
> The problem is that:
>
> 1. Whitespace is highly significant in delineating scope and separation
> at a statement level
>
> 2. Whitespace is largely insignificant at the expression level
>

Maybe only allow them at certain places where they can be seen as an extension to an already 
existing statement syntax (not to an expression syntax):

foo.bar = def(egg, spam):
	pass

return def(egg, spam):
	pass

yield def(egg, spam):
	pass


Anyway, if you'd introduce @return (which I'm -1 about) you'd need also to introduce @yield.

	-panzi


From grosser.meister.morti at gmx.net  Thu Apr 15 00:11:52 2010
From: grosser.meister.morti at gmx.net (=?UTF-8?B?TWF0aGlhcyBQYW56ZW5iw7Zjaw==?=)
Date: Thu, 15 Apr 2010 00:11:52 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <20100414235157.3ad38e9d@o>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>
	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>
	<20100414235157.3ad38e9d@o>
Message-ID: <4BC63DA8.6060603@gmx.net>

On 04/14/2010 11:51 PM, spir ? wrote:
 > On Wed, 14 Apr 2010 17:41:43 +0100
 > Conrad Irwin<conrad.irwin at googlemail.com>  wrote:
 >
 >> Changing things so that return isn't necessary at all would also solve
 >> the problem, and quite nicely, but I think that's a far-too-drastic
 >> change in semantics.
 >
 > Well actually, in _many_ languages the last expression is taken as return value.
 > (Not only Lisp&  friends, also pure OO ones like Io.)

Also in Ruby. Anyway I think this is ugly (and violates explicit is better than implicit) and might 
even be dangerous because you "leek" the return value of the last statement. Basically you suddenly 
need to always write None (or nil) at the end of a function that should not return anything.

	-panzi


From bruce at leapyear.org  Thu Apr 15 00:24:46 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Wed, 14 Apr 2010 15:24:46 -0700
Subject: [Python-ideas] CSV api with conversion
In-Reply-To: <4BC2F4F9.6050008@netwok.org>
References: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com> 
	<4BC2F4F9.6050008@netwok.org>
Message-ID: <q2gcf5b87741004141524j7a3f145dl282762ccbdebe4b0@mail.gmail.com>

If you do this, you'll probably want to support mapping empty values. That
is,

[int,str]

could map

1,
,2

to

[1,None]
[None,'2']

or

[1,'']
[0,'2']

I'm not sure what the defaults should be but there are reasonable use cases
for both.

--- Bruce
http://www.vroospeak.com


On Mon, Apr 12, 2010 at 3:24 AM, ?ric Araujo <merwok at netwok.org> wrote:

> Hello list
>
> This API would be very useful. (I?m using Python right know to filter
> hundreds of spreadsheets records. Loving it.)
>
> Suggestions:
> 1) Name the argument ?converters? (it?s an iterable);
> 2) Make it a positional argument.
>
> Related wish: Add an argument for a row factory. Default would be list, and
> use cases include using tuple, a named tuple class, or any custom callable.
>
> Adding converters and rowfactory would remove the need for looping over CSV
> reader objects and manually using row and cell converters.
>
> Cheers
> _______________________________________________
> 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/20100414/90edf237/attachment.html>

From daniel at stutzbachenterprises.com  Thu Apr 15 00:47:51 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Wed, 14 Apr 2010 17:47:51 -0500
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63914.7060206@gmail.com>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC63914.7060206@gmail.com>
Message-ID: <y2jeae285401004141547odf7b3765y541e2388984c9409@mail.gmail.com>

On Wed, Apr 14, 2010 at 4:52 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> The course most likely to bear fruit is actually for people to identify
> what tools they need in the functools module in order to make Python
> expressions Turing complete
>

Unless I'm mistaken, Python's lambda expressions are already Turing
complete.  Below is a lambda expression for calculating the factorial of a
number, demonstrating that lambda expressions can use recursion:

lambda n: ((lambda f, *args: f(f, *args))
               ((lambda f, n: 1 if n <= 0 else n*f(f, n-1)),n))

Using a similar scheme, one could write a state machine, which is sufficient
to simulate the canonical Turing machine.

Of course, anyone writing a real algorithm using recursive lambda
expressions deserves what they get. ;-)
--
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/20100414/8258d966/attachment.html>

From python at mrabarnett.plus.com  Thu Apr 15 01:02:54 2010
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 15 Apr 2010 00:02:54 +0100
Subject: [Python-ideas] CSV api with conversion
In-Reply-To: <q2gcf5b87741004141524j7a3f145dl282762ccbdebe4b0@mail.gmail.com>
References: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com>
	<4BC2F4F9.6050008@netwok.org>
	<q2gcf5b87741004141524j7a3f145dl282762ccbdebe4b0@mail.gmail.com>
Message-ID: <4BC6499E.7010600@mrabarnett.plus.com>

Bruce Leban wrote:
> If you do this, you'll probably want to support mapping empty values. 
> That is,
> 
> [int,str]
> 
> could map
> 
> 1,
> ,2
> 
> to 
> 
> [1,None]
> [None,'2']
> 
> or
> 
> [1,'']
> [0,'2']
> 
> I'm not sure what the defaults should be but there are reasonable use 
> cases for both.
> 
The actual values read from the CSV file are strings and you're passing
them to functions:

     int("1"), str("")
     int(""), str("2")

If you want it to return a default value instead of raising an exception
on an empty field then you should pass a conversion function which does
that, for example:

     def int_or_none(field):
         if field.strip():
            return int(field)
         else:
            return None

> --- Bruce
> http://www.vroospeak.com
> 
> 
> On Mon, Apr 12, 2010 at 3:24 AM, ?ric Araujo <merwok at netwok.org 
> <mailto:merwok at netwok.org>> wrote:
> 
>     Hello list
> 
>     This API would be very useful. (I?m using Python right know to
>     filter hundreds of spreadsheets records. Loving it.)
> 
>     Suggestions:
>     1) Name the argument ?converters? (it?s an iterable);
>     2) Make it a positional argument.
> 
>     Related wish: Add an argument for a row factory. Default would be
>     list, and use cases include using tuple, a named tuple class, or any
>     custom callable.
> 
>     Adding converters and rowfactory would remove the need for looping
>     over CSV reader objects and manually using row and cell converters.
> 
>     Cheers
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org <mailto: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



From jimjjewett at gmail.com  Thu Apr 15 01:24:12 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 14 Apr 2010 19:24:12 -0400
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63CBD.1050905@gmx.net>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o> 
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net> 
	<4BC63914.7060206@gmail.com> <4BC63CBD.1050905@gmx.net>
Message-ID: <g2vfb6fbf561004141624oa9958f89ufca1e3ef7ac0e1c@mail.gmail.com>

On Wed, Apr 14, 2010 at 6:07 PM, Mathias Panzenb?ck
<grosser.meister.morti at gmx.net> wrote:

> Maybe only allow them [function definitions] at certain places
> where they can be seen as an
> extension to an already existing statement syntax (not to an
> expression syntax):

> foo.bar = def(egg, spam):
> ? ? ? ?pass

There have been some proposals to allow dotted names and/or indexes in
place of the name, so that would be written as

    def foo.bar(egg, spam):
        pass

They haven't been permanently rejected, but they've been put on hold
for the same reason class decorators were -- once allowed, they can't
be backed out, so lets wait until we're *sure* we need them.

> return def(egg, spam):
> ? ? ? ?pass

This is really only useful inside another function, and isn't a clear
win.  (Would you return the function, or the result of calling the
function?  Could you put () after the definition to call it?  Could
you use other decorators?  Could you put a comma after the definition
to return a tuple of the function and something?)

And note that today's idiom is merely sub-optimal, not outright
terrible.  You can still use your own short name instead of the long
one you need for an external API.

    def wrap():
        def _(egg, spam)
            pass
        return _

-jJ


From conrad.irwin at googlemail.com  Thu Apr 15 01:33:16 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Thu, 15 Apr 2010 00:33:16 +0100
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63CBD.1050905@gmx.net>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>
	<4BC63CBD.1050905@gmx.net>
Message-ID: <4BC650BC.9070608@googlemail.com>

On 04/14/2010 11:07 PM, Mathias Panzenb?ck wrote:
> On 04/14/2010 11:52 PM, Nick Coghlan wrote:
>>
>> The problem is that:
>>
>> 1. Whitespace is highly significant in delineating scope and separation
>> at a statement level
>>
>> 2. Whitespace is largely insignificant at the expression level
>>
> 
> Maybe only allow them at certain places where they can be seen as an
> extension to an already existing statement syntax (not to an expression
> syntax):
> 
> foo.bar = def(egg, spam):
>     pass
> 
> return def(egg, spam):
>     pass
> 
> yield def(egg, spam):
>     pass
> 
> 

There are several places a value might be used:

    return/yield/throw
    rhs of an assignment
    inside a function call

When treating inline-functions as values, the first case is best handled
by @return - the same arguments about not putting decorators on the same
line as function name apply here too. I am also slightly against truly
"anonymous" functions, if it doesn't fit inside a lambda, the name at
least provides some compulsory documentation, and a reference point
while debugging.


I am of the opinion the rhs of assignment case is better handled by
allowing more flexible function names:

    def alpha.beta(val):
        pass


Allowing functions inside function calls is the topic for another day.

Conrad


From python at mrabarnett.plus.com  Thu Apr 15 02:16:01 2010
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 15 Apr 2010 01:16:01 +0100
Subject: [Python-ideas] @return?
In-Reply-To: <g2vfb6fbf561004141624oa9958f89ufca1e3ef7ac0e1c@mail.gmail.com>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>
	<20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC63914.7060206@gmail.com> <4BC63CBD.1050905@gmx.net>
	<g2vfb6fbf561004141624oa9958f89ufca1e3ef7ac0e1c@mail.gmail.com>
Message-ID: <4BC65AC1.1010907@mrabarnett.plus.com>

Jim Jewett wrote:
> On Wed, Apr 14, 2010 at 6:07 PM, Mathias Panzenb?ck
> <grosser.meister.morti at gmx.net> wrote:
> 
>> Maybe only allow them [function definitions] at certain places
>> where they can be seen as an
>> extension to an already existing statement syntax (not to an
>> expression syntax):
> 
>> foo.bar = def(egg, spam):
>>        pass
> 
> There have been some proposals to allow dotted names and/or indexes in
> place of the name, so that would be written as
> 
>     def foo.bar(egg, spam):
>         pass
> 
> They haven't been permanently rejected, but they've been put on hold
> for the same reason class decorators were -- once allowed, they can't
> be backed out, so lets wait until we're *sure* we need them.
> 
>> return def(egg, spam):
>>        pass
> 
> This is really only useful inside another function, and isn't a clear
> win.  (Would you return the function, or the result of calling the
> function?
 >
The function itself.

> Could you put () after the definition to call it?
 >
Probably not.

> Could you use other decorators?  Could you put a comma after the
> definition to return a tuple of the function and something?)
> 
> And note that today's idiom is merely sub-optimal, not outright
> terrible.  You can still use your own short name instead of the long
> one you need for an external API.
> 
>     def wrap():
>         def _(egg, spam)
>             pass
>         return _
> 
How about:

     def wrap():
         def return(egg, spam):
             pass

:-)


From bruce at leapyear.org  Thu Apr 15 02:20:52 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Wed, 14 Apr 2010 17:20:52 -0700
Subject: [Python-ideas] CSV api with conversion
In-Reply-To: <o2wcf5b87741004141719jea342ce6wa872934ab10c9a06@mail.gmail.com>
References: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com>
	<4BC2F4F9.6050008@netwok.org>
	<q2gcf5b87741004141524j7a3f145dl282762ccbdebe4b0@mail.gmail.com>
	<4BC6499E.7010600@mrabarnett.plus.com>
	<o2wcf5b87741004141719jea342ce6wa872934ab10c9a06@mail.gmail.com>
Message-ID: <i2kcf5b87741004141720r471e6205o98e8f063b9af7960@mail.gmail.com>

Sure I could do that. I just this think if you're making a convenience
function like this you should strive to make it more convenient.  :-)

--- Bruce
(via android)

On Apr 14, 2010 4:03 PM, "MRAB" <python at mrabarnett.plus.com> wrote:

Bruce Leban wrote:
>
> If you do this, you'll probably want to support mapping empty values. That
is...
The actual values read from the CSV file are strings and you're passing
them to functions:

   int("1"), str("")
   int(""), str("2")

If you want it to return a default value instead of raising an exception
on an empty field then you should pass a conversion function which does
that, for example:

   def int_or_none(field):
       if field.strip():
          return int(field)
       else:
          return None

> --- Bruce
> > http://www.vroospeak.com
> >
> >
>
> > On Mon, Apr 12, 2010 at 3:24 AM, ?ric Araujo <merwok at netwok.org <mailto:
> merwok at netwok.org>> wrote:...
>    Python-ideas at python.org <mailto:Python-ideas at python.org>
>
>
> >    http://mail.python.org/mailman/listinfo/python-ideas
> >
> >
> >
> ------------------------------------------------------------------------
>
>
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at pyth...
>


_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100414/b1ed0137/attachment.html>

From greg.ewing at canterbury.ac.nz  Thu Apr 15 02:58:54 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 15 Apr 2010 12:58:54 +1200
Subject: [Python-ideas] @return?
In-Reply-To: <73193102-8838-459A-80D2-23B8271C15BA@masklinn.net>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC60C76.9080107@mrabarnett.plus.com>
	<73193102-8838-459A-80D2-23B8271C15BA@masklinn.net>
Message-ID: <4BC664CE.3060804@canterbury.ac.nz>

Masklinn wrote:
> there's no reason why it should be unsolvable, Haskell manages to 
 > have lambdas even using offside syntax (though it has a few properties
> which probably make it easier to handle than in Python)

Yes. Haskell doesn't have imperative control structures,
everything is an expression returning a value.

The two languages are sufficiently different that you
can't easily transplant selected features from one to
the other.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Thu Apr 15 03:23:00 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 15 Apr 2010 13:23:00 +1200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63914.7060206@gmail.com>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC63914.7060206@gmail.com>
Message-ID: <4BC66A74.5060709@canterbury.ac.nz>

Nick Coghlan wrote:
> identify
> what tools they need in the functools module in order to make Python
> expressions Turing complete (you should be able to use functional
> programming tricks to attain that without needing to introduce embedded
> assignments).

Functional programming tricks used to achieve that
typically rely a lot on recursion and tail call
optimisation, which Python isn't likely to get.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Thu Apr 15 03:24:45 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 15 Apr 2010 13:24:45 +1200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63DA8.6060603@gmx.net>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com> <20100414235157.3ad38e9d@o>
	<4BC63DA8.6060603@gmx.net>
Message-ID: <4BC66ADD.8040406@canterbury.ac.nz>

Mathias Panzenb?ck wrote:
> might even be dangerous because you "leek" the 
> return value of the last statement.

Or if you're not Welsh, you "leak" it. :-)

-- 
Greg


From python at mrabarnett.plus.com  Thu Apr 15 03:45:23 2010
From: python at mrabarnett.plus.com (MRAB)
Date: Thu, 15 Apr 2010 02:45:23 +0100
Subject: [Python-ideas] CSV api with conversion
In-Reply-To: <i2kcf5b87741004141720r471e6205o98e8f063b9af7960@mail.gmail.com>
References: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com>	
	<4BC2F4F9.6050008@netwok.org>	
	<q2gcf5b87741004141524j7a3f145dl282762ccbdebe4b0@mail.gmail.com>	
	<4BC6499E.7010600@mrabarnett.plus.com>	
	<o2wcf5b87741004141719jea342ce6wa872934ab10c9a06@mail.gmail.com>
	<i2kcf5b87741004141720r471e6205o98e8f063b9af7960@mail.gmail.com>
Message-ID: <4BC66FB3.2080908@mrabarnett.plus.com>

Bruce Leban wrote:
> Sure I could do that. I just this think if you're making a convenience 
> function like this you should strive to make it more convenient.  :-)
> 
If you're passing in 'int' as a conversion function then it should do
what 'int' does, which is to raise an exception.

I could quote the Zen of Python:

     Errors should never pass silently.
     Unless explicitly silenced.

It shouldn't be so convenient that it leads to sloppy coding. :-)

> --- Bruce
> (via android)
> 
>> On Apr 14, 2010 4:03 PM, "MRAB" <python at mrabarnett.plus.com 
>> <mailto:python at mrabarnett.plus.com>> wrote:
>>
>> Bruce Leban wrote:
>> >
>> > If you do this, you'll probably want to support mapping empty 
>> values. That is...
>>
>> The actual values read from the CSV file are strings and you're passing
>> them to functions:
>>
>>    int("1"), str("")
>>    int(""), str("2")
>>
>> If you want it to return a default value instead of raising an exception
>> on an empty field then you should pass a conversion function which does
>> that, for example:
>>
>>    def int_or_none(field):
>>        if field.strip():
>>           return int(field)
>>        else:
>>           return None
>>



From pyideas at rebertia.com  Thu Apr 15 06:57:10 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Wed, 14 Apr 2010 21:57:10 -0700
Subject: [Python-ideas] @return?
In-Reply-To: <4BC664CE.3060804@canterbury.ac.nz>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC60C76.9080107@mrabarnett.plus.com>
	<73193102-8838-459A-80D2-23B8271C15BA@masklinn.net>
	<4BC664CE.3060804@canterbury.ac.nz>
Message-ID: <m2m50697b2c1004142157p21ea282bgb069434da2fb7533@mail.gmail.com>

On Wed, Apr 14, 2010 at 5:58 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Masklinn wrote:
>> there's no reason why it should be unsolvable, Haskell manages to
>
>> have lambdas even using offside syntax (though it has a few properties
>>
>> which probably make it easier to handle than in Python)
<snip>
> The two languages are sufficiently different that you
> can't easily transplant selected features from one to
> the other.

List and other comprehensions notwithstanding. :-)

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


From ctb at msu.edu  Thu Apr 15 07:02:37 2010
From: ctb at msu.edu (C. Titus Brown)
Date: Wed, 14 Apr 2010 22:02:37 -0700
Subject: [Python-ideas] question - 'bag' type
Message-ID: <20100415050237.GE7185@idyll.org>

Hi all,

this seems like the right forum to ask -- is there a reason why Python
doesn't have a 'bag' builtin type, e.g.

   b = bag(foo=bar, baz=bif)

   assert b.foo == bar
   assert b.bz == bif

?

It's easy to write and there's a great discussion over at the cookbook:

http://code.activestate.com/recipes/259174-bag-collection-class/

Inquiring minds want to know!

thanks,
--titus
-- 
C. Titus Brown, ctb at msu.edu


From daniel at stutzbachenterprises.com  Thu Apr 15 07:08:26 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Thu, 15 Apr 2010 00:08:26 -0500
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <20100415050237.GE7185@idyll.org>
References: <20100415050237.GE7185@idyll.org>
Message-ID: <j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>

On Thu, Apr 15, 2010 at 12:02 AM, C. Titus Brown <ctb at msu.edu> wrote:

> this seems like the right forum to ask -- is there a reason why Python
> doesn't have a 'bag' builtin type, e.g.
>
Python 2.7 and 3.1 have a Counter type, that is similar to (but not
identical to) that recipe:

http://docs.python.org/py3k/library/collections.html#collections.Counter

--
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/20100415/cb3cf75a/attachment.html>

From ctb at msu.edu  Thu Apr 15 07:12:38 2010
From: ctb at msu.edu (C. Titus Brown)
Date: Wed, 14 Apr 2010 22:12:38 -0700
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
References: <20100415050237.GE7185@idyll.org>
	<j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
Message-ID: <20100415051238.GB29949@idyll.org>

On Thu, Apr 15, 2010 at 12:08:26AM -0500, Daniel Stutzbach wrote:
> On Thu, Apr 15, 2010 at 12:02 AM, C. Titus Brown <ctb at msu.edu> wrote:
> 
> > this seems like the right forum to ask -- is there a reason why Python
> > doesn't have a 'bag' builtin type, e.g.
> >
> Python 2.7 and 3.1 have a Counter type, that is similar to (but not
> identical to) that recipe:
> 
> http://docs.python.org/py3k/library/collections.html#collections.Counter

Huh, seems like a different use case from mine -- I just would like to be able
to refer to dictionary keys as attributes.  So I guess the cookbook recipe
distracted you from my real interest, which is the short notation:

   b = bag(foo=bar, bif=baz)

   assert b.foo == bar
   assert b.bif == baz

Still curious :)

thanks,
--t
-- 
C. Titus Brown, ctb at msu.edu


From pyideas at rebertia.com  Thu Apr 15 07:14:11 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Wed, 14 Apr 2010 22:14:11 -0700
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <20100415050237.GE7185@idyll.org>
References: <20100415050237.GE7185@idyll.org>
Message-ID: <i2h50697b2c1004142214ne1fceb9fz8d8e262e8228d414@mail.gmail.com>

On Wed, Apr 14, 2010 at 10:02 PM, C. Titus Brown <ctb at msu.edu> wrote:
> Hi all,
>
> this seems like the right forum to ask -- is there a reason why Python
> doesn't have a 'bag' builtin type, e.g.
>
> ? b = bag(foo=bar, baz=bif)
>
> ? assert b.foo == bar
> ? assert b.bz == bif
>
> ?
>
> It's easy to write and there's a great discussion over at the cookbook:
>
> http://code.activestate.com/recipes/259174-bag-collection-class/
>
> Inquiring minds want to know!

There was some discussion:
http://mail.python.org/pipermail/python-ideas/2009-July/005219.html
http://www.mail-archive.com/python-list at python.org/msg229512.html

...the outcome of which was the Counter class:
http://docs.python.org/dev/py3k/library/collections.html#collections.Counter

It's /somewhat/ like a bag, except elements can have negative
multiplicity and the default iterator yields each element exactly
once, regardless of its multiplicity (yeah, I know, doesn't quite make
sense). There have been attempts to also add a proper bag/multiset
type, but the use cases for bags are relatively few and
collections.Counter is usually close enough that it can be used in
such cases, although not as elegantly.

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


From pyideas at rebertia.com  Thu Apr 15 07:20:51 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Wed, 14 Apr 2010 22:20:51 -0700
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <20100415051238.GB29949@idyll.org>
References: <20100415050237.GE7185@idyll.org>
	<j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
	<20100415051238.GB29949@idyll.org>
Message-ID: <r2u50697b2c1004142220n18dafd9br5ffe5e88dad1f493@mail.gmail.com>

On Wed, Apr 14, 2010 at 10:12 PM, C. Titus Brown <ctb at msu.edu> wrote:
> On Thu, Apr 15, 2010 at 12:08:26AM -0500, Daniel Stutzbach wrote:
>> On Thu, Apr 15, 2010 at 12:02 AM, C. Titus Brown <ctb at msu.edu> wrote:
>> > this seems like the right forum to ask -- is there a reason why Python
>> > doesn't have a 'bag' builtin type, e.g.
>> >
>> Python 2.7 and 3.1 have a Counter type, that is similar to (but not
>> identical to) that recipe:
>>
>> http://docs.python.org/py3k/library/collections.html#collections.Counter
>
> Huh, seems like a different use case from mine -- I just would like to be able
> to refer to dictionary keys as attributes. ?So I guess the cookbook recipe
> distracted you from my real interest, which is the short notation:
>
> ? b = bag(foo=bar, bif=baz)
>
> ? assert b.foo == bar
> ? assert b.bif == baz
>
> Still curious :)

Also, that's not a bag at all. Seems you're looking for something
similar to namedtuple:
http://docs.python.org/dev/library/collections.html#collections.namedtuple

For the record, a bag is an unordered collection that permits
duplicate elements. Sort of like an unordered, unindexable list, or a
set that allows duplicate elements.
It's got nothing whatsoever to do with being able to access elements
using attribute syntax.

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


From bruce at leapyear.org  Thu Apr 15 07:22:13 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Wed, 14 Apr 2010 22:22:13 -0700
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <20100415051238.GB29949@idyll.org>
References: <20100415050237.GE7185@idyll.org>
	<j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
	<20100415051238.GB29949@idyll.org>
Message-ID: <s2xcf5b87741004142222r25bbd216ib1ce7edadd1d3857@mail.gmail.com>

The example you give is a dict aside from syntax. What makes it bag-like? Do
you expect that I can write

b = bag(foo=bar, foo=car)

But I'd hardly expect b.foo == bar or b.foo == car as you suggest.

--- Bruce
http://www.vroospeak.com


On Wed, Apr 14, 2010 at 10:12 PM, C. Titus Brown <ctb at msu.edu> wrote:

> On Thu, Apr 15, 2010 at 12:08:26AM -0500, Daniel Stutzbach wrote:
> > On Thu, Apr 15, 2010 at 12:02 AM, C. Titus Brown <ctb at msu.edu> wrote:
> >
> > > this seems like the right forum to ask -- is there a reason why Python
> > > doesn't have a 'bag' builtin type, e.g.
> > >
> > Python 2.7 and 3.1 have a Counter type, that is similar to (but not
> > identical to) that recipe:
> >
> > http://docs.python.org/py3k/library/collections.html#collections.Counter
>
> Huh, seems like a different use case from mine -- I just would like to be
> able
> to refer to dictionary keys as attributes.  So I guess the cookbook recipe
> distracted you from my real interest, which is the short notation:
>
>   b = bag(foo=bar, bif=baz)
>
>   assert b.foo == bar
>   assert b.bif == baz
>
> Still curious :)
>
> thanks,
> --t
> --
> C. Titus Brown, ctb at msu.edu
> _______________________________________________
> 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/20100414/2cc7c69a/attachment.html>

From ctb at msu.edu  Thu Apr 15 07:30:38 2010
From: ctb at msu.edu (C. Titus Brown)
Date: Wed, 14 Apr 2010 22:30:38 -0700
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <s2xcf5b87741004142222r25bbd216ib1ce7edadd1d3857@mail.gmail.com>
References: <20100415050237.GE7185@idyll.org>
	<j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
	<20100415051238.GB29949@idyll.org>
	<s2xcf5b87741004142222r25bbd216ib1ce7edadd1d3857@mail.gmail.com>
Message-ID: <20100415053038.GE29949@idyll.org>

On Wed, Apr 14, 2010 at 10:22:13PM -0700, Bruce Leban wrote:
> The example you give is a dict aside from syntax. What makes it bag-like? Do
> you expect that I can write
> 
> b = bag(foo=bar, foo=car)
> 
> But I'd hardly expect b.foo == bar or b.foo == car as you suggest.

I guess I don't understand what a bag is -- I'd just heard this structure
referred to as such.

"dict aside from syntax" is the point, yes!

thanks,
--titus


From ctb at msu.edu  Thu Apr 15 07:31:17 2010
From: ctb at msu.edu (C. Titus Brown)
Date: Wed, 14 Apr 2010 22:31:17 -0700
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <r2u50697b2c1004142220n18dafd9br5ffe5e88dad1f493@mail.gmail.com>
References: <20100415050237.GE7185@idyll.org>
	<j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
	<20100415051238.GB29949@idyll.org>
	<r2u50697b2c1004142220n18dafd9br5ffe5e88dad1f493@mail.gmail.com>
Message-ID: <20100415053117.GG29949@idyll.org>

On Wed, Apr 14, 2010 at 10:20:51PM -0700, Chris Rebert wrote:
> On Wed, Apr 14, 2010 at 10:12 PM, C. Titus Brown <ctb at msu.edu> wrote:
> > On Thu, Apr 15, 2010 at 12:08:26AM -0500, Daniel Stutzbach wrote:
> >> On Thu, Apr 15, 2010 at 12:02 AM, C. Titus Brown <ctb at msu.edu> wrote:
> >> > this seems like the right forum to ask -- is there a reason why Python
> >> > doesn't have a 'bag' builtin type, e.g.
> >> >
> >> Python 2.7 and 3.1 have a Counter type, that is similar to (but not
> >> identical to) that recipe:
> >>
> >> http://docs.python.org/py3k/library/collections.html#collections.Counter
> >
> > Huh, seems like a different use case from mine -- I just would like to be able
> > to refer to dictionary keys as attributes. ??So I guess the cookbook recipe
> > distracted you from my real interest, which is the short notation:
> >
> > ?? b = bag(foo=bar, bif=baz)
> >
> > ?? assert b.foo == bar
> > ?? assert b.bif == baz
> >
> > Still curious :)
> 
> Also, that's not a bag at all. Seems you're looking for something
> similar to namedtuple:
> http://docs.python.org/dev/library/collections.html#collections.namedtuple
> 
> For the record, a bag is an unordered collection that permits
> duplicate elements. Sort of like an unordered, unindexable list, or a
> set that allows duplicate elements.
> It's got nothing whatsoever to do with being able to access elements
> using attribute syntax.

Thanks!

--titus
-- 
C. Titus Brown, ctb at msu.edu


From wuwei23 at gmail.com  Thu Apr 15 08:02:54 2010
From: wuwei23 at gmail.com (alex23)
Date: Wed, 14 Apr 2010 23:02:54 -0700 (PDT)
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <20100415050237.GE7185@idyll.org>
References: <20100415050237.GE7185@idyll.org>
Message-ID: <3469fb78-8f87-4fa5-9df5-feec80dfcddd@h27g2000yqm.googlegroups.com>

On Apr 15, 3:02?pm, "C. Titus Brown" <c... at msu.edu> wrote:
> ? ?b = bag(foo=bar, baz=bif)
>
> ? ?assert b.foo == bar
> ? ?assert b.bz == bif

I've always known this as a 'bunch' after Alex Martelli's recipe[1].
It's handy, but at 3 lines of code not an urgent candidate (IMO) for
stdlib:

  class Bunch:
    def __init__(self, **kwds):
      self.__dict__.update(kwds)

[1]: http://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named


From bruce at leapyear.org  Thu Apr 15 08:05:05 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Wed, 14 Apr 2010 23:05:05 -0700
Subject: [Python-ideas] CSV api with conversion
In-Reply-To: <4BC66FB3.2080908@mrabarnett.plus.com>
References: <z2z180ba39c1004110328o2d6e351dpeb3c532f83b7aa89@mail.gmail.com> 
	<4BC2F4F9.6050008@netwok.org>
	<q2gcf5b87741004141524j7a3f145dl282762ccbdebe4b0@mail.gmail.com>
	<4BC6499E.7010600@mrabarnett.plus.com>
	<o2wcf5b87741004141719jea342ce6wa872934ab10c9a06@mail.gmail.com>
	<i2kcf5b87741004141720r471e6205o98e8f063b9af7960@mail.gmail.com> 
	<4BC66FB3.2080908@mrabarnett.plus.com>
Message-ID: <v2xcf5b87741004142305h9fd11c0dn2f8e7e082e02769c@mail.gmail.com>

I didn't mean to suggest that errors should be ignored. Making it easy to
map an empty field to None instead of throwing an error isn't ignoring an
error, it's allowing the developer to preserve data. Granted the csv module
doesn't distinguish between empty fields and non-empty fields but many csv
files do have that distinction. Perhaps the csv module should be fixed to
allow that distinction to be available, maybe by adding new Dialects? Aside
from that it's worth considering a variety of use cases before adding
something like this to the standard libraries.

Imagine that I want a missing int in the first field to raise an exception,
in the second to get the value 0 and in the third to get the value None, I
could write something like:
(1) csv.reader(f, (int, (int, None), (int, 0))
(2) csv.reader(f, (int, csv.map_empty(int, None), csv.map_empty(int, 0))

I'm not saying I like either of those syntaxes, I'm just giving examples to
show feasibility. The benefit of either of those is that they can be used
for both reading and writing while an arbitrary function can't.

If I was going to add this conversion feature to csv, it seems to me to make
the most sense to implement this as a Dialect. The documentation for Dialect
is a little thin, but here's an example:

d = Dialect(base_dialect, *ordered_formats, **key_formats)

d = Dialect(csv.excel, int, str, float)
d = Dialect(csv.excel, sku=int, name=str, price=float)

r = csv.Reader(f, dialect=d)

--- Bruce
http://www.vroospeak.com


On Wed, Apr 14, 2010 at 6:45 PM, MRAB <python at mrabarnett.plus.com> wrote:

> Bruce Leban wrote:
>
>> Sure I could do that. I just this think if you're making a convenience
>> function like this you should strive to make it more convenient.  :-)
>>
>>  If you're passing in 'int' as a conversion function then it should do
> what 'int' does, which is to raise an exception.
>
> I could quote the Zen of Python:
>
>    Errors should never pass silently.
>    Unless explicitly silenced.
>
> It shouldn't be so convenient that it leads to sloppy coding. :-)
>
>  --- Bruce
>> (via android)
>>
>>
>>  On Apr 14, 2010 4:03 PM, "MRAB" <python at mrabarnett.plus.com <mailto:
>>> python at mrabarnett.plus.com>> wrote:
>>>
>>> Bruce Leban wrote:
>>> >
>>> > If you do this, you'll probably want to support mapping empty values.
>>> That is...
>>>
>>> The actual values read from the CSV file are strings and you're passing
>>> them to functions:
>>>
>>>   int("1"), str("")
>>>   int(""), str("2")
>>>
>>> If you want it to return a default value instead of raising an exception
>>> on an empty field then you should pass a conversion function which does
>>> that, for example:
>>>
>>>   def int_or_none(field):
>>>       if field.strip():
>>>          return int(field)
>>>       else:
>>>          return None
>>>
>>>
> _______________________________________________
> 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/20100414/3eaea716/attachment.html>

From masklinn at masklinn.net  Thu Apr 15 08:08:19 2010
From: masklinn at masklinn.net (Masklinn)
Date: Thu, 15 Apr 2010 08:08:19 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63DA8.6060603@gmx.net>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>
	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>
	<20100414235157.3ad38e9d@o> <4BC63DA8.6060603@gmx.net>
Message-ID: <6CB1A019-A348-48CF-A607-2B86E79F25D4@masklinn.net>

On 15 Apr 2010, at 00:11 , Mathias Panzenb?ck wrote:
> On 04/14/2010 11:51 PM, spir ? wrote:
> > On Wed, 14 Apr 2010 17:41:43 +0100
> > Conrad Irwin<conrad.irwin at googlemail.com>  wrote:
> >
> >> Changing things so that return isn't necessary at all would also solve
> >> the problem, and quite nicely, but I think that's a far-too-drastic
> >> change in semantics.
> >
> > Well actually, in _many_ languages the last expression is taken as return value.
> > (Not only Lisp&  friends, also pure OO ones like Io.)
> 
> Also in Ruby. Anyway I think this is ugly (and violates explicit is better than implicit)
Why? Functions always returning the last-evaluated expression by default is a pretty explicit rule. And it's a pretty nice default too, more useful than returning None (which is the current behavior, and if you want to argue about arbitrary stuff I'd say that's just as arbitrary if not more)

> and might even be dangerous because you "leek" the return value of the last statement. Basically you suddenly need to always write None (or nil) at the end of a function that should not return anything.
In my experience (with languages behaving that way), that tends not to be much of an issue. Most functions and methods return values anyway, so that's the general case. And it's not like you should rely on undocumented return values.

So that objection is mostly a scare-tactic, akin to the "oh noes, significant whitespace is going to kill us all" screed coming from other communities when Python comes up.

From masklinn at masklinn.net  Thu Apr 15 08:10:37 2010
From: masklinn at masklinn.net (Masklinn)
Date: Thu, 15 Apr 2010 08:10:37 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC650BC.9070608@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>
	<4BC63CBD.1050905@gmx.net> <4BC650BC.9070608@googlemail.com>
Message-ID: <78A04D86-7998-4E54-B6DE-0C613666CBA7@masklinn.net>

On 15 Apr 2010, at 01:33 , Conrad Irwin wrote:
> I am also slightly against truly
> "anonymous" functions, if it doesn't fit inside a lambda, the name at
> least provides some compulsory documentation

Isn't that statement a bit disingenuous when considering that `for` or
`with` blocks can contain arbitrary complexity and not require any kind
of naming?

> and a reference point while debugging.

that can be useful, but again it's not like most python source provides
that.


From ctb at msu.edu  Thu Apr 15 08:20:59 2010
From: ctb at msu.edu (C. Titus Brown)
Date: Wed, 14 Apr 2010 23:20:59 -0700
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <3469fb78-8f87-4fa5-9df5-feec80dfcddd@h27g2000yqm.googlegroups.com>
References: <20100415050237.GE7185@idyll.org>
	<3469fb78-8f87-4fa5-9df5-feec80dfcddd@h27g2000yqm.googlegroups.com>
Message-ID: <20100415062059.GB3792@idyll.org>

On Wed, Apr 14, 2010 at 11:02:54PM -0700, alex23 wrote:
> On Apr 15, 3:02?pm, "C. Titus Brown" <c... at msu.edu> wrote:
> > ? ?b = bag(foo=bar, baz=bif)
> >
> > ? ?assert b.foo == bar
> > ? ?assert b.bz == bif
> 
> I've always known this as a 'bunch' after Alex Martelli's recipe[1].
> It's handy, but at 3 lines of code not an urgent candidate (IMO) for
> stdlib:
> 
>   class Bunch:
>     def __init__(self, **kwds):
>       self.__dict__.update(kwds)
> 
> [1]: http://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named

Well, yes -- but 'sets' weren't exactly rocket science either, and I find
them really useful, too :).

--titus
-- 
C. Titus Brown, ctb at msu.edu


From mal at egenix.com  Thu Apr 15 09:31:32 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 15 Apr 2010 09:31:32 +0200
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <20100415050237.GE7185@idyll.org>
References: <20100415050237.GE7185@idyll.org>
Message-ID: <4BC6C0D4.3070406@egenix.com>

C. Titus Brown wrote:
> Hi all,
> 
> this seems like the right forum to ask -- is there a reason why Python
> doesn't have a 'bag' builtin type, e.g.
> 
>    b = bag(foo=bar, baz=bif)
> 
>    assert b.foo == bar
>    assert b.bz == bif
> 
> ?

That's what's normally called a "namespace" in Python-land
and can easily be had via a regular instance:

class Namespace:
    def __init__(self, **kws):
        self.__dict__.update(kws)

b = Namespace(foo=bar, baz=bif)

assert b.foo == bar
assert b.bz == bif

For a more elaborate example of a namespace class, see mx.Misc.Namespace
from our eGenix mx Base package:

    http://www.egenix.com/products/python/mxBase/

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 15 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


From phd at phd.pp.ru  Thu Apr 15 11:01:44 2010
From: phd at phd.pp.ru (Oleg Broytman)
Date: Thu, 15 Apr 2010 13:01:44 +0400
Subject: [Python-ideas] item/attr dual access (was: 'bag' type)
In-Reply-To: <20100415051238.GB29949@idyll.org>
References: <20100415050237.GE7185@idyll.org>
	<j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
	<20100415051238.GB29949@idyll.org>
Message-ID: <20100415090144.GC7144@phd.pp.ru>

On Wed, Apr 14, 2010 at 10:12:38PM -0700, C. Titus Brown wrote:
> I just would like to be able
> to refer to dictionary keys as attributes.  So I guess the cookbook recipe
> distracted you from my real interest, which is the short notation:
> 
>    b = bag(foo=bar, bif=baz)
> 
>    assert b.foo == bar
>    assert b.bif == baz

   See class DictRecord at
http://ppa.cvs.sourceforge.net/viewvc/*checkout*/ppa/QPS/qps/qUtils.py
   License: Python.

Oleg.
-- 
     Oleg Broytman            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.


From masklinn at masklinn.net  Thu Apr 15 11:29:16 2010
From: masklinn at masklinn.net (Masklinn)
Date: Thu, 15 Apr 2010 11:29:16 +0200
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <4BC6C0D4.3070406@egenix.com>
References: <20100415050237.GE7185@idyll.org> <4BC6C0D4.3070406@egenix.com>
Message-ID: <463E17AD-2133-42B2-99C7-365A1E16B357@masklinn.net>

On 15 Apr 2010, at 09:31 , M.-A. Lemburg wrote:
> 
> C. Titus Brown wrote:
>> Hi all,
>> 
>> this seems like the right forum to ask -- is there a reason why Python
>> doesn't have a 'bag' builtin type, e.g.
>> 
>>   b = bag(foo=bar, baz=bif)
>> 
>>   assert b.foo == bar
>>   assert b.bz == bif
>> 
>> ?
> 
> That's what's normally called a "namespace" in Python-land
> and can easily be had via a regular instance:
> 
> class Namespace:
>    def __init__(self, **kws):
>        self.__dict__.update(kws)
> 
> b = Namespace(foo=bar, baz=bif)

An other way is to inherit from dict and just forward __getattr__
 and __setattr__ to __getitem__ and __setitem__ (with exception conversion
maybe), that way both accesses are possible, and you get all the dicty
goodness for free (dict merging with both arg and **kwargs constructor 
arguments, iterations, string representation, `dict.update`, ?)

class NS(dict):
    def __getattr__(self, key):
        return self.__getitem__(key)
    def __setattr__(self, key, value):
        return self.__setitem__(key, value)
    def __delattr__(self, key):
        return self.__delitem__(key)

(note: that one probably breaks `hasattr` and `getattr` given KeyError isn't
converted to AttributeError, but that should not take many lines)

From conrad.irwin at googlemail.com  Thu Apr 15 13:03:17 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Thu, 15 Apr 2010 12:03:17 +0100
Subject: [Python-ideas] @return?
In-Reply-To: <78A04D86-7998-4E54-B6DE-0C613666CBA7@masklinn.net>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>
	<4BC63CBD.1050905@gmx.net> <4BC650BC.9070608@googlemail.com>
	<78A04D86-7998-4E54-B6DE-0C613666CBA7@masklinn.net>
Message-ID: <4BC6F275.20506@googlemail.com>


On 04/15/2010 07:10 AM, Masklinn wrote:
> On 15 Apr 2010, at 01:33 , Conrad Irwin wrote:
>> I am also slightly against truly
>> "anonymous" functions, if it doesn't fit inside a lambda, the name at
>> least provides some compulsory documentation
> 
> Isn't that statement a bit disingenuous when considering that `for` or
> `with` blocks can contain arbitrary complexity and not require any kind
> of naming?
> 
>> and a reference point while debugging.
> 
> that can be useful, but again it's not like most python source provides
> that.

The thing I fear is ending up with a stacktrace like:

Traceback (most recent call last):
  File "a.py", line 10, in <module>
    event('complete')
  File "a.py", line 6, in event
    def event(*args): [callback(*args) for callback in cbs]
TypeError: <anonymous>() takes no arguments (1 given)

In general, it is going to take a while to find out what <anonymous> is,
and where it came from, and why it has the wrong signature. Because you
can't pass with/for blocks around there is little need for them to carry
their documentation with them. Obviously it's not impossible, it's just
not pleasant either.

Conrad


From denis.spir at gmail.com  Thu Apr 15 13:37:02 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Thu, 15 Apr 2010 13:37:02 +0200
Subject: [Python-ideas] "value" ~ "data" ~ "object"
Message-ID: <20100415133702.78f1394b@o>

Hello,

I have been recently thinking at lexical distinctions around the notion of data. (--> eg for a starting point http://c2.com/cgi/wiki?WhatIsData) Not only but especially in Python. I ended up with the following questions:
Can one state "in Python value=data=object"?
Can one state "in Python speak value=data=object"?

What useful distinctions are or may be done, for instance in documentation?
What kind of difference in actual language semantics may such distinctions mirror?

Denis

PS: side-question on english:
I am annoyed by the fact that in english "data" is mainly used & understood as a collective (uncountable) noun. "datum" (singular) & "datas" (plural) seem to be considered weird. How to denote a single unit of data wothout using the phrase "piece of data"? Can one still use "datum" or "datas" (or "data" as plural) and be trivially understood by *anybody* (not only scientists)? Or else what word should one use?
-->  
Compare: german Datum/Daten http://de.wiktionary.org/wiki/Datum, french donn?e/donn?es http://fr.wiktionary.org/wiki/donn%C3%A9e, etc...
________________________________

vit esse estrany ?

spir.wikidot.com


From fuzzyman at gmail.com  Thu Apr 15 13:43:07 2010
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 15 Apr 2010 13:43:07 +0200
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <3469fb78-8f87-4fa5-9df5-feec80dfcddd@h27g2000yqm.googlegroups.com>
References: <20100415050237.GE7185@idyll.org>
	<3469fb78-8f87-4fa5-9df5-feec80dfcddd@h27g2000yqm.googlegroups.com>
Message-ID: <l2j6f4025011004150443jf5e967e6mab09adc8217e326a@mail.gmail.com>

On 15 April 2010 08:02, alex23 <wuwei23 at gmail.com> wrote:

> On Apr 15, 3:02 pm, "C. Titus Brown" <c... at msu.edu> wrote:
> >    b = bag(foo=bar, baz=bif)
> >
> >    assert b.foo == bar
> >    assert b.bz == bif
>
> I've always known this as a 'bunch' after Alex Martelli's recipe[1].
> It's handy, but at 3 lines of code not an urgent candidate (IMO) for
> stdlib:
>
>  class Bunch:
>    def __init__(self, **kwds):
>      self.__dict__.update(kwds)
>


Yeah, we've used this class a tonne - especially for testing where you just
need a quick object with a bunch of attributes. I think we added a repr as
well. It would certainly be a nice harmless addition to the collections
module.

Michael



>
> [1]:
> http://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named
> _______________________________________________
> 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/20100415/1c9d2c5e/attachment.html>

From masklinn at masklinn.net  Thu Apr 15 13:52:15 2010
From: masklinn at masklinn.net (Masklinn)
Date: Thu, 15 Apr 2010 13:52:15 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC6F275.20506@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>
	<4BC63CBD.1050905@gmx.net> <4BC650BC.9070608@googlemail.com>
	<78A04D86-7998-4E54-B6DE-0C613666CBA7@masklinn.net>
	<4BC6F275.20506@googlemail.com>
Message-ID: <37574C03-1AE0-471C-9BF1-90B644E8F8E0@masklinn.net>

On 15 Apr 2010, at 13:03 , Conrad Irwin wrote:
> 
> 
> On 04/15/2010 07:10 AM, Masklinn wrote:
>> On 15 Apr 2010, at 01:33 , Conrad Irwin wrote:
>>> I am also slightly against truly
>>> "anonymous" functions, if it doesn't fit inside a lambda, the name at
>>> least provides some compulsory documentation
>> 
>> Isn't that statement a bit disingenuous when considering that `for` or
>> `with` blocks can contain arbitrary complexity and not require any kind
>> of naming?
>> 
>>> and a reference point while debugging.
>> 
>> that can be useful, but again it's not like most python source provides
>> that.
> 
> The thing I fear is ending up with a stacktrace like:
> 
> Traceback (most recent call last):
>  File "a.py", line 10, in <module>
>    event('complete')
>  File "a.py", line 6, in event
>    def event(*args): [callback(*args) for callback in cbs]
> TypeError: <anonymous>() takes no arguments (1 given)
> 
> In general, it is going to take a while to find out what <anonymous> is,
> and where it came from, and why it has the wrong signature. Because you
> can't pass with/for blocks around there is little need for them to carry
> their documentation with them. Obviously it's not impossible, it's just
> not pleasant either.
I understand that fear, but there is no reason why the repr for the anonymous
def wouldn't include the file and line where the function was created, is
there?, e.g.

> TypeError: <anonymous at b.py:42>() takes no arguments (1 given)

something along those lines. Tracking those infos would be necessary for
debugging anyway.


From conrad.irwin at googlemail.com  Thu Apr 15 15:31:49 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Thu, 15 Apr 2010 14:31:49 +0100
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <20100415133702.78f1394b@o>
References: <20100415133702.78f1394b@o>
Message-ID: <4BC71545.5010804@googlemail.com>


On 04/15/2010 12:37 PM, spir ? wrote:
> Hello,
> 
> I have been recently thinking at lexical distinctions around the notion of data. (--> eg for a starting point http://c2.com/cgi/wiki?WhatIsData) Not only but especially in Python. I ended up with the following questions:
> Can one state "in Python value=data=object"?
> Can one state "in Python speak value=data=object"?
> 
> What useful distinctions are or may be done, for instance in documentation?
> What kind of difference in actual language semantics may such distinctions mirror?

Uh.. you are trying to have a discussion about detailed semantics
without defining what you mean by any of your terminology.

As I see it (which is undoubtedly misleading in many respects):

 the set of all data is a countably infinite and unordered.
   (perhaps segments of memory)
 the set of all values is a countably infinite and partially ordered.
 an object is a member of the set of (datum, value) pairs.
   (perhaps a memory address coupled with a type)

In Python, each object with a different value has a different datum (and
for the most part, objects with the same values have different data
too). The only operation that concerns that datum of an object is the
"is" operator.

The value of an object is more useful, and this is what all the other
comparison operators (and most other functions) deal with. It shouldn't
be necessary to make the distinction between an object and its value in
documentation (though it is (I presume) occasionally useful in actual
code to distinguish objects with the same datum, perhaps in cycle
detection).

Conrad

> 
> Denis
> 
> PS: side-question on english:
> I am annoyed by the fact that in english "data" is mainly used & understood as a collective (uncountable) noun. "datum" (singular) & "datas" (plural) seem to be considered weird. How to denote a single unit of data wothout using the phrase "piece of data"? Can one still use "datum" or "datas" (or "data" as plural) and be trivially understood by *anybody* (not only scientists)? Or else what word should one use?

You can use datum/data as countable but it sounds forced (as above).


From ncoghlan at gmail.com  Thu Apr 15 16:27:59 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 16 Apr 2010 00:27:59 +1000
Subject: [Python-ideas] @return?
In-Reply-To: <37574C03-1AE0-471C-9BF1-90B644E8F8E0@masklinn.net>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>	<4BC63CBD.1050905@gmx.net>
	<4BC650BC.9070608@googlemail.com>	<78A04D86-7998-4E54-B6DE-0C613666CBA7@masklinn.net>	<4BC6F275.20506@googlemail.com>
	<37574C03-1AE0-471C-9BF1-90B644E8F8E0@masklinn.net>
Message-ID: <4BC7226F.7060107@gmail.com>

Masklinn wrote:
>> TypeError: <anonymous at b.py:42>() takes no arguments (1 given)
> 
> something along those lines. Tracking those infos would be necessary for
> debugging anyway.

Probably worth putting an RFE on the tracker for that idea. Best
suggestion I've seen in this thread, and I can't think of anything that
would make it impossible (not necessarily *easy*, but it should be
possible to come up with something).

Cheers,
Nick.

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


From ncoghlan at gmail.com  Thu Apr 15 16:30:00 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 16 Apr 2010 00:30:00 +1000
Subject: [Python-ideas] @return?
In-Reply-To: <4BC66A74.5060709@canterbury.ac.nz>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>
	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>
	<4BC66A74.5060709@canterbury.ac.nz>
Message-ID: <4BC722E8.8080506@gmail.com>

Greg Ewing wrote:
> Nick Coghlan wrote:
>> identify
>> what tools they need in the functools module in order to make Python
>> expressions Turing complete (you should be able to use functional
>> programming tricks to attain that without needing to introduce embedded
>> assignments).
> 
> Functional programming tricks used to achieve that
> typically rely a lot on recursion and tail call
> optimisation, which Python isn't likely to get.

Ah, good point.

Cheers,
Nick.

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


From george.sakkis at gmail.com  Thu Apr 15 16:31:00 2010
From: george.sakkis at gmail.com (George Sakkis)
Date: Thu, 15 Apr 2010 16:31:00 +0200
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <l2j6f4025011004150443jf5e967e6mab09adc8217e326a@mail.gmail.com>
References: <20100415050237.GE7185@idyll.org>
	<3469fb78-8f87-4fa5-9df5-feec80dfcddd@h27g2000yqm.googlegroups.com>
	<l2j6f4025011004150443jf5e967e6mab09adc8217e326a@mail.gmail.com>
Message-ID: <g2n91ad5bf81004150731s13133465sac9e1fa37c11f645@mail.gmail.com>

On Thu, Apr 15, 2010 at 1:43 PM, Michael Foord <fuzzyman at gmail.com> wrote:
>
>
> On 15 April 2010 08:02, alex23 <wuwei23 at gmail.com> wrote:
>>
>> On Apr 15, 3:02?pm, "C. Titus Brown" <c... at msu.edu> wrote:
>> > ? ?b = bag(foo=bar, baz=bif)
>> >
>> > ? ?assert b.foo == bar
>> > ? ?assert b.bz == bif
>>
>> I've always known this as a 'bunch' after Alex Martelli's recipe[1].
>> It's handy, but at 3 lines of code not an urgent candidate (IMO) for
>> stdlib:
>>
>> ?class Bunch:
>> ? ?def __init__(self, **kwds):
>> ? ? ?self.__dict__.update(kwds)
>
>
> Yeah, we've used this class a tonne - especially for testing where you just
> need a quick object with a bunch of attributes. I think we added a repr as
> well. It would certainly be a nice harmless addition to the collections
> module.
>
> Michael

In the past I've found useful a hybrid of the 'bunch' and the namedtuple[1].

George

[1] http://code.activestate.com/recipes/576555-records/


From ncoghlan at gmail.com  Thu Apr 15 16:40:10 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 16 Apr 2010 00:40:10 +1000
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <20100415133702.78f1394b@o>
References: <20100415133702.78f1394b@o>
Message-ID: <4BC7254A.9020304@gmail.com>

spir ? wrote:
> What useful distinctions are or may be done, for instance in documentation?

Python mainly considers:

object identity (x is y, determined by id())
object value (x == y, determined by the implementations of relevant
__eq__ methods)

For many objects, their value degenerates to being the same as their
identity (i.e. they compare equal only with themselves), but others have
for more useful comparisons defined (e.g. containers, numbers).

In addition to objects with their identities and values, there are
references to objects. These 'references' are the only things in Python
which aren't first class objects, since they reflect lookup entries in
some namespace or container, such as the mapping from names to pointers
in a class or module __dict__ or a function's locals, or the items
stored in a list or set.

Cheers,
Nick.

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


From denis.spir at gmail.com  Thu Apr 15 19:42:51 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Thu, 15 Apr 2010 19:42:51 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC63CBD.1050905@gmx.net>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o>
	<4BC5F047.8060306@googlemail.com>
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC63914.7060206@gmail.com> <4BC63CBD.1050905@gmx.net>
Message-ID: <20100415194251.12d847ee@o>

On Thu, 15 Apr 2010 00:07:57 +0200
Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:

> Maybe only allow them at certain places where they can be seen as an extension to an already 
> existing statement syntax (not to an expression syntax):
> 
> foo.bar = def(egg, spam):
> 	pass
> 
> return def(egg, spam):
> 	pass
> 
> yield def(egg, spam):
> 	pass

This is more or less the same argument as what I stated in a previous post: the issue is a different, incompatible, format for func defs, compared to ordinary expression. The possible name prefixing the definition breaks the pattern. More precisely, "def" (or "function"/"method") should come just before the parameter list to allow a func def be used like any other expression.
This won't change... but what about an alternative, like in Lua?

Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From denis.spir at gmail.com  Thu Apr 15 19:56:44 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Thu, 15 Apr 2010 19:56:44 +0200
Subject: [Python-ideas] question - 'bag' type
In-Reply-To: <20100415053038.GE29949@idyll.org>
References: <20100415050237.GE7185@idyll.org>
	<j2reae285401004142208m56183c63l44c5aa5e65251839@mail.gmail.com>
	<20100415051238.GB29949@idyll.org>
	<s2xcf5b87741004142222r25bbd216ib1ce7edadd1d3857@mail.gmail.com>
	<20100415053038.GE29949@idyll.org>
Message-ID: <20100415195644.4d3fe8ca@o>

On Wed, 14 Apr 2010 22:30:38 -0700
"C. Titus Brown" <ctb at msu.edu> wrote:

> I guess I don't understand what a bag is -- I'd just heard this structure
> referred to as such.
> 
> "dict aside from syntax" is the point, yes!

Then what you need is an interface transforming pseudo-keys into attr names. (I do that often, esp. for config objects read from text files in which the user only specifies differences from default -- then I can access config elements using object syntax -- seems to be similar to your expectations).
Just use setattr / getattr to build a generic class for such needs. It makes a flexible type for data "units" (composite objects); flexible in that the attr names are data themselves.

Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From conrad.irwin at googlemail.com  Thu Apr 15 20:07:46 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Thu, 15 Apr 2010 19:07:46 +0100
Subject: [Python-ideas] @return?
In-Reply-To: <20100415194251.12d847ee@o>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>
	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>
	<4BC63CBD.1050905@gmx.net> <20100415194251.12d847ee@o>
Message-ID: <4BC755F2.7050002@googlemail.com>



On 04/15/2010 06:42 PM, spir ? wrote:
> On Thu, 15 Apr 2010 00:07:57 +0200
> Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:
> 
>> Maybe only allow them at certain places where they can be seen as an extension to an already 
>> existing statement syntax (not to an expression syntax):
>>
>> foo.bar = def(egg, spam):
>> 	pass
>>
>> return def(egg, spam):
>> 	pass
>>
>> yield def(egg, spam):
>> 	pass
> 
> This is more or less the same argument as what I stated in a previous post: the issue is a different, incompatible, format for func defs, compared to ordinary expression. The possible name prefixing the definition breaks the pattern. More precisely, "def" (or "function"/"method") should come just before the parameter list to allow a func def be used like any other expression.
> This won't change... but what about an alternative, like in Lua?
> 
It's hard to see that an alternative syntax for scoping a block is going
to be acceptable. A syntax like "@return", couple with expanding the
allowable forms of the def name solve many issues. Perhaps the only
remaining "missing" feature is passing functions to functions, though I
think that could be done with something like a "call" block:

call filter:
    def lt(x):
        return x < 2
    [1,2,3,4]

Which would work more elegantly if all functions had named parameters:

call filter:
    def fun(x):
        return x < 2
    seq=[1,2,3,4]

And it might be possible to restrict the contents of the block to only
be functions - somewhat reducing its functionality, but retaining the
"only one way to do it".

call partial(filter, seq=[1,2,3,4]):
    def fun(x):
        return x < 2

Conrad



From denis.spir at gmail.com  Thu Apr 15 20:13:48 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Thu, 15 Apr 2010 20:13:48 +0200
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <4BC71545.5010804@googlemail.com>
References: <20100415133702.78f1394b@o>
	<4BC71545.5010804@googlemail.com>
Message-ID: <20100415201348.5d85bd06@o>

On Thu, 15 Apr 2010 14:31:49 +0100
Conrad Irwin <conrad.irwin at googlemail.com> wrote:

> 
> On 04/15/2010 12:37 PM, spir ? wrote:
> > Hello,
> > 
> > I have been recently thinking at lexical distinctions around the notion of data. (--> eg for a starting point http://c2.com/cgi/wiki?WhatIsData) Not only but especially in Python. I ended up with the following questions:
> > Can one state "in Python value=data=object"?
> > Can one state "in Python speak value=data=object"?
> > 
> > What useful distinctions are or may be done, for instance in documentation?
> > What kind of difference in actual language semantics may such distinctions mirror?
> 
> Uh.. you are trying to have a discussion about detailed semantics
> without defining what you mean by any of your terminology.

This is precisely the point: how to properly use given terms -- giving them semantic distinctions or not.

> [...]

> (and for the most part, objects with the same values have different data too).

Right, this makes sense for me. And do you mean data are different as soon as located at different places in memory even if bit-per-bit equal? Or only that value holds a notion of interpretation (due to the type)?

> [...]

> It shouldn't
> be necessary to make the distinction between an object and its value in
> documentation (though it is (I presume) occasionally useful in actual
> code to distinguish objects with the same datum, perhaps in cycle
> detection).

Thank you. Let us take the case of a simple assignment:
   name = expression
Once the expression is evaluated, what we get is commonly called a value, right? But in numerous places the result of data lookup is called object instead. While conceptually, for me, it's exactly the same thing.
   x.a = 1
results in an attribute 'a' with "value" 1, in x.
   b = x.a
looks up for the "object" denoted to by the attr name 'a' in x.

(I'm not trying to annoy people, just to clarify common notions.)

> Conrad



________________________________

vit esse estrany ?

spir.wikidot.com


From guido at python.org  Thu Apr 15 20:36:28 2010
From: guido at python.org (Guido van Rossum)
Date: Thu, 15 Apr 2010 11:36:28 -0700
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <20100415201348.5d85bd06@o>
References: <20100415133702.78f1394b@o> <4BC71545.5010804@googlemail.com> 
	<20100415201348.5d85bd06@o>
Message-ID: <k2mca471dc21004151136wf7f1cba4sb06804710a611924@mail.gmail.com>

2010/4/15 spir ? <denis.spir at gmail.com>:
> On Thu, 15 Apr 2010 14:31:49 +0100
> Conrad Irwin <conrad.irwin at googlemail.com> wrote:
>
>>
>> On 04/15/2010 12:37 PM, spir ? wrote:
>> > Hello,
>> >
>> > I have been recently thinking at lexical distinctions around the notion of data. (--> eg for a starting point http://c2.com/cgi/wiki?WhatIsData) Not only but especially in Python. I ended up with the following questions:
>> > Can one state "in Python value=data=object"?
>> > Can one state "in Python speak value=data=object"?
>> >
>> > What useful distinctions are or may be done, for instance in documentation?
>> > What kind of difference in actual language semantics may such distinctions mirror?
>>
>> Uh.. you are trying to have a discussion about detailed semantics
>> without defining what you mean by any of your terminology.
>
> This is precisely the point: how to properly use given terms -- giving them semantic distinctions or not.

Data is a buzzword.

Object is, well, an object. It has a distinct
id/address/location/whatever. (Though these may be reused after an
object is destroyed.)

Value is semantically defined by the type/class -- e.g. for numbers,
two objects with the value 1 have the same value (even if the type is
different, e.g. 1 and 1.0); and similar for strings. But for other
object types the value is just the object identity. And for tuples it
actually depends on the items. IOW values are defined by __eq__.

>> [...]
>
>> (and for the most part, objects with the same values have different data too).
>
> Right, this makes sense for me. And do you mean data are different as soon as located at different places in memory even if bit-per-bit equal? Or only that value holds a notion of interpretation (due to the type)?

There is no notion of bit-per-bit equal. Only object identity (same
address) and value equality defined by __eq__.

>> [...]
>
>> It shouldn't
>> be necessary to make the distinction between an object and its value in
>> documentation (though it is (I presume) occasionally useful in actual
>> code to distinguish objects with the same datum, perhaps in cycle
>> detection).
>
> Thank you. Let us take the case of a simple assignment:
> ? name = expression
> Once the expression is evaluated, what we get is commonly called a value, right?

No, an object. (Which has a value but the meaning of the value depends
on the type.)

> But in numerous places the result of data lookup is called object instead.

Please stop using 'data'. It has no meaning in this context.

> While conceptually, for me, it's exactly the same thing.
> ? x.a = 1
> results in an attribute 'a' with "value" 1, in x.

No, attribute lookup returns an object, not a value.

> ? b = x.a
> looks up for the "object" denoted to by the attr name 'a' in x.

All this is defined by object semantics. Value semantics apply at a later level.

> (I'm not trying to annoy people, just to clarify common notions.)

-- 
--Guido van Rossum (python.org/~guido)


From bruce at leapyear.org  Thu Apr 15 20:41:33 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Thu, 15 Apr 2010 11:41:33 -0700
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <20100415201348.5d85bd06@o>
References: <20100415133702.78f1394b@o> <4BC71545.5010804@googlemail.com> 
	<20100415201348.5d85bd06@o>
Message-ID: <n2ocf5b87741004151141gfeda380xe3f68874e55f975b@mail.gmail.com>

data = plural of datum

both words are commonly misused as to singular/plural usage.
"piece/unit/item of data" is a common substitution for "datum" by people who
don't know the word. [Likewise, "media" is the plural of "medium" but people
get that confused too.]

With numbers, a single number is a datum. More than one numbers are data.

You would never refer to "the value X" (where X is a python variable) but
you would refer to "the value 3" or "the value pi". Generally, in English
when people say "data" they're referring to the numbers in a more abstract
sense than 3 and pi.

I would say that roughly:

value : datum :: instance : object

But this is hardly precise. People frequently refer to A as an object when
we really mean it's an instance of the object [e.g., class] Alpha.

--- Bruce
http://www.vroospeak.com


2010/4/15 spir ? <denis.spir at gmail.com>

> On Thu, 15 Apr 2010 14:31:49 +0100
> Conrad Irwin <conrad.irwin at googlemail.com> wrote:
>
> >
> > On 04/15/2010 12:37 PM, spir ? wrote:
> > > Hello,
> > >
> > > I have been recently thinking at lexical distinctions around the notion
> of data. (--> eg for a starting point http://c2.com/cgi/wiki?WhatIsData)
> Not only but especially in Python. I ended up with the following questions:
> > > Can one state "in Python value=data=object"?
> > > Can one state "in Python speak value=data=object"?
> > >
> > > What useful distinctions are or may be done, for instance in
> documentation?
> > > What kind of difference in actual language semantics may such
> distinctions mirror?
> >
> > Uh.. you are trying to have a discussion about detailed semantics
> > without defining what you mean by any of your terminology.
>
> This is precisely the point: how to properly use given terms -- giving them
> semantic distinctions or not.
>
> > [...]
>
> > (and for the most part, objects with the same values have different data
> too).
>
> Right, this makes sense for me. And do you mean data are different as soon
> as located at different places in memory even if bit-per-bit equal? Or only
> that value holds a notion of interpretation (due to the type)?
>
> > [...]
>
> > It shouldn't
> > be necessary to make the distinction between an object and its value in
> > documentation (though it is (I presume) occasionally useful in actual
> > code to distinguish objects with the same datum, perhaps in cycle
> > detection).
>
> Thank you. Let us take the case of a simple assignment:
>   name = expression
> Once the expression is evaluated, what we get is commonly called a value,
> right? But in numerous places the result of data lookup is called object
> instead. While conceptually, for me, it's exactly the same thing.
>   x.a = 1
> results in an attribute 'a' with "value" 1, in x.
>   b = x.a
> looks up for the "object" denoted to by the attr name 'a' in x.
>
> (I'm not trying to annoy people, just to clarify common notions.)
>
> > Conrad
>
>
>
> ________________________________
>
> vit esse estrany ?
>
> spir.wikidot.com
> _______________________________________________
> 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/20100415/344803e9/attachment.html>

From guido at python.org  Thu Apr 15 21:00:23 2010
From: guido at python.org (Guido van Rossum)
Date: Thu, 15 Apr 2010 12:00:23 -0700
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <n2ocf5b87741004151141gfeda380xe3f68874e55f975b@mail.gmail.com>
References: <20100415133702.78f1394b@o> <4BC71545.5010804@googlemail.com> 
	<20100415201348.5d85bd06@o>
	<n2ocf5b87741004151141gfeda380xe3f68874e55f975b@mail.gmail.com>
Message-ID: <w2jca471dc21004151200u64ae5e25zcf1b1a72a25a8a40@mail.gmail.com>

2010/4/15 Bruce Leban <bruce at leapyear.org>:
> data = plural of datum
> both words are commonly misused as to singular/plural usage.

Too pedantic.

> "piece/unit/item of data" is a common substitution for "datum" by people who
> don't know the word. [Likewise, "media" is the plural of "medium" but people
> get that confused too.]

> With numbers, a single number is a datum. More than one numbers are data.
> You would never refer to "the value X" (where X is a python variable) but
> you would refer to "the value 3" or "the value pi". Generally, in English
> when people say "data" they're referring to the numbers in a more abstract
> sense than 3 and pi.

> I would say that roughly:
> value : datum :: instance : object
>
> But this is hardly precise. People frequently refer to A as an object when
> we really mean it's an instance of the object [e.g., class] Alpha.

No. In Python, object always refers to an instance. "An instance of an
object" is nonsense (unless the object happens to be a class object,
in which case the object's class is also called a metaclass).

We do use type and class interchangeably in Python. (Except in very
old Python versions where type refers to a built-in type or a type
defined by a built-in or extension module, and class refers to a
user-defined class -- but in modern Python there is no longer a
difference.)

-- 
--Guido van Rossum (python.org/~guido)


From bruce at leapyear.org  Thu Apr 15 21:22:16 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Thu, 15 Apr 2010 12:22:16 -0700
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <w2jca471dc21004151200u64ae5e25zcf1b1a72a25a8a40@mail.gmail.com>
References: <20100415133702.78f1394b@o> <4BC71545.5010804@googlemail.com> 
	<20100415201348.5d85bd06@o>
	<n2ocf5b87741004151141gfeda380xe3f68874e55f975b@mail.gmail.com>
	<w2jca471dc21004151200u64ae5e25zcf1b1a72a25a8a40@mail.gmail.com>
Message-ID: <u2mcf5b87741004151222v44d83784s8d03503e39f34f52@mail.gmail.com>

Sorry -- Denis asked not just about Python but about English and I was
speaking in that context and it's hard to not be pedantic in that case. :-)

Even if Python defines precise meanings of 'object', 'class', 'metaclass'
most of us use other languages too which use those words differently so
there will invariably be some cross-leakage. I know a programming system
that uses the word 'model' where others use table and 'entity' where others
use row. :-)

--- Bruce
http://www.vroospeak.com


On Thu, Apr 15, 2010 at 12:00 PM, Guido van Rossum <guido at python.org> wrote:

> 2010/4/15 Bruce Leban <bruce at leapyear.org>:
> > data = plural of datum
> > both words are commonly misused as to singular/plural usage.
>
> Too pedantic.
>
> > "piece/unit/item of data" is a common substitution for "datum" by people
> who
> > don't know the word. [Likewise, "media" is the plural of "medium" but
> people
> > get that confused too.]
>
> > With numbers, a single number is a datum. More than one numbers are data.
> > You would never refer to "the value X" (where X is a python variable) but
> > you would refer to "the value 3" or "the value pi". Generally, in English
> > when people say "data" they're referring to the numbers in a more
> abstract
> > sense than 3 and pi.
>
> > I would say that roughly:
> > value : datum :: instance : object
> >
> > But this is hardly precise. People frequently refer to A as an object
> when
> > we really mean it's an instance of the object [e.g., class] Alpha.
>
> No. In Python, object always refers to an instance. "An instance of an
> object" is nonsense (unless the object happens to be a class object,
> in which case the object's class is also called a metaclass).
>
> We do use type and class interchangeably in Python. (Except in very
> old Python versions where type refers to a built-in type or a type
> defined by a built-in or extension module, and class refers to a
> user-defined class -- but in modern Python there is no longer a
> difference.)
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100415/6bbcb3ec/attachment.html>

From grosser.meister.morti at gmx.net  Thu Apr 15 21:30:03 2010
From: grosser.meister.morti at gmx.net (=?UTF-8?B?TWF0aGlhcyBQYW56ZW5iw7Zjaw==?=)
Date: Thu, 15 Apr 2010 21:30:03 +0200
Subject: [Python-ideas] @return?
In-Reply-To: <4BC755F2.7050002@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>	<4BC50AEC.8000901@googlemail.com>	<20100414165421.4d97a595@o>	<4BC5F047.8060306@googlemail.com>	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>	<4BC63914.7060206@gmail.com>	<4BC63CBD.1050905@gmx.net>
	<20100415194251.12d847ee@o> <4BC755F2.7050002@googlemail.com>
Message-ID: <4BC7693B.3060506@gmx.net>

On 04/15/2010 08:07 PM, Conrad Irwin wrote:
 >
 > It's hard to see that an alternative syntax for scoping a block is going
 > to be acceptable. A syntax like "@return", couple with expanding the
 > allowable forms of the def name solve many issues. Perhaps the only
 > remaining "missing" feature is passing functions to functions, though I
 > think that could be done with something like a "call" block:
 >
 > call filter:
 >      def lt(x):
 >          return x<  2
 >      [1,2,3,4]

maybe just:

filter(lt,[1,2,3,4]):
	def lt(x):
		return x < 2

or

filter(lt,[1,2,3,4]) where:
	def lt(x):
		return x < 2

basically something like where in haskell. but then dis doesnt save much, just reverses the order of 
the statements (and possibly removes lt from the scope after filter was called). is that really enough?

	-panzi


From alan.gauld at btinternet.com  Thu Apr 15 23:37:51 2010
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Thu, 15 Apr 2010 22:37:51 +0100
Subject: [Python-ideas] "value" ~ "data" ~ "object"
References: <20100415133702.78f1394b@o>
Message-ID: <hq80vp$h2h$1@dough.gmane.org>


"spir ?" <denis.spir at gmail.com> wrote

Lots of points here and I suspect the English usage will vary greatly 
between
the different English communities.

>especially in Python. I ended up with the following questions:
> Can one state "in Python value=data=object"?
> Can one state "in Python speak value=data=object"?

I'm not sure I understand your distinction between the two statements.

I think in Python it's true to say that value=object but the rule is not 
commutative.
object !=value in every case. (A function is an object but is not really a 
value
(although it will return a value if called, and of course has an id() and 
is
"not None", so in that sense is a value - but that is I think a special 
case)

Data is a concept and is wider than mere values or objects. values can be 
data.
But so can rules. Now a rule can be expressed as a function or as a 
mapping,
and the mapping will contain values, but the mapping - the relationships - 
are
not explicit values, they are rules inherent to the mapping. But the 
mapping
is data.

Objects differ from pure values in most languages in that they usually 
(always?)
have operations (at least a constructor, and in modern Python much more). 
But
since I said that all values in Python are objects their difference here is 
moot.

> What useful distinctions are or may be done, for instance in 
> documentation?
> What kind of difference in actual language semantics may such 
> distinctions mirror?

My dictionary defines data as
    facts or figures from which conclusions can be inferred; information

facts are not always the same as values (defined as "measures" so by 
definition
relative - you can compare values against a known datum of similar type
(which is another concept again!) but you cannot really compare facts other
than by their truthfulness, but then, an untruthful fact is not a fact!)

> PS: side-question on english:
> I am annoyed by the fact that in english "data" is mainly used & 
> understood
> as a collective (uncountable) noun. "datum" (singular) & "datas" (plural) 
> seem
> to be considered weird.

Speaking for the English English:
"datas" is weird, in fact it is a non-word so far as I know.
"datum" is perfectly acceptable and most well read people will recognise it
although it is not a commonly used word. But it is by no means restricted 
to the
scientific community.
Common parlance uses data as both plural and singular, much as sheep is
used both ways. "data set" is often used when plurality is being 
emphasised.
(I have a friend (who works in MIS systems) who is very particular about 
his
use of data/datum.)

> How to denote a single unit of data wothout using the phrase "piece of 
> data"?

datum does just fine. Or sometimes "data point" is used.

> Can one still use "datum" or "datas" (or "data" as plural) and be 
> trivially
> understood by *anybody* (not only scientists)?

datum and data are fine when the plurality is obvious. Otherwise I tend to
use data set to emphasise plurality. Never use datas!

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.alan-g.me.uk/ 




From wuwei23 at gmail.com  Fri Apr 16 04:52:18 2010
From: wuwei23 at gmail.com (alex23)
Date: Thu, 15 Apr 2010 19:52:18 -0700 (PDT)
Subject: [Python-ideas] @return?
In-Reply-To: <4BC5F047.8060306@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
	<t2heae285401004131541nd34192cdl8fb86b6f1d305d0@mail.gmail.com>
	<4BC50AEC.8000901@googlemail.com> <20100414165421.4d97a595@o> 
	<4BC5F047.8060306@googlemail.com>
Message-ID: <b7fefceb-238b-40eb-8baf-cac5377d7d20@j17g2000yqa.googlegroups.com>

Conrad Irwin <conrad.ir... at googlemail.com> wrote:
> ? ? result = register_callback(def success(arg):
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?print(arg)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? )
>
> I think it is significantly nicer than the decorator abuse:
>
> ? ? @register_callback
> ? ? def result(arg):
> ? ? ? ? print(arg)

How is that an abuse of the decorator syntax?

How is your @return syntax more clear in its intent than:

   from decorator import decorator

   @decorator
   def a_decorator(...):
      ....

Is returning a function from within another function - outside of
decorators - that recurring a task that we need new syntax that not
only overloads existing syntax for a different use, but also disrupts
the readability of a function?


From stephen at xemacs.org  Fri Apr 16 08:35:04 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 16 Apr 2010 15:35:04 +0900
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <n2ocf5b87741004151141gfeda380xe3f68874e55f975b@mail.gmail.com>
References: <20100415133702.78f1394b@o> <4BC71545.5010804@googlemail.com>
	<20100415201348.5d85bd06@o>
	<n2ocf5b87741004151141gfeda380xe3f68874e55f975b@mail.gmail.com>
Message-ID: <8739yvaorr.fsf@uwakimon.sk.tsukuba.ac.jp>

Bruce Leban writes:

 > I would say that roughly:
 > 
 > value : datum :: instance : object

You can say that if you like, but unfortunately you cannot expect
others to take that meaning without an explicit gloss to explain what
you mean.  Data in the broadest sense (as the plural of datum) is just
tiny pieces of unstructured information, but it is often used in other
senses, such as coextensive with "information", or connoting an array
of information pieces of some type, or a stream of information pieces
conforming to some syntax.  Because of current common usage, it is
most useful as a collective noun for "information" when you don't want
to be precise.

Since in English it is rare that we are precise about the "sense" in
which we use "data", I agree with Guido that the word should be
avoided in this kind of discussion.


From lie.1296 at gmail.com  Fri Apr 16 12:49:42 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Fri, 16 Apr 2010 20:49:42 +1000
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <hq80vp$h2h$1@dough.gmane.org>
References: <20100415133702.78f1394b@o> <hq80vp$h2h$1@dough.gmane.org>
Message-ID: <hq9feq$i1c$1@dough.gmane.org>

On 04/16/10 07:37, Alan Gauld wrote:
> 
> "spir ?" <denis.spir at gmail.com> wrote
> 
> Lots of points here and I suspect the English usage will vary greatly
> between
> the different English communities.
> 
>> especially in Python. I ended up with the following questions:
>> Can one state "in Python value=data=object"?
>> Can one state "in Python speak value=data=object"?
> 
> I'm not sure I understand your distinction between the two statements.
> 
> I think in Python it's true to say that value=object but the rule is not
> commutative.
> object !=value in every case. 

I'm sorry, but I'm not sure how you define your equality; in my textbook
equality is a relationship that is "reflexive, symmetric, and
transitive" (commutative is just another way to say symmetric). I'm not
sure what you meant when you say value == object but object != value.
Did you mean value *is an* object but object *is not (necessarily) a* value?

> (A function is an object but is not really a value
> (although it will return a value if called, and of course has an id()
> and is "not None", so in that sense is a value - but that is I think a special
> case)
> 
> Data is a concept and is wider than mere values or objects. values can
> be data. But so can rules. Now a rule can be expressed as a function or as a
> mapping, and the mapping will contain values, but the mapping - the relationships
> - are not explicit values, they are rules inherent to the mapping. But the
> mapping is data.

You don't need to define a mapping; since definition of mapping can be
derived from function:
- mapping is the set of all (x, F(x))
but so do function can be defined from a mapping:
- f(x) = y iff (x,y) ? {set of 2-tuple}

so we can say that a mapping and function is equivalent:

> Objects differ from pure values in most languages in that they usually
> (always?) have operations (at least a constructor, and in modern Python much
> more). But since I said that all values in Python are objects their difference here
> is moot.
> 
>> What useful distinctions are or may be done, for instance in
>> documentation?
>> What kind of difference in actual language semantics may such
>> distinctions mirror?
> 
> My dictionary defines data as
>    facts or figures from which conclusions can be inferred; information

I guess the problem here is the distinction between data, value, object
depends on how you define it. IOW, trying to make a concrete distinction
from an inconcrete axioms/definition is bound to be futile.

Many Information Systems people like to differentiate between data and
information; most English dictionaries does not.

> facts are not always the same as values (defined as "measures" so by
> definition relative - you can compare values against a known datum of similar type
> (which is another concept again!) but you cannot really compare facts other
> than by their truthfulness, but then, an untruthful fact is not a fact!)



From lie.1296 at gmail.com  Fri Apr 16 14:30:37 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Fri, 16 Apr 2010 22:30:37 +1000
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <k2mca471dc21004151136wf7f1cba4sb06804710a611924@mail.gmail.com>
References: <20100415133702.78f1394b@o> <4BC71545.5010804@googlemail.com>
	<20100415201348.5d85bd06@o>
	<k2mca471dc21004151136wf7f1cba4sb06804710a611924@mail.gmail.com>
Message-ID: <hq9lbs$8o8$1@dough.gmane.org>

On 04/16/10 04:36, Guido van Rossum wrote:
> Object is, well, an object. It has a distinct
> id/address/location/whatever. (Though these may be reused after an
> object is destroyed.)

IMHO, the fact that the return value of id(...) can be reused by
different object is a bug (though a bug that have no practical impact
for most real-life program and other possible alternative
implementations I can think of are no good for practical purposes)



From conrad.irwin at googlemail.com  Fri Apr 16 17:11:56 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Fri, 16 Apr 2010 16:11:56 +0100
Subject: [Python-ideas] Fwd: Re:  @return?
Message-ID: <4BC87E3C.8060201@googlemail.com>

On 04/16/2010 03:52 AM, alex23 wrote:
> Conrad Irwin <conrad.ir... at googlemail.com> wrote:
>>     result = register_callback(def success(arg):
>>                                    print(arg)
>>                               )
>>
>> I think it is significantly nicer than the decorator abuse:
>>
>>     @register_callback
>>     def result(arg):
>>         print(arg)
> 
> How is that an abuse of the decorator syntax?

Well, It would be clearer expanded as:

    def success(arg):
        print(arg)

    result = register_callback(success)

But in order to assign the result to "result", I renamed the function,
register_callback returns an int.

> 
> How is your @return syntax more clear in its intent than:
> 
>    from decorator import decorator
> 
>    @decorator
>    def a_decorator(...):
>       ....

@decorator solves one common case extremely well, though perusing its
documentation I notice lots of "@return" use still - in any decorator
that takes parameters before the function (arguably this could be solved
by modifying "@decorator"). I also feel that, in the memoize example,
the author has gone out of his way to use @decorator where creating an
enclosing scope and "@return"ing would be less intrusive.

> Is returning a function from within another function - outside of
> decorators - that recurring a task that we need new syntax that not
> only overloads existing syntax for a different use, but also disrupts
> the readability of a function?

In light of the above, yes, there are enough uses for it, and the
feeling of cleanliness it provides. Using it with classes is also useful
(found in django) - though much rarer:

def infix(bp, func):

    class Operator(TokenBase):
        ...
        def led(self, left, parser):
            ...

        def eval(self, context):
            ...

    return Operator


The syntax overloading was intentional, "@return" is very like a
decorator in behaviour (albeit not in implementation). Introducing a new
syntax to do something so similar seems very heavy-handed.

Having @return next to the definition emphasizes that flow of control,
and (particularly for lengthy definitions) doesn't leave an orphaned
return statement floating somewhere at the end.

def infix(bp, func):

    @return
    class Operator(TokenBase):
        ...
        def led(self, left, parser):
            ...

        def eval(self, context):
            ...

Obviously, on matters of aesthetics, anyone can be right. I am, however,
convinced that avoiding repetition (even if it is just of a name) in an
unambiguous manner is a worthy goal.

Conrad


From lie.1296 at gmail.com  Fri Apr 16 19:16:19 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Sat, 17 Apr 2010 03:16:19 +1000
Subject: [Python-ideas] @return?
In-Reply-To: <4BC4E3D8.4050206@googlemail.com>
References: <4BC4E3D8.4050206@googlemail.com>
Message-ID: <hqa63n$el3$1@dough.gmane.org>

On 04/14/10 07:36, Conrad Irwin wrote:
> The proposal is thus to introduce "@return" that returns the decorated
> object, a hybrid of the behavior of the return statement and decorators.
> I think the intended semantics are clear, providing you know the basics
> of how decorators work:
> 
>     def decorator(func):
>         @return
>         def wrapper(*args):
>             func(modulate(args))

Why stop half-way? Why not eliminate the nested defs as well:

@decorator(func)
def wrapper(*args):
    func(modulate(args))

to mean:

def decorator(func):
    def wrapper(*args):
        func(modulate(args))
    return wrapper



From alan.gauld at btinternet.com  Sat Apr 17 01:36:31 2010
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Sat, 17 Apr 2010 00:36:31 +0100
Subject: [Python-ideas] "value" ~ "data" ~ "object"
References: <20100415133702.78f1394b@o> <hq80vp$h2h$1@dough.gmane.org>
	<hq9feq$i1c$1@dough.gmane.org>
Message-ID: <hqasaa$srh$1@dough.gmane.org>

"Lie Ryan" <lie.1296 at gmail.com> wrote

> I'm sorry, but I'm not sure how you define your equality; ...
> Did you mean value *is an* object but object *is not (necessarily) a* value?

Yes, exactly. On reflection "="  was probably the wrong symbol to use.

>> mapping is data.
> 
> You don't need to define a mapping; since definition of mapping can be
> derived from function:

True but that's the point I was making.
The mapping whether implemented as a table/dictionary or 
as a function is still a form of data but it is not a value or even
a set of values.

> I guess the problem here is the distinction between data, value, object
> depends on how you define it. IOW, trying to make a concrete distinction
> from an inconcrete axioms/definition is bound to be futile.

Indeed, and I'm very aware that Denis is coming from another 
language and even within English there are there are geographical 
differences of idiom and definition for the same words. It is therefore 
very difficult to be absolutely precise in any such discussion.

> Many Information Systems people like to differentiate between data and
> information; most English dictionaries does not.

Ooh I was deliverately steering clear of the distinctions between data, 
information and knowledge! There lie religious wars! :-)

Likewise the distinctions between Type and class can take many twists.


-- 
Alan Gauld
Author of the Learn to Program web site
http://www.alan-g.me.uk/



From stephen at xemacs.org  Sat Apr 17 07:55:01 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 17 Apr 2010 14:55:01 +0900
Subject: [Python-ideas] "value" ~ "data" ~ "object"
In-Reply-To: <hqasaa$srh$1@dough.gmane.org>
References: <20100415133702.78f1394b@o> <hq80vp$h2h$1@dough.gmane.org>
	<hq9feq$i1c$1@dough.gmane.org> <hqasaa$srh$1@dough.gmane.org>
Message-ID: <87pr1yoc7e.fsf@uwakimon.sk.tsukuba.ac.jp>

Alan Gauld writes:

 > Ooh I was deliverately steering clear of the distinctions between data, 
 > information and knowledge! There lie religious wars! :-)

That's precisely why Guido says "don't say 'data' in this context."

It's not your choice to steer clear of those differences of
definition, it's your reader's, and she is not going to be aware that
it's necessary unless you explain.  You can't win here.



From cmjohnson.mailinglist at gmail.com  Sun Apr 18 02:46:20 2010
From: cmjohnson.mailinglist at gmail.com (Carl M. Johnson)
Date: Sat, 17 Apr 2010 14:46:20 -1000
Subject: [Python-ideas] @return?
In-Reply-To: <4BC7693B.3060506@gmx.net>
References: <4BC4E3D8.4050206@googlemail.com>
	<4BC50AEC.8000901@googlemail.com> 
	<20100414165421.4d97a595@o> <4BC5F047.8060306@googlemail.com> 
	<BBFCCB0F-716A-4AF9-A1F1-4C9B9B775C2B@masklinn.net>
	<4BC63914.7060206@gmail.com> 
	<4BC63CBD.1050905@gmx.net> <20100415194251.12d847ee@o>
	<4BC755F2.7050002@googlemail.com> <4BC7693B.3060506@gmx.net>
Message-ID: <o2w3bdda691004171746v2c04071fj72be1ec9782a2341@mail.gmail.com>

On Thu, Apr 15, 2010 at 9:30 AM, Mathias Panzenb?ck wrote:

> filter(lt,[1,2,3,4]) where:
> ? ? ? ?def lt(x):
> ? ? ? ? ? ? ? ?return x < 2
>
> basically something like where in haskell. but then dis doesnt save much,
> just reverses the order of the statements (and possibly removes lt from the
> scope after filter was called). is that really enough?

If you look through the archives of python-ideas, you?ll find that
I?ve agitated for some version of this syntax several times. What I
really want is just to be able to have one or more lines written in
one order but executed in another. A where statement would do that.
Another proposal I had was


filter(@(x),[1,2,3,4]):
            return x < 2

Where ?@? meant, ?function taking these parameters, to be defined in
the block to follow.?

Another proposal was to allow decorators to use arbitrarily complex
expressions. Then one could write:

@lambda f: filter(f, [1, 2, 3, 4])
def results(x):
            return x < 2

I?ve seen some other interesting stuff being done with the
with-statement today (Ex.
http://code.google.com/p/ouspg/wiki/AnonymousBlocksInPython
http://pypi.python.org/pypi/withhacks ) and proposals to make ?with?
work more like an anonymous block in certain circumstances. Say

with filtering([1, 2, 3]) as result:
     def overtwo(x):
          return x < 2

(You can actually get that to work in today?s Python using withhacks,
but as the name implies, it is quite hacky, since it ends up taking
apart the stack to do its magic.)

My feeling is that until Python has some kind of block operator, these
discussions will pop up every 6 months or so. Here?s looking forward
to Fall 2010?s fruitless discussion. :-[

-- Carl M. Johnson


From zac256 at gmail.com  Tue Apr 20 04:37:54 2010
From: zac256 at gmail.com (Zac Burns)
Date: Mon, 19 Apr 2010 19:37:54 -0700
Subject: [Python-ideas] __decorate__ method
Message-ID: <m2o333edbe81004191937p967010fj8044ce86ea295992@mail.gmail.com>

I would like to propose an extension to behavior the decorator syntax. For
@decorator '@' should see if decorator supplies a __decorate__ method. If
so, call the __decorate__ method. Otherwise, call decorator directly.

Guido does say that __decorate__ should not replace __call__ here
http://markmail.org/message/ig6diu6j55flxr6c, saying

"""
Q: Is there a strong feeling (in any direction) about calling the
decorator's "decorate" or "__decorate__" attribute, rather than its
"__call__" attribute?

A: It should be __call__; that's the only backwards compatible way, and
makes it easy to create decorators as functions.

"""
(Sidenote: Can someone explain what the backward incompatibility is?)

There is one use case I have run into where I wanted to make a distinction
between __call__ and __decorate__. It is a Null object, which is like None
but supplies several interfaces. It's an empty collection, a context that
does nothing, a callable that returns None, and should be a decorator that
returns the original function - except that it's already a callable that
returns None. This object is cool for doing stuff like:
"""
with (blocking if block else Null):
   doSomething()
"""
Rather than
"""
if block:
   with blocking:
      doSomething()
else:
   doSomething
"""
And, it fits in several spots like "os.walk(x, onerror=Null)" for example.

I'll admit, the use case here is fairly spurious. There may be use cases
which are more 'real'. If not, *C'est la vie*.

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer
Zindagi Games
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100419/c59b6987/attachment.html>

From p.f.moore at gmail.com  Tue Apr 20 09:35:49 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Apr 2010 08:35:49 +0100
Subject: [Python-ideas] __decorate__ method
In-Reply-To: <m2o333edbe81004191937p967010fj8044ce86ea295992@mail.gmail.com>
References: <m2o333edbe81004191937p967010fj8044ce86ea295992@mail.gmail.com>
Message-ID: <h2r79990c6b1004200035p804919f6n7143c58a27e49016@mail.gmail.com>

On 20 April 2010 03:37, Zac Burns <zac256 at gmail.com> wrote:
> I would like to propose an extension to behavior the decorator syntax. For
> @decorator '@' should see if decorator supplies a __decorate__ method. If
> so, call the __decorate__ method. Otherwise, call decorator directly.
>
> Guido does say that __decorate__ should not replace __call__ here
> http://markmail.org/message/ig6diu6j55flxr6c, saying
>
> """
> Q: Is there a strong feeling (in any direction) about calling the
> decorator's "decorate" or "__decorate__" attribute, rather than its
> "__call__" attribute?
>
> A: It should be __call__; that's the only backwards compatible way, and
> makes it easy to create decorators as functions.
>
> """
>
> (Sidenote: Can someone explain what the backward incompatibility is?)

A key use case for decorators was to implement classmethods and
similar things, where the "old form" is to use f=classmethod(f) after
the definition.

class A:
    def f(cls):
        ...
    f = classmethod(f)

becomes

class A:
    @classmethod
    def f(cls):
        ...

The backward compatibility requirement is that classmethod (and
similar user defined cases) don't have to change.

> There is one use case I have run into where I wanted to make a distinction
> between __call__ and __decorate__. It is a Null object, which is like None
> but supplies several interfaces. It's an empty collection, a context that
> does nothing, a callable that returns None, and should be a decorator that
> returns the original function - except that it's already a callable that
> returns None. This object is cool for doing stuff like:
> """
> with (blocking if block else Null):
> ?? doSomething()
> """
> Rather than
> """
> if block:
> ?? with blocking:
> ????? doSomething()
> else:
> ?? doSomething
> """
> And, it fits in several spots like "os.walk(x, onerror=Null)" for example.
>
> I'll admit, the use case here is fairly spurious. There may be use cases
> which are more 'real'. If not, C'est la vie.

I can't see why you'd ever want to use Null as a decorator - so I'm
unconvinced by your use case. In any case, even if there is a reason
for having a null decorator, it's not clear to me that it can't be a
different object from your Null object - there's no reason to have all
the functionality covered by one "kitchen sink" object.

So sorry, but I'd say this proposal isn't justified (I'd assume it's
probably disallowed under the moratorium anyway).

Paul.


From jimjjewett at gmail.com  Tue Apr 20 16:13:17 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 20 Apr 2010 10:13:17 -0400
Subject: [Python-ideas] __decorate__ method
In-Reply-To: <h2r79990c6b1004200035p804919f6n7143c58a27e49016@mail.gmail.com>
References: <m2o333edbe81004191937p967010fj8044ce86ea295992@mail.gmail.com> 
	<h2r79990c6b1004200035p804919f6n7143c58a27e49016@mail.gmail.com>
Message-ID: <w2hfb6fbf561004200713ma215338eq77604dbb3c7b9ea3@mail.gmail.com>

On 20 April 2010 03:37, Zac Burns <zac256 at gmail.com> wrote:

> Guido does say that __decorate__ should not replace __call__

> (Sidenote: Can someone explain what the backward incompatibility is?)

Note that this only means it shouldn't *replace* __call__.  Using
__decorate__ if it exists and falling  back to __call__ would be
acceptable from a backwards compatibility standpoint.  (It may be
ruled out for ugliness or complication, but not for backwards
compatibility.)

-jJ


From ziade.tarek at gmail.com  Tue Apr 20 17:35:44 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 20 Apr 2010 17:35:44 +0200
Subject: [Python-ideas] Small enhancement to os.path.splitext
Message-ID: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>

Hello

Currently, os.path.splitext will split a string giving you the piece
behind the last dot:

>>> os.path.splitext('file.tar.gz')
('file.tar', '.gz')

In some cases, what we really want is the two last parts when
splitting on the dots (like in my example).

What about providing an extra argument to be able to grab more than one dot ?

>>> os.path.splitext('file.tar.gz', numext=2)
('file', '.tar.gz')

If numext > numbers of dots, it will just split after the first dot:

>>> os.path.splitext('file.tar', numext=2)
('file', '.tar')


What do you think ?

Regards
Tarek






-- 
Tarek Ziad? | http://ziade.org


From mal at egenix.com  Tue Apr 20 17:44:03 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 20 Apr 2010 17:44:03 +0200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
Message-ID: <4BCDCBC3.2090605@egenix.com>

Tarek Ziad? wrote:
> Hello
> 
> Currently, os.path.splitext will split a string giving you the piece
> behind the last dot:
> 
>>>> os.path.splitext('file.tar.gz')
> ('file.tar', '.gz')
> 
> In some cases, what we really want is the two last parts when
> splitting on the dots (like in my example).
> 
> What about providing an extra argument to be able to grab more than one dot ?
> 
>>>> os.path.splitext('file.tar.gz', numext=2)
> ('file', '.tar.gz')
> 
> If numext > numbers of dots, it will just split after the first dot:
> 
>>>> os.path.splitext('file.tar', numext=2)
> ('file', '.tar')
> 
> 
> What do you think ?

I'm not sure whether that would really solve anything.

The general problem with extensions is that they can span multiple
"dotted" parts in a filename, but whether they do or not depends
on the extensions.

E.g. you can have 'file.tar', 'file.tar.gz', 'file.tgz', 'file.tar.gz.uu',
'file.tag.gz.asc', 'file.tar.gz.gpg', etc.

OTOH, it's possible to have files using extra dotted
parts to signal certain properties to the user, which don't
really mean anything in terms of encoding, file format or
compression, e.g. 'file.i686.linux.64bit.bin'

Most systems I know that have to deal with file extensions,
come with a list of possible extensions and then register
a handler or property with each.

They typically use the 'longest match wins' strategy and then
use the match extension as file extension.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 20 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


From ziade.tarek at gmail.com  Tue Apr 20 17:48:01 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 20 Apr 2010 17:48:01 +0200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCDCBC3.2090605@egenix.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<4BCDCBC3.2090605@egenix.com>
Message-ID: <x2h94bdd2611004200848y4e8c8b81g8433089e4c88cb33@mail.gmail.com>

On Tue, Apr 20, 2010 at 5:44 PM, M.-A. Lemburg <mal at egenix.com> wrote:
[..]
>
> They typically use the 'longest match wins' strategy and then
> use the match extension as file extension.

A split from the first right dot is also fine with me:

>>> os.path.splitext('file.tar.gz', longest_match=True)
('file', '.tar.gz')

Tarek


From bruce at leapyear.org  Tue Apr 20 17:48:25 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Tue, 20 Apr 2010 08:48:25 -0700
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
Message-ID: <v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>

When would you know in advance you want 2 parts? Compare file.tar.gz to
backup.2010.04.20.tar. I'd think the usual case would be

split
if gz or zip or...:
  split again

--- Bruce
(via android)

On Apr 20, 2010 8:36 AM, "Tarek Ziad?" <ziade.tarek at gmail.com> wrote:

Hello

Currently, os.path.splitext will split a string giving you the piece
behind the last dot:

>>> os.path.splitext('file.tar.gz')
('file.tar', '.gz')

In some cases, what we really want is the two last parts when
splitting on the dots (like in my example).

What about providing an extra argument to be able to grab more than one dot
?

>>> os.path.splitext('file.tar.gz', numext=2)
('file', '.tar.gz')

If numext > numbers of dots, it will just split after the first dot:

>>> os.path.splitext('file.tar', numext=2)
('file', '.tar')


What do you think ?

Regards
Tarek






--
Tarek Ziad? | http://ziade.org
_______________________________________________
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/20100420/b590ad73/attachment.html>

From conrad.irwin at googlemail.com  Tue Apr 20 17:50:44 2010
From: conrad.irwin at googlemail.com (Conrad Irwin)
Date: Tue, 20 Apr 2010 16:50:44 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <x2h94bdd2611004200848y4e8c8b81g8433089e4c88cb33@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>	<4BCDCBC3.2090605@egenix.com>
	<x2h94bdd2611004200848y4e8c8b81g8433089e4c88cb33@mail.gmail.com>
Message-ID: <4BCDCD54.1080607@googlemail.com>


On 04/20/2010 04:48 PM, Tarek Ziad? wrote:
> On Tue, Apr 20, 2010 at 5:44 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> [..]
>>
>> They typically use the 'longest match wins' strategy and then
>> use the match extension as file extension.
> 
> A split from the first right dot is also fine with me:
> 
>>>> os.path.splitext('file.tar.gz', longest_match=True)
> ('file', '.tar.gz')

What you actually need is an function that implements the longest-match
scheme described before. Anything based on number of "."s (including the
current splitext) is broken and wrong.

Conrad


From ziade.tarek at gmail.com  Tue Apr 20 18:10:27 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 20 Apr 2010 18:10:27 +0200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
Message-ID: <y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>

On Tue, Apr 20, 2010 at 5:48 PM, Bruce Leban <bruce at leapyear.org> wrote:
> When would you know in advance you want 2 parts? Compare file.tar.gz to
> backup.2010.04.20.tar. I'd think the usual case would be
>
> split
> if gz or zip or...:
> ? split again

Right, that's from the user point of view, and that's why I was
thinking about numext in the first place,
to be able to do what you describe (a loop with a split position that moves)

my undertsanding now is that we would need to iterate from the
longest-match to the shortest-match,
until we find a pattern that works, so numext should be done from the
left to the right.

Or maybe simply drop that idea and just use path.endswith(extension)... :)

In that case the only subtle case is when the filename starts with '.',

So what about a new API :

   os.path.hasext(path, extensions)

That would return True if the path match on extension provided in the
extensions sequence
(using .endswith, but ignoring the first dot if the filename starts with a dot)

Tarek
-- 
Tarek Ziad? | http://ziade.org


From p.f.moore at gmail.com  Tue Apr 20 18:25:10 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Apr 2010 17:25:10 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
Message-ID: <n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>

On 20 April 2010 17:10, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> Or maybe simply drop that idea and just use path.endswith(extension)... :)
>
> In that case the only subtle case is when the filename starts with '.',
>
> So what about a new API :
>
> ? os.path.hasext(path, extensions)
>
> That would return True if the path match on extension provided in the
> extensions sequence
> (using .endswith, but ignoring the first dot if the filename starts with a dot)

That should take into account filesystem case sensitivity if it's to
meet user expectations. Which is a whole can of worms that you
probably don't want to open - certainly not for the standard library
without expecting a lot of work!

The current stdlib functions - all of which simply split up the
filename - avoid the problem, leaving it to the application to address
case sensitivity issues.

(Of course, if you want to start down this route, I'd suggest you
start with a function which, given a directory name, determines if
that directory's treats file names within it as case sensitive or not.
I'm not even sure if this is possible to implement in any sane way,
but it would be the key building block for any other path matching
code, such as your os.path.hasext proposal).

Paul.


From ziade.tarek at gmail.com  Tue Apr 20 18:47:50 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 20 Apr 2010 18:47:50 +0200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
Message-ID: <n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>

On Tue, Apr 20, 2010 at 6:25 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 20 April 2010 17:10, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> Or maybe simply drop that idea and just use path.endswith(extension)... :)
>>
>> In that case the only subtle case is when the filename starts with '.',
>>
>> So what about a new API :
>>
>> ? os.path.hasext(path, extensions)
>>
>> That would return True if the path match on extension provided in the
>> extensions sequence
>> (using .endswith, but ignoring the first dot if the filename starts with a dot)
>
> That should take into account filesystem case sensitivity if it's to
> meet user expectations. Which is a whole can of worms that you
> probably don't want to open - certainly not for the standard library
> without expecting a lot of work!
>
> The current stdlib functions - all of which simply split up the
> filename - avoid the problem, leaving it to the application to address
> case sensitivity issues.
>
> (Of course, if you want to start down this route, I'd suggest you
> start with a function which, given a directory name, determines if
> that directory's treats file names within it as case sensitive or not.
> I'm not even sure if this is possible to implement in any sane way,
> but it would be the key building block for any other path matching
> code, such as your os.path.hasext proposal).

I am not sure to follow the issue. Do you mean that in the same filesystem,
each directory can treat case sensivity differently ? I wasn't aware of that.

How would this affect the extension btw ?   I can imagine that
the path+extensions could to be normalized before the matching job, but
I don't see other issue, do you have an example ?


>
> Paul.
>



-- 
Tarek Ziad? | http://ziade.org


From fdrake at acm.org  Tue Apr 20 19:07:15 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 20 Apr 2010 13:07:15 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com> 
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com> 
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com> 
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com> 
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com> 
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com> 
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
Message-ID: <p2m9cee7ab81004201007q5a82f504r2974ce04f00cdac3@mail.gmail.com>

On Tue, Apr 20, 2010 at 12:47 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> I am not sure to follow the issue. Do you mean that in the same filesystem,
> each directory can treat case sensivity differently ? I wasn't aware of that.

I've never seen a filesystem that doesn't treat case-sensitivity
consistently, regardless of path.

But a single hierarchy composed of multiple filesystems may have
different behaviors in different directories, because they're mounted
from different filesystems.

> How would this affect the extension btw ? ? I can imagine that
> the path+extensions could to be normalized before the matching job, but
> I don't see other issue, do you have an example ?

I suspect a substantial part of the problem is really that Python
doesn't expose an API to normalize a path based on it's actual
location in the hierarchy; the operating system is used, but nothing
that deals with a path on a mounted filesystem that has non-default
behavior when compared to the traditional OS-centric expectations.

For a specific example, consider mounting a case-insensitive HFS
filesystem from Unix (well, most current Unixes): If the HFS is
mounted at /MyHfsMount (on an ext3 filesystem), and contains a
hierarchy /Folder/SomeFile.txt, the file would have an absolute path
of

    /MyHfsMount/Folder/SomeFile.txt

But the normalized path should be:

    /MyHfsMount/folder/somefile.txt

(Note that each path segment is normalized according to the filesystem
it's on, rather than the running OS.)


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller


From mwm-keyword-python.b4bdba at mired.org  Tue Apr 20 19:11:01 2010
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Tue, 20 Apr 2010 13:11:01 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
Message-ID: <20100420131101.75f0aca0@bhuda.mired.org>

On Tue, 20 Apr 2010 18:47:50 +0200
Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> > (Of course, if you want to start down this route, I'd suggest you
> > start with a function which, given a directory name, determines if
> > that directory's treats file names within it as case sensitive or not.
> > I'm not even sure if this is possible to implement in any sane way,
> > but it would be the key building block for any other path matching
> > code, such as your os.path.hasext proposal).
> 
> I am not sure to follow the issue. Do you mean that in the same filesystem,
> each directory can treat case sensivity differently ? I wasn't aware of that.

I don't think so. On the other hand, with modern file systems, if I
need a directory that is case-insensitive on a file system that's
case-sensitive, I'll just create a case-sensitive file system at that
point. Doesn't even require root privs these days.

> How would this affect the extension btw ?   I can imagine that
> the path+extensions could to be normalized before the matching job, but
> I don't see other issue, do you have an example ?

This gets back to user expectations - if foo.c and foo.C are different
files, then foo.c doesn't have a .C extension. If they aren't
different file, then it does. Which means you have to know whether
files are being treated in a case insensitive manner or not before you
can normalize the names.

    <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  Tue Apr 20 21:46:43 2010
From: brett at python.org (Brett Cannon)
Date: Tue, 20 Apr 2010 12:46:43 -0700
Subject: [Python-ideas] __decorate__ method
In-Reply-To: <w2hfb6fbf561004200713ma215338eq77604dbb3c7b9ea3@mail.gmail.com>
References: <m2o333edbe81004191937p967010fj8044ce86ea295992@mail.gmail.com> 
	<h2r79990c6b1004200035p804919f6n7143c58a27e49016@mail.gmail.com> 
	<w2hfb6fbf561004200713ma215338eq77604dbb3c7b9ea3@mail.gmail.com>
Message-ID: <v2ybbaeab101004201246h683bf4d4oe15106c6b8903633@mail.gmail.com>

On Tue, Apr 20, 2010 at 07:13, Jim Jewett <jimjjewett at gmail.com> wrote:

> On 20 April 2010 03:37, Zac Burns <zac256 at gmail.com> wrote:
>
> > Guido does say that __decorate__ should not replace __call__
>
> > (Sidenote: Can someone explain what the backward incompatibility is?)
>
> Note that this only means it shouldn't *replace* __call__.  Using
> __decorate__ if it exists and falling  back to __call__ would be
> acceptable from a backwards compatibility standpoint.  (It may be
> ruled out for ugliness or complication, but not for backwards
> compatibility.)


Jim's right on the backwards-compatibility point.

But I say YAGNI on this. If this Null class needs a no-op decorator either
introspect on the parameters to __call__ to do what is needed, use your own
custom decorate() function that take in the decorator to use and introspects
for Null, or something along those lines. There is no common class of
problem that __decorate__ would solve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100420/69f4faef/attachment.html>

From zac256 at gmail.com  Tue Apr 20 23:13:43 2010
From: zac256 at gmail.com (Zac Burns)
Date: Tue, 20 Apr 2010 14:13:43 -0700
Subject: [Python-ideas] Carol Newman
Message-ID: <m2r333edbe81004201413j3d1414e2x1d321df59940afc0@mail.gmail.com>

http://www.ristorantealpirata.com/home.php

-- 
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer
Zindagi Games


From p.f.moore at gmail.com  Tue Apr 20 23:42:33 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Apr 2010 22:42:33 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
Message-ID: <o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>

On 20 April 2010 17:47, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> I am not sure to follow the issue. Do you mean that in the same filesystem,
> each directory can treat case sensivity differently ? I wasn't aware of that.

Apologies, I was unclear (I was trying to avoid the term "filesystem"
which isn't an obvious concept on Windows). Putting it more simply,
you need to be able to determine the case sensitivity of the
filesystem to determine if a file "has extension .xxx".

> How would this affect the extension btw ? ? I can imagine that
> the path+extensions could to be normalized before the matching job, but
> I don't see other issue, do you have an example ?

As Mike Meyer explained, whether file foo.C "has extension .c" depends
(as far as the user is concerned) on whether the filesystem it's on is
case sensitive.

Many unix utility ports on Windows don't consider this, and they are
quite annoying when the problem hits you (which admittedly isn't that
often). Having an os.path.has_extension function in Python which
doesn't consider case sensitivity would be an attractive nuisance,
encouraging people to write subtly broken code like this. I'm -1 on
such a function.

Having said that, if you can write a function which detects filesystem
case sensitivity (and write a "correct" has_extension function based
on it), you'd be my hero (I believe it's a pretty difficult issue, if
not impossible in the general case).

Paul.


From ziade.tarek at gmail.com  Tue Apr 20 23:55:12 2010
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 20 Apr 2010 23:55:12 +0200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
Message-ID: <k2h94bdd2611004201455ya07b207bh491319046b736098@mail.gmail.com>

On Tue, Apr 20, 2010 at 11:42 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 20 April 2010 17:47, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> I am not sure to follow the issue. Do you mean that in the same filesystem,
>> each directory can treat case sensivity differently ? I wasn't aware of that.
>
> Apologies, I was unclear (I was trying to avoid the term "filesystem"
> which isn't an obvious concept on Windows). Putting it more simply,
> you need to be able to determine the case sensitivity of the
> filesystem to determine if a file "has extension .xxx".
>
>> How would this affect the extension btw ? ? I can imagine that
>> the path+extensions could to be normalized before the matching job, but
>> I don't see other issue, do you have an example ?
>
> As Mike Meyer explained, whether file foo.C "has extension .c" depends
> (as far as the user is concerned) on whether the filesystem it's on is
> case sensitive.
>
> Many unix utility ports on Windows don't consider this, and they are
> quite annoying when the problem hits you (which admittedly isn't that
> often). Having an os.path.has_extension function in Python which
> doesn't consider case sensitivity would be an attractive nuisance,
> encouraging people to write subtly broken code like this. I'm -1 on
> such a function.
>
> Having said that, if you can write a function which detects filesystem
> case sensitivity (and write a "correct" has_extension function based
> on it), you'd be my hero (I believe it's a pretty difficult issue, if
> not impossible in the general case).

Ok well, I doubt I'll be your hero, this is way over my head ;)

The only simple way that comes in my mind is to write a test file to
try it out but that's a hack

But being able to detect it sounds like something we should definitely
have in os/os.path.



>
> Paul.
>



-- 
Tarek Ziad? | http://ziade.org


From p.f.moore at gmail.com  Wed Apr 21 00:29:10 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 20 Apr 2010 23:29:10 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <k2h94bdd2611004201455ya07b207bh491319046b736098@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<k2h94bdd2611004201455ya07b207bh491319046b736098@mail.gmail.com>
Message-ID: <h2v79990c6b1004201529m21f14443m5dc4d6048c5f36ee@mail.gmail.com>

On 20 April 2010 22:55, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> Ok well, I doubt I'll be your hero, this is way over my head ;)

:-)

> The only simple way that comes in my mind is to write a test file to
> try it out but that's a hack
>
> But being able to detect it sounds like something we should definitely
> have in os/os.path.

Actually, I just dis a bit of digging - on Windows,
GetVolumeInformation, or GetVolumeInformationByHandleW looks like it'd
do the job.

Does anyone know how to find out if a filesystem is case sensitive on
Linux/MacOS/Unix...?

Paul.


From ckaynor at zindagigames.com  Wed Apr 21 00:36:24 2010
From: ckaynor at zindagigames.com (Chris Kaynor)
Date: Tue, 20 Apr 2010 15:36:24 -0700
Subject: [Python-ideas] [PyQt] Carol Newman
In-Reply-To: <m2m38ff15fe1004201506nd7c31191h9832387f4f4fd883@mail.gmail.com>
References: <m2r333edbe81004201413j3d1414e2x1d321df59940afc0@mail.gmail.com>
	<m2m38ff15fe1004201506nd7c31191h9832387f4f4fd883@mail.gmail.com>
Message-ID: <t2va03c8d051004201536j666e14cbn6ea148add4c9741f@mail.gmail.com>

There was a G-mail invasion earlier today that allowed e-mails to be sent
from any g-mail account without the owner's permission.

Chris


On Tue, Apr 20, 2010 at 3:06 PM, Nick Gaens <mail at nickgaens.com> wrote:

> Please someone remove this address from the lists, because of spamming..
>
>
> --
> Nick Gaens
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100420/ab647a30/attachment.html>

From zac256 at gmail.com  Wed Apr 21 00:53:20 2010
From: zac256 at gmail.com (Zac Burns)
Date: Tue, 20 Apr 2010 15:53:20 -0700
Subject: [Python-ideas] [PyQt] Carol Newman
In-Reply-To: <t2va03c8d051004201536j666e14cbn6ea148add4c9741f@mail.gmail.com>
References: <m2r333edbe81004201413j3d1414e2x1d321df59940afc0@mail.gmail.com>
	<m2m38ff15fe1004201506nd7c31191h9832387f4f4fd883@mail.gmail.com>
	<t2va03c8d051004201536j666e14cbn6ea148add4c9741f@mail.gmail.com>
Message-ID: <q2j333edbe81004201553zeda087dfk23cf8275cbd880b3@mail.gmail.com>

Yes, please do not remove me. Sorry for the inconvenience!
--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer
Zindagi Games


On Tue, Apr 20, 2010 at 3:36 PM, Chris Kaynor <ckaynor at zindagigames.com>wrote:

> There was a G-mail invasion earlier today that allowed e-mails to be sent
> from any g-mail account without the owner's permission.
>
> Chris
>
>
> On Tue, Apr 20, 2010 at 3:06 PM, Nick Gaens <mail at nickgaens.com> wrote:
>
>> Please someone remove this address from the lists, because of spamming..
>>
>>
>> --
>> Nick Gaens
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100420/e85e3dae/attachment.html>

From greg.ewing at canterbury.ac.nz  Wed Apr 21 02:18:41 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 21 Apr 2010 12:18:41 +1200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
Message-ID: <4BCE4461.8080902@canterbury.ac.nz>

Paul Moore wrote:

> As Mike Meyer explained, whether file foo.C "has extension .c" depends
> (as far as the user is concerned) on whether the filesystem it's on is
> case sensitive.

I don't think that's really true. It's common to find,
e.g., files ending with .jpg, .JPG, or other variations on
a case-sensitive filesystem that got there by being copied
from a case-insensitive one, or simply created by people
using tools that don't care about the case of the extension.

Seems to me the best thing to do is always compare extensions
case-insensitively unless you have a specific reason to do
otherwise. So I would recommend that any proposed hasextension()
function should be case-insensitive by default.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Wed Apr 21 02:19:56 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 21 Apr 2010 12:19:56 +1200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <k2h94bdd2611004201455ya07b207bh491319046b736098@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<k2h94bdd2611004201455ya07b207bh491319046b736098@mail.gmail.com>
Message-ID: <4BCE44AC.1030100@canterbury.ac.nz>

Tarek Ziad? wrote:

> The only simple way that comes in my mind is to write a test file to
> try it out but that's a hack

Not to mention failing if the user doesn't have write
permission on the file system.

-- 
Greg


From fdrake at acm.org  Wed Apr 21 02:27:23 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 20 Apr 2010 20:27:23 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCE4461.8080902@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com> 
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com> 
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com> 
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com> 
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com> 
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com> 
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com> 
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com> 
	<4BCE4461.8080902@canterbury.ac.nz>
Message-ID: <p2k9cee7ab81004201727gc305137fve3ce0ae8af3ad579@mail.gmail.com>

On Tue, Apr 20, 2010 at 8:18 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Seems to me the best thing to do is always compare extensions
> case-insensitively unless you have a specific reason to do
> otherwise. So I would recommend that any proposed hasextension()
> function should be case-insensitive by default.

I've certainly seen cases where the case was relevant in order to
determine how a file was handled.  There have been compilers that
interpreted .c as C and .C as C++.  (Not that better options weren't
available, but that was part of the default interpretation.)  This was
GCC, so... not particularly obscure.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller


From mwm-keyword-python.b4bdba at mired.org  Wed Apr 21 02:47:59 2010
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Tue, 20 Apr 2010 20:47:59 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCE4461.8080902@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
Message-ID: <20100420204759.777cb707@bhuda.mired.org>

On Wed, 21 Apr 2010 12:18:41 +1200
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> Paul Moore wrote:
> 
> > As Mike Meyer explained, whether file foo.C "has extension .c" depends
> > (as far as the user is concerned) on whether the filesystem it's on is
> > case sensitive.
> 
> I don't think that's really true. It's common to find,
> e.g., files ending with .jpg, .JPG, or other variations on
> a case-sensitive filesystem that got there by being copied
> from a case-insensitive one, or simply created by people
> using tools that don't care about the case of the extension.

That's probably true for the vast majority of extensions, but I chose
.C vs. .c for a reason - gcc thinks they are different:

bhuda% cmp bunny.c bunny.C
bhuda% file bunny.?
bunny.C: ASCII C program text
bunny.c: ASCII C program text
bhuda% gcc bunny.c
bhuda% g++ bunny.c
bunny.c: In function 'int main(int, char**)':
bunny.c:25: error: 'fork' was not declared in this scope
bunny.c:26: error: 'wait' was not declared in this scope
bhuda% gcc bunny.C
bunny.C: In function 'int main(int, char**)':
bunny.C:25: error: 'fork' was not declared in this scope
bunny.C:26: error: 'wait' was not declared in this scope
bhuda% 

> Seems to me the best thing to do is always compare extensions
> case-insensitively unless you have a specific reason to do
> otherwise. So I would recommend that any proposed hasextension()
> function should be case-insensitive by default.

Reasonable, but if you have a way to make it case-sensitive, you're
back where we started from: needing to figure out whether the files in
question care about case. Given the number of options here - including
that the file may not exist yet, and ditto for the file system it's
going to be on - possibly the solution is to leave off that option,
and document that this case has to be dealt with by the caller.


     <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 greg.ewing at canterbury.ac.nz  Wed Apr 21 03:33:30 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 21 Apr 2010 13:33:30 +1200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <20100420204759.777cb707@bhuda.mired.org>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
Message-ID: <4BCE55EA.6060902@canterbury.ac.nz>

On 21/04/10 12:47, Mike Meyer wrote:
> if you have a way to make it case-sensitive, you're
> back where we started from: needing to figure out whether the files in
> question care about case.

It's not whether the *files* care about case, it's
whether the *application* cares about case.

For example, an application that deals with image
files should probably recognise .jpg, .JPG, .Jpg, etc.
as all meaning the same thing.

An application that deals with source files, on
the other hand, will probably want to distinguish
between .c and .C.

So I think it's likely that in any particular case,
the caller of hasextension() will know whether he
wants case-sensitivity or not.

-- 
Greg



From p.f.moore at gmail.com  Wed Apr 21 09:48:45 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 21 Apr 2010 08:48:45 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCE55EA.6060902@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
Message-ID: <r2m79990c6b1004210048wdfb1f87fya5b3df9e37433336@mail.gmail.com>

On 21 April 2010 02:33, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> So I think it's likely that in any particular case,
> the caller of hasextension() will know whether he
> wants case-sensitivity or not.

True, but equally, the natural reaction for any but the most careful
of programmers would be to say something like hasextension(fn, '.txt')
without thinking. Hence my assertion that it's an attractive nuisance.
In practice, it's no worse than splitext(fn) == '.txt', but it gives
the impression that it should do a better job (even though, as you
say, it can't).

Once you get beyond the most basic operations, filename handling is
hard. (I haven't even touched on MacOS unicode normalisation issues
yet...) Getting it 90% right is easy (99% if you cover case
sensitivity) - it's that last 1% that bites. (And yes, the 90%/99%
split is, in my view, about accurate).

Paul.


From greg.ewing at canterbury.ac.nz  Wed Apr 21 12:10:38 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 21 Apr 2010 22:10:38 +1200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <r2m79990c6b1004210048wdfb1f87fya5b3df9e37433336@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<r2m79990c6b1004210048wdfb1f87fya5b3df9e37433336@mail.gmail.com>
Message-ID: <4BCECF1E.8060403@canterbury.ac.nz>

Paul Moore wrote:
> the natural reaction for any but the most careful
> of programmers would be to say something like hasextension(fn, '.txt')
> without thinking.

That's why I think that case-insensitivity should be the default.
Most of the time, people don't use case alone to distinguish between
different file types. It's only in rare situations such as .c vs
.C that the case matters, and in those situations, you know
that you're dealing with something special.

In any case, I don't believe it has anything to do with the
*filesystem* on which the file happens to reside. As long as
the filesystem is case-preserving, an application can regard
file extensions as being case-sensitive or not as it pleases.

-- 
Greg


From fdrake at acm.org  Wed Apr 21 12:58:51 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 21 Apr 2010 06:58:51 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCECF1E.8060403@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com> 
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com> 
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com> 
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com> 
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com> 
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org> 
	<4BCE55EA.6060902@canterbury.ac.nz>
	<r2m79990c6b1004210048wdfb1f87fya5b3df9e37433336@mail.gmail.com>
	<4BCECF1E.8060403@canterbury.ac.nz>
Message-ID: <l2h9cee7ab81004210358q7081f869gf36b537858d7d08b@mail.gmail.com>

On Wed, Apr 21, 2010 at 6:10 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> As long as the filesystem is case-preserving

But that's exactly the catch; you see things like .JPG and .GIF
primarily on files that are copied from case-insensitive filesystems,
and, less often, from software that hasn't been updated since those
were pervasive on the operating system(s) the software was intended
for (commonly written by programmers without experience with
case-preserving systems).

As such legacy fades (however slowly), should we *increase* the amount
of code that deals with it, or should we move on?

Keep in mind that with the advent of Python 3, we're putting a lot of
effort into shedding much more recent "legacy".


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller


From mwm-keyword-python.b4bdba at mired.org  Wed Apr 21 16:19:30 2010
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Wed, 21 Apr 2010 10:19:30 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCE55EA.6060902@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
Message-ID: <20100421101930.359ea195@bhuda.mired.org>

On Wed, 21 Apr 2010 13:33:30 +1200
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> On 21/04/10 12:47, Mike Meyer wrote:
> > if you have a way to make it case-sensitive, you're
> > back where we started from: needing to figure out whether the files in
> > question care about case.
> 
> It's not whether the *files* care about case, it's
> whether the *application* cares about case.

Actually, it's the file system. The *application* case is dealt with
by the option of doing a case-insensitive test. If you turn that off,
then you have to figure out whether or not the file system is case
insensitive to do it right.

> So I think it's likely that in any particular case,
> the caller of hasextension() will know whether he
> wants case-sensitivity or not.

Right. I'm talking about the case where the developer knows he wants
case sensitivity. In that case, you have to know whether or not the
file system is case sensitive to know whether or not "file.c" would
get opened if the application tried to open "file.C".

    <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 p.f.moore at gmail.com  Wed Apr 21 17:06:01 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 21 Apr 2010 16:06:01 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <l2h9cee7ab81004210358q7081f869gf36b537858d7d08b@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<r2m79990c6b1004210048wdfb1f87fya5b3df9e37433336@mail.gmail.com>
	<4BCECF1E.8060403@canterbury.ac.nz>
	<l2h9cee7ab81004210358q7081f869gf36b537858d7d08b@mail.gmail.com>
Message-ID: <h2r79990c6b1004210806jed922f51oa2d06eeb4bee21b0@mail.gmail.com>

On 21 April 2010 11:58, Fred Drake <fdrake at acm.org> wrote:
> As such legacy fades (however slowly), should we *increase* the amount
> of code that deals with it, or should we move on?

It's not clear to me that it's all "legacy". I had the impression that
MacOS used a case insensitive filesystem - is that right? Certainly, I
know that MacOS uses Unicode normalisation, so simple string
comparison is definitely not correct. (I only use MacOS as an example
to avoid the assumption that this is a Windows-only issue - there are
also case-insensitive filesystems available for Unix in general, if
nothing else SMBFS).

Certainly, non-case-preserving systems are a dying breed. But from
what I've read, the situation around case sensitivity is far less
clear - I've even seen comments from Unix users that claim they would
like Unix to move away from case sensitivity. (I'm not qualified to
judge the relevance or importance of such claims, I merely note that
they exist).

Like it or not, treating filenames as uninterpreted byte strings will
violate some users' expectations. Library support for dealing with
user expectations at a higher level would be good.

Unfortunately, from my reading, it seems like at least on Linux,
filesystem writers are expected to implement their own path handling
(at least, that's how I interpret the FUSE documentation, and I
couldn't find any lower level filesystem driver documentation that
implied otherwise). So, at the filesystem level, it seems that on
Linux all bets are off - I could, in theory, write a filesystem that
was case insensitive for consonants, but case sensitive for vowels.
And stored filenames in bit-reversed UTF-8. Bleh.

Paul.


From jimjjewett at gmail.com  Wed Apr 21 17:12:48 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 21 Apr 2010 11:12:48 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <20100421101930.359ea195@bhuda.mired.org>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com> 
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com> 
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com> 
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com> 
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com> 
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com> 
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org> 
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
Message-ID: <i2ufb6fbf561004210812o832fa77ch4ffadd06efb9b61b@mail.gmail.com>

On Wed, Apr 21, 2010 at 10:19 AM, Mike Meyer
<mwm-keyword-python.b4bdba at mired.org> wrote:

> Right. I'm talking about the case where the developer knows he wants
> case sensitivity.

And can therefore call a different library function, or pass an
optional flag argument.

> In that case, you have to know whether or not the
> file system is case sensitive to know whether or not "file.c" would
> get opened if the application tried to open "file.C".

uhm ... Why?

If it would, there really isn't any way to tell what the "real" name
is ... or do you just mean that it should cease to be case-sensitive
in exactly those cases where file.c is file.C, as a way of breaking
less than it otherwise would?

-jJ


From mwm-keyword-python.b4bdba at mired.org  Wed Apr 21 17:24:33 2010
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Wed, 21 Apr 2010 11:24:33 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <h2r79990c6b1004210806jed922f51oa2d06eeb4bee21b0@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<r2m79990c6b1004210048wdfb1f87fya5b3df9e37433336@mail.gmail.com>
	<4BCECF1E.8060403@canterbury.ac.nz>
	<l2h9cee7ab81004210358q7081f869gf36b537858d7d08b@mail.gmail.com>
	<h2r79990c6b1004210806jed922f51oa2d06eeb4bee21b0@mail.gmail.com>
Message-ID: <20100421112433.1ac2b0d6@bhuda.mired.org>

On Wed, 21 Apr 2010 16:06:01 +0100
Paul Moore <p.f.moore at gmail.com> wrote:

> On 21 April 2010 11:58, Fred Drake <fdrake at acm.org> wrote:
> > As such legacy fades (however slowly), should we *increase* the amount
> > of code that deals with it, or should we move on?
> 
> It's not clear to me that it's all "legacy". I had the impression that
> MacOS used a case insensitive filesystem - is that right?

Half right: MacOS has a couple of native file systems, and they can
all be either case-sensitive or case-insensitive. Most Mac
applications now work correctly on case-sensitive file systems, so you
can safely make all your Mac file systems case-sensitive, which wasn't
always the case. If you're using unix software - well, it's not all
case-insensitive friendly.

zfs file systems - used on Solaris and BSD, and available though
orphaned for MacOS - also consider case sensitivity optional.

> Certainly, I know that MacOS uses Unicode normalisation, so simple
> string comparison is definitely not correct. (I only use MacOS as an
> example to avoid the assumption that this is a Windows-only issue -
> there are also case-insensitive filesystems available for Unix in
> general, if nothing else SMBFS).

Unicode normalization is an option for zfs file systems.

    <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 rob.cliffe at btinternet.com  Wed Apr 21 18:17:55 2010
From: rob.cliffe at btinternet.com (Rob Cliffe)
Date: Wed, 21 Apr 2010 17:17:55 +0100
Subject: [Python-ideas] Small suggestion re help(Exception)
Message-ID: <AD78DD45CAB840508522A8CD7C491A10@robslaptop>

help() on an Exception class lists the method resolution order (effectively the inheritance hierarchy).
E.g. help(ArithmeticError) displays inter alia:

Method resolution order:
    ArithmeticError
    StandardError
    Exception
    BaseException
    __builtin__.object

Would it be possible for it also display the Python built-in SUBclasses of the class?  E.g. in the same example something like:

Built-in subclasses:
    FloatingPointError
    OverflowError
    ZeroDivisionError

This may seem pointless to grizzled old Python veterans who (maybe) know the inheritance hierarchy backwards, but for those of us with less experience I think it would be helpful, e.g.
(1) It would help to track down an Exception whose name you have forgotten.
(2) It would sometimes be illuminating, e.g. LookupError might be a bit obscure at first, until you see that it is the superclass of the familiar IndexError and KeyError.

Sorry, I'm not sure if I should send this sort of thing to Python-Ideas or Python-Dev, so please let me know gently which one I should (not) have sent it to.

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

From fuzzyman at voidspace.org.uk  Wed Apr 21 18:22:36 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 21 Apr 2010 18:22:36 +0200
Subject: [Python-ideas] [Python-Dev] Small suggestion re help(Exception)
In-Reply-To: <AD78DD45CAB840508522A8CD7C491A10@robslaptop>
References: <AD78DD45CAB840508522A8CD7C491A10@robslaptop>
Message-ID: <4BCF264C.90909@voidspace.org.uk>

On 21/04/2010 18:17, Rob Cliffe wrote:
> help() on an Exception class lists the method resolution order 
> (effectively the inheritance hierarchy).
> E.g. help(ArithmeticError) displays inter alia:
> Method resolution order:
>     ArithmeticError
>     StandardError
>     Exception
>     BaseException
>     __builtin__.object
> Would it be possible for it also display the Python built-in 
> SUBclasses of the class?  E.g. in the same example something like:
> Built-in subclasses:
>     FloatingPointError
>     OverflowError
>     ZeroDivisionError
> This may seem pointless to grizzled old Python veterans who (maybe) 
> know the inheritance hierarchy backwards, but for those of us with 
> less experience I think it would be helpful, e.g.
> (1) It would help to track down an Exception whose name you have 
> forgotten.
> (2) It would sometimes be illuminating, e.g. LookupError might be a 
> bit obscure at first, until you see that it is the superclass of the 
> familiar IndexError and KeyError.
> Sorry, I'm not sure if I should send this sort of thing to 
> Python-Ideas or Python-Dev, so please let me know gently which one I 
> should (not) have sent it to.

This sounds like a pretty straightforward feature request that you could 
put on the tracker (preferably with patch and tests of course), but is 
on-topic for this mailing list.

I rarely use help(...) myself (I probably should), but it sounds like a 
useful enhancement.

Michael

> Best wishes
> Rob Cliffe
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>    


-- 
http://www.ironpythoninaction.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100421/79ce1f9a/attachment.html>

From greg.ewing at canterbury.ac.nz  Thu Apr 22 01:09:53 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 22 Apr 2010 11:09:53 +1200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <20100421101930.359ea195@bhuda.mired.org>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
Message-ID: <4BCF85C1.9050004@canterbury.ac.nz>

Mike Meyer wrote:

> I'm talking about the case where the developer knows he wants
> case sensitivity. In that case, you have to know whether or not the
> file system is case sensitive to know whether or not "file.c" would
> get opened if the application tried to open "file.C".

What? I thought the use case we were talking about is
where you have a filename and you want to make a guess
about what kind of data it contains, based on the
extension.

I don't think I've ever wanted to find out whether a
file will get opened if I use the wrong case. I just
trust that the filename I'm given is suitable for
passing to open(), whatever case it might have. I
also can't think why you might be worried about that
just for the extension, and not the rest of the
pathname.

-- 
Greg



From p.f.moore at gmail.com  Thu Apr 22 09:26:17 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 22 Apr 2010 08:26:17 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCF85C1.9050004@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
	<4BCF85C1.9050004@canterbury.ac.nz>
Message-ID: <l2k79990c6b1004220026vf39e208fz7a1288c8c327f030@mail.gmail.com>

On 22 April 2010 00:09, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Mike Meyer wrote:
>
>> I'm talking about the case where the developer knows he wants
>> case sensitivity. In that case, you have to know whether or not the
>> file system is case sensitive to know whether or not "file.c" would
>> get opened if the application tried to open "file.C".
>
> What? I thought the use case we were talking about is
> where you have a filename and you want to make a guess
> about what kind of data it contains, based on the
> extension.

I believe that the use case being discussed goes as follows:

1. User supplies name FILE.C to the program
2. Program has different behaviours for .c and .C files
3. Program needs to decide whether to use the .c or .C behaviour

Option 1 is to use .C always on the basis that you believe that the
user should expect case sensitive behaviour.
Option 2 is to acknowledge that if the filesystem is case insensitive,
the user will expect the same behaviour for both .c and .C files
(assume .c is the "obvious" one) and do that.

Note that with option 2, the user isn't necessarily being perverse by
expecting .c behaviour. Maybe a legacy program created the file, using
the all-uppercase name, and the user didn't (want to, remember to)
change it. Maybe the user had caps lock on by accident, and doesn't
want to waste time correcting the whole line.

The point is that users using a case insensitive filesystem have a
reasonable expectation that that programs will ignore the case of
filenames (even in cases where they don't have to do so). Violating
that expectation is bad.

A second use case:

1. User has a directory containing a number of temporary files, all
with extension .tmp (but in varying case)
2. User has a "cleanup" program which deletes temporary files

The user will quite reasonably expect the cleanup program to delete
all files with extension .tmp, regardless of the case. Essentially, in
this simplified example, any behaviour that differs from DEL *.TMP
would be considered a bug.

Hope this clarifies things a bit.
Paul


From mwm-keyword-python.b4bdba at mired.org  Thu Apr 22 17:02:35 2010
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Thu, 22 Apr 2010 11:02:35 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BCF85C1.9050004@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
	<4BCF85C1.9050004@canterbury.ac.nz>
Message-ID: <20100422110235.4f409c0e@bhuda.mired.org>

On Thu, 22 Apr 2010 11:09:53 +1200
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> Mike Meyer wrote:
> 
> > I'm talking about the case where the developer knows he wants
> > case sensitivity. In that case, you have to know whether or not the
> > file system is case sensitive to know whether or not "file.c" would
> > get opened if the application tried to open "file.C".
> 
> What? I thought the use case we were talking about is
> where you have a filename and you want to make a guess
> about what kind of data it contains, based on the
> extension.

How are these different? If the user typed the filename "foo.c" and I
am trying to decide if it has the ".C" extension. If "foo.C" exists on
the disk and the user knows that "foo.c" and "foo.C" are the same
file, it's reasonable for the user to expect the application to figure
out that this file has the ".C" extension, even though they typed
".c". So whether or not the comparison should be case sensitive
depends on whether or not the file system is case sensitive.

Likewise, if we're *saving* the file, and the user expects us to
automatically add the right extension, then if the file system is case
sensitive, ".c" is the wrong extension. If the file system is case
insensitive, it's not clear to me what the user might expect.

       <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 greg.ewing at canterbury.ac.nz  Fri Apr 23 02:33:10 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 23 Apr 2010 12:33:10 +1200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <20100422110235.4f409c0e@bhuda.mired.org>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
	<4BCF85C1.9050004@canterbury.ac.nz>
	<20100422110235.4f409c0e@bhuda.mired.org>
Message-ID: <4BD0EAC6.4090402@canterbury.ac.nz>

Mike Meyer wrote:
> If the user typed the filename "foo.c" and I
> am trying to decide if it has the ".C" extension. If "foo.C" exists on
> the disk and the user knows that "foo.c" and "foo.C" are the same
> file, it's reasonable for the user to expect the application to figure
> out that this file has the ".C" extension, even though they typed
> ".c".

But you don't know whether the user is expecting this. If he
knows that gcc distinguishes between .c and .C, it may be that
he is expecting foo to be compiled as a C file rather than C++,
and he made a mistake when he named the file foo.C.

-- 
Greg



From mwm-keyword-python.b4bdba at mired.org  Fri Apr 23 02:26:56 2010
From: mwm-keyword-python.b4bdba at mired.org (Mike Meyer)
Date: Thu, 22 Apr 2010 20:26:56 -0400
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <4BD0EAC6.4090402@canterbury.ac.nz>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
	<4BCF85C1.9050004@canterbury.ac.nz>
	<20100422110235.4f409c0e@bhuda.mired.org>
	<4BD0EAC6.4090402@canterbury.ac.nz>
Message-ID: <20100422202656.7bc05d1e@bhuda.mired.org>

On Fri, 23 Apr 2010 12:33:10 +1200
Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> Mike Meyer wrote:
> > If the user typed the filename "foo.c" and I
> > am trying to decide if it has the ".C" extension. If "foo.C" exists on
> > the disk and the user knows that "foo.c" and "foo.C" are the same
> > file, it's reasonable for the user to expect the application to figure
> > out that this file has the ".C" extension, even though they typed
> > ".c".
> But you don't know whether the user is expecting this. If he
> knows that gcc distinguishes between .c and .C, it may be that
> he is expecting foo to be compiled as a C file rather than C++,
> and he made a mistake when he named the file foo.C.

Given that the argument for making the test case-insensitive to start
with was that the user expects .JPG and .jpg to be the same, I think
you just shot down the case for making the test case-insensitive as
well.

      <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 greg.ewing at canterbury.ac.nz  Fri Apr 23 02:53:16 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 23 Apr 2010 12:53:16 +1200
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <20100422202656.7bc05d1e@bhuda.mired.org>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<x2pcf5b87741004200843wa284e6fcp254552ec8276dc86@mail.gmail.com>
	<j2kcf5b87741004200844l87fa4f10odb34d5b7ba6764a4@mail.gmail.com>
	<v2qcf5b87741004200848g9cf796e4p446e69b629b9f7b6@mail.gmail.com>
	<y2s94bdd2611004200910q8b1ee8a4m769d1280294e2f3b@mail.gmail.com>
	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>
	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>
	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>
	<4BCE4461.8080902@canterbury.ac.nz>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
	<4BCF85C1.9050004@canterbury.ac.nz>
	<20100422110235.4f409c0e@bhuda.mired.org>
	<4BD0EAC6.4090402@canterbury.ac.nz>
	<20100422202656.7bc05d1e@bhuda.mired.org>
Message-ID: <4BD0EF7C.3090800@canterbury.ac.nz>

Mike Meyer wrote:

> Given that the argument for making the test case-insensitive to start
> with was that the user expects .JPG and .jpg to be the same, I think
> you just shot down the case for making the test case-insensitive as
> well.

I only said it should be case-sensitive as a *default*.
The .c/.C thing is a special case, which the application
can deal with by explicitly requesting a case-sensitive
comparison. Most of the time you'll be dealing with
things like .jpg/.JPG, where I don't think any harm could
be caused by treating the extensions case-insensitively
always.

I still don't think you can decide based on the file
system behaviour. What if the user creates his files on
a case-insensitive system and then copies them to a
case-sensitive one or vice versa? The intended meaning
of the extensions doesn't suddenly change when that
happens.

-- 
Greg


From p.f.moore at gmail.com  Fri Apr 23 09:50:16 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 23 Apr 2010 08:50:16 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <w2w79990c6b1004230049p8cae7cb2h44b0d5728773ae72@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<20100420204759.777cb707@bhuda.mired.org>
	<4BCE55EA.6060902@canterbury.ac.nz>
	<20100421101930.359ea195@bhuda.mired.org>
	<4BCF85C1.9050004@canterbury.ac.nz>
	<20100422110235.4f409c0e@bhuda.mired.org>
	<4BD0EAC6.4090402@canterbury.ac.nz>
	<20100422202656.7bc05d1e@bhuda.mired.org>
	<4BD0EF7C.3090800@canterbury.ac.nz>
	<w2w79990c6b1004230049p8cae7cb2h44b0d5728773ae72@mail.gmail.com>
Message-ID: <i2x79990c6b1004230050t3a0452ffr921cee4c6d7dfeb6@mail.gmail.com>

Sorry, should have gone to the list.

On 23 April 2010 01:53, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> I still don't think you can decide based on the file
> system behaviour. What if the user creates his files on
> a case-insensitive system and then copies them to a
> case-sensitive one or vice versa? The intended meaning
> of the extensions doesn't suddenly change when that
> happens.

I don't know if you actually use case insensitive filenames regularly
(an odd question that, in "normal life" I'd immediately assume 99.99%
of people I meet use Windows, but on this list, I tend to assume most
people use Unix/Linux or Mac - sorry if my assumption's mistaken) but
personally, as a Windows user, I try to keep filename case the way I
want it, but I'd tend to double check if moving files to a case
sensitive system. But - and this is the key point here for me - the
filenames I *type* at the command line often don't match the case on
the filesystem (because I'm too lazy to hit the shift key when I know
it doesn't matter, for example) and so my expectations very much are
based on filesystem case sensitivity, and what's more, it's what I
type that's unreliable.

As far as I am concerned, any behaviour that relies on filenames
differing only in case being handled differently is wrong on Windows.
(Yes, that includes gcc's behaviour). All programs should work case
insensitively in all cases when dealing with files. Simple.

That's my view as a Windows user. I rationalise it as being based on
the case sensitivity of the filesystem, but I'll admit I have no
experience with using case sensitive filesystems on Windows (for all
practical purposes, they don't exist). I also have limited experience
with Unix, and all my Unix experience is in situations where all the
filesystems are case sensitive. So arguably, my position is Unix ==
case sensitive, Windows = case insensitive, and a simple switch on
sys.platform would work for me. But desktop Linux systems need to deal
with such things as FAT32-formatted USB disks, Samba filesystems, etc.
And I have no good intuition on how they should be handled. So I fall
back on my original rationalisation, that the filesystem behaviour is
what matters.

So to summarise:
?* Case sensitivity behaviour determined by host OS would work for me
?* But it "feels" wrong
?* Case sensitive everywhere is completely wrong (as it ignores
Windows users' expectations)
?* Choosing a default based on filesystem behaviour is logical, but
hard, and there may be no real requirement for it

Also, making the user choose every time (for example, GNU find with
its -name and -iname options) is not a helpful or portable approach
(e.g., I want find . -name *.sql to find all SQL scripts, regardless
of platform).

Cross-platform tools with a strong focus on file and filename
semantics (for example, DVCSs such as Mercurial) have specialist
needs, and probably should always write custom code. But for "quick"
scripts, something in the standard library which made doing the
"right" thing easy would be a huge help.

Paul


From lie.1296 at gmail.com  Fri Apr 23 13:24:16 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Fri, 23 Apr 2010 21:24:16 +1000
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <20100421112433.1ac2b0d6@bhuda.mired.org>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>	<n2p79990c6b1004200925g3870a80coa8275b4860c8b446@mail.gmail.com>	<n2x94bdd2611004200947rbc97e621s4fa752499db2e34a@mail.gmail.com>	<o2t79990c6b1004201442m29f7c8f1sfd792baa6456b831@mail.gmail.com>	<4BCE4461.8080902@canterbury.ac.nz>	<20100420204759.777cb707@bhuda.mired.org>	<4BCE55EA.6060902@canterbury.ac.nz>	<r2m79990c6b1004210048wdfb1f87fya5b3df9e37433336@mail.gmail.com>	<4BCECF1E.8060403@canterbury.ac.nz>	<l2h9cee7ab81004210358q7081f869gf36b537858d7d08b@mail.gmail.com>	<h2r79990c6b1004210806jed922f51oa2d06eeb4bee21b0@mail.gmail.com>
	<20100421112433.1ac2b0d6@bhuda.mired.org>
Message-ID: <hqs03s$e6u$1@dough.gmane.org>

On 04/22/10 01:24, Mike Meyer wrote:
> On Wed, 21 Apr 2010 16:06:01 +0100
> Paul Moore <p.f.moore at gmail.com> wrote:
> 
>> On 21 April 2010 11:58, Fred Drake <fdrake at acm.org> wrote:
>>> As such legacy fades (however slowly), should we *increase* the amount
>>> of code that deals with it, or should we move on?
>>
>> It's not clear to me that it's all "legacy". I had the impression that
>> MacOS used a case insensitive filesystem - is that right?
> 
> Half right: MacOS has a couple of native file systems, and they can
> all be either case-sensitive or case-insensitive. Most Mac
> applications now work correctly on case-sensitive file systems, so you
> can safely make all your Mac file systems case-sensitive, which wasn't
> always the case. If you're using unix software - well, it's not all
> case-insensitive friendly.

how about:

def hasextension(filename, ext, smartness=0):
    # when smartness = 0 filename is treated as uninterpreted bytestring
    # when smartness = 10, filename will be:
    # - unicode normalization
    # - case normalization
    # - accent normalization
    # - synonym normalization
    # - language normalization (have filename in French?)
    # - mistyping normalization
    # - extension normalization ('.jpg' matches '.jpg' and '.jpeg')
    # - wrapper normalization (.tgz is normalized to .tar.gz)
    # - filetype normalization (.mpg matches .mov, .avi, .ogg, etc)

    ... magic code follows ...

:-)



From lie.1296 at gmail.com  Fri Apr 23 13:34:10 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Fri, 23 Apr 2010 21:34:10 +1000
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <i2x79990c6b1004230050t3a0452ffr921cee4c6d7dfeb6@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>	<20100420204759.777cb707@bhuda.mired.org>	<4BCE55EA.6060902@canterbury.ac.nz>	<20100421101930.359ea195@bhuda.mired.org>	<4BCF85C1.9050004@canterbury.ac.nz>	<20100422110235.4f409c0e@bhuda.mired.org>	<4BD0EAC6.4090402@canterbury.ac.nz>	<20100422202656.7bc05d1e@bhuda.mired.org>	<4BD0EF7C.3090800@canterbury.ac.nz>	<w2w79990c6b1004230049p8cae7cb2h44b0d5728773ae72@mail.gmail.com>
	<i2x79990c6b1004230050t3a0452ffr921cee4c6d7dfeb6@mail.gmail.com>
Message-ID: <hqs0mi$gc3$1@dough.gmane.org>

On 04/23/10 17:50, Paul Moore wrote:
> As far as I am concerned, any behaviour that relies on filenames
> differing only in case being handled differently is wrong on Windows.
> (Yes, that includes gcc's behaviour). All programs should work case
> insensitively in all cases when dealing with files. Simple.

Have any of you convinced each other? Otherwise perhaps it's time to
consider "In the face of ambiguity, refuse the temptation to guess."



From p.f.moore at gmail.com  Fri Apr 23 13:49:22 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 23 Apr 2010 12:49:22 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <hqs0mi$gc3$1@dough.gmane.org>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<20100421101930.359ea195@bhuda.mired.org>
	<4BCF85C1.9050004@canterbury.ac.nz>
	<20100422110235.4f409c0e@bhuda.mired.org>
	<4BD0EAC6.4090402@canterbury.ac.nz>
	<20100422202656.7bc05d1e@bhuda.mired.org>
	<4BD0EF7C.3090800@canterbury.ac.nz>
	<w2w79990c6b1004230049p8cae7cb2h44b0d5728773ae72@mail.gmail.com>
	<i2x79990c6b1004230050t3a0452ffr921cee4c6d7dfeb6@mail.gmail.com>
	<hqs0mi$gc3$1@dough.gmane.org>
Message-ID: <j2q79990c6b1004230449v64b63190o41871b01851b51df@mail.gmail.com>

On 23 April 2010 12:34, Lie Ryan <lie.1296 at gmail.com> wrote:
> On 04/23/10 17:50, Paul Moore wrote:
>> As far as I am concerned, any behaviour that relies on filenames
>> differing only in case being handled differently is wrong on Windows.
>> (Yes, that includes gcc's behaviour). All programs should work case
>> insensitively in all cases when dealing with files. Simple.
>
> Have any of you convinced each other? Otherwise perhaps it's time to
> consider "In the face of ambiguity, refuse the temptation to guess."

:-)

Good point. Which I guess boils down to saying that if there's no
consensus, then nothing should be added to the stdlib (which is a
conclusion I'm happy with).

Paul.


From bruce at leapyear.org  Fri Apr 23 16:21:06 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Fri, 23 Apr 2010 07:21:06 -0700
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <m2tcf5b87741004230720tdf8ed58anb0cac0b710b86acc@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<i2x79990c6b1004230050t3a0452ffr921cee4c6d7dfeb6@mail.gmail.com>
	<hqs0mi$gc3$1@dough.gmane.org>
	<j2q79990c6b1004230449v64b63190o41871b01851b51df@mail.gmail.com>
	<l2rcf5b87741004230636la0db908dx545d44e0c2e8b751@mail.gmail.com>
	<k2tcf5b87741004230647sf6fd3a01g18cbbd52c546d23f@mail.gmail.com>
	<u2lcf5b87741004230703p7a8a4a78z7145852494bc7d80@mail.gmail.com>
	<g2qcf5b87741004230706hdbae3d78vaa4493d78e5635b9@mail.gmail.com>
	<z2scf5b87741004230709s6c302b26q2dbf287e38a6dcb1@mail.gmail.com>
	<m2tcf5b87741004230720tdf8ed58anb0cac0b710b86acc@mail.gmail.com>
Message-ID: <h2wcf5b87741004230721v8922ad23p5a5123251c11c82e@mail.gmail.com>

Also note that there are really THREE variations:

Case sensitive (Unix/mac normally)
Case preserving (windows normally)
Case insensitive (some legacy fs)

IMHO gcc treating .c and .C is annoying. I usually get .JPG instead of .jpg
when windows apps pick the extension for me. Also annoying.

Notwithstanding that you can't do case insensitive compare without knowing
the file system locale otherwise .GIF != .gif. So this is a mess.

Furthermore it's not just extensions. Some names are conventionally case
sensitive. And if I write #include "foo.h" and have foo.h and FOO.h you
better get the right one. If I'm filtering unsafe filetypes are .EXE and .PL
unsafe?

Probably most useful is to provide access to fs locale and case sensitivety
mode and leave rest for now.

--- Bruce
(via android)

On Apr 23, 2010 4:49 AM, "Paul Moore" <p.f.moore at gmail.com> wrote:

On 23 April 2010 12:34, Lie Ryan <lie.1296 at gmail.com> wrote:
> On 04/23/10 17:50, Paul Moore wrote:
...
:-)

Good point. Which I guess boils down to saying that if there's no
consensus, then nothing should be added to the stdlib (which is a
conclusion I'm happy with).

Paul.

_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
ht...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100423/c25050f3/attachment.html>

From p.f.moore at gmail.com  Fri Apr 23 17:43:37 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 23 Apr 2010 16:43:37 +0100
Subject: [Python-ideas] Small enhancement to os.path.splitext
In-Reply-To: <h2wcf5b87741004230721v8922ad23p5a5123251c11c82e@mail.gmail.com>
References: <r2k94bdd2611004200835nda0ffd3dz2aa37e0b48ad496e@mail.gmail.com>
	<hqs0mi$gc3$1@dough.gmane.org>
	<j2q79990c6b1004230449v64b63190o41871b01851b51df@mail.gmail.com>
	<l2rcf5b87741004230636la0db908dx545d44e0c2e8b751@mail.gmail.com>
	<k2tcf5b87741004230647sf6fd3a01g18cbbd52c546d23f@mail.gmail.com>
	<u2lcf5b87741004230703p7a8a4a78z7145852494bc7d80@mail.gmail.com>
	<g2qcf5b87741004230706hdbae3d78vaa4493d78e5635b9@mail.gmail.com>
	<z2scf5b87741004230709s6c302b26q2dbf287e38a6dcb1@mail.gmail.com>
	<m2tcf5b87741004230720tdf8ed58anb0cac0b710b86acc@mail.gmail.com>
	<h2wcf5b87741004230721v8922ad23p5a5123251c11c82e@mail.gmail.com>
Message-ID: <k2i79990c6b1004230843p2832ae87g7997bf3543f5b17@mail.gmail.com>

On 23 April 2010 15:21, Bruce Leban <bruce at leapyear.org> wrote:
> Probably most useful is to provide access to fs locale and case sensitivety
> mode and leave rest for now.

That was my original suggestion - unfortunately I only know how to do
this for Windows, and my research seems to indicate that it might not
even be possible on Linux.

If someone can give me some pointers on how to check case sensitivity
for a filesystem on Linux/Unix/POSIX and MacOS, I'm willing to try to
create a suitable patch for the stdlib. I don't consider writing a
file then reading it back as a way of doing this, as there may be
permission issues, and it'll trigger filesystem notification hooks,
etc, so it's not really suitable as a stdlib solution (although
obviously it's a fine solution for an application to use if the
application design makes it appropriate...)

Paul.


From anfedorov at gmail.com  Fri Apr 23 22:47:34 2010
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Fri, 23 Apr 2010 16:47:34 -0400
Subject: [Python-ideas] Anaphoric if
Message-ID: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>

I imagine this has been covered before, but somehow my Google-foo is
failing. What are people's opinions about having an anaphoric-if syntax
sugar like:

if foo() as x:
    ... x


meaning

x = foo()
if x:
    ... x


?

I do this a lot, and it seems very un-Pythonically verbose to repeat "x"
(especially when a longer variable name is appropriate).

Cheers,
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100423/7007a810/attachment.html>

From benjamin at python.org  Fri Apr 23 22:56:32 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 23 Apr 2010 20:56:32 +0000 (UTC)
Subject: [Python-ideas] Anaphoric if
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
Message-ID: <loom.20100423T225605-767@post.gmane.org>

Andrey Fedorov <anfedorov at ...> writes:

> 
> 
> I imagine this has been covered before

It's been rejected many times.






From pyideas at rebertia.com  Sat Apr 24 01:18:19 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Fri, 23 Apr 2010 16:18:19 -0700
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
Message-ID: <y2t50697b2c1004231618rae363201q6c92498fc761987@mail.gmail.com>

On Fri, Apr 23, 2010 at 1:47 PM, Andrey Fedorov <anfedorov at gmail.com> wrote:
> I imagine this has been covered before, but somehow my Google-foo is
> failing. What are people's opinions about having an anaphoric-if syntax
> sugar like:
>
> if foo() as x:
> ?? ?... x
>
> meaning
>
> x = foo()
> if x:
> ?? ?... x

Master Yoda had me google "python-ideas if assignment", which was fruitful:

[Python-ideas] Inline assignment expression:
http://mail.python.org/pipermail/python-ideas/2009-March/003423.html

Post in same thread summarizing rejection reasons:
http://mail.python.org/pipermail/python-ideas/2009-March/003440.html

Cheers,
Chris
--
The moratorium makes this pointless anyways.
http://blog.rebertia.com


From bruce at leapyear.org  Sat Apr 24 01:53:18 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Fri, 23 Apr 2010 16:53:18 -0700
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <m2qcf5b87741004231644vb5a10c3du4b3d0fd80dd2d9e5@mail.gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
	<y2t50697b2c1004231618rae363201q6c92498fc761987@mail.gmail.com>
	<z2gcf5b87741004231634i60b0f0fbo988a64de26b19942@mail.gmail.com>
	<m2qcf5b87741004231644vb5a10c3du4b3d0fd80dd2d9e5@mail.gmail.com>
Message-ID: <u2zcf5b87741004231653i4cbb61a3m1b0deb99e32cd4df@mail.gmail.com>

def anaphor(x):
  return (x,) if x else ()

for foo in anaphor(bar):
   ...

--- Bruce
(via android)

On Apr 23, 2010 4:18 PM, "Chris Rebert" <pyideas at rebertia.com> wrote:

On Fri, Apr 23, 2010 at 1:47 PM, Andrey Fedorov <anfedorov at gmail.com> wrote:
> I imagine this has be...
Master Yoda had me google "python-ideas if assignment", which was fruitful:

[Python-ideas] Inline assignment expression:
http://mail.python.org/pipermail/python-ideas/2009-March/003423.html

Post in same thread summarizing rejection reasons:
http://mail.python.org/pipermail/python-ideas/2009-March/003440.html

Cheers,
Chris
--
The moratorium makes this pointless anyways.
http://blog.rebertia.com

_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
ht...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100423/12edabb2/attachment.html>

From jess.austin at gmail.com  Sat Apr 24 02:23:50 2010
From: jess.austin at gmail.com (Jess Austin)
Date: Fri, 23 Apr 2010 19:23:50 -0500
Subject: [Python-ideas] Anaphoric if
Message-ID: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com>

On Fri, Apr 23, 2010 at 3:47 PM,  Andrey Fedorov <anfedorov at gmail.com> wrote:
> I imagine this has been covered before, but somehow my Google-foo is
> failing. What are people's opinions about having an anaphoric-if syntax
> sugar like:
>
> if foo() as x:
> ? ?... x
>
>
> meaning
>
> x = foo()
> if x:
> ? ?... x
>

I like this, and I'd like for it to be in python, although I don't
think it will be widely supported because it only saves one line, and
the idiom it replaces isn't very common. [Which facts didn't prevent
the adoption of '@' decorator syntax, but I digress...]  A question
for the sake of completeness: would the following:

if not foo() as x:
    ... x

mean this:

x = foo()
if not x:
    ... x


cheers,
Jess


From raymond.hettinger at gmail.com  Sat Apr 24 02:26:45 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 23 Apr 2010 17:26:45 -0700
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
Message-ID: <899AD1BB-C3C8-49C6-9B0F-8E4307EA455D@gmail.com>


On Apr 23, 2010, at 1:47 PM, Andrey Fedorov wrote:

> I imagine this has been covered before, but somehow my Google-foo is failing. What are people's opinions about having an anaphoric-if syntax sugar like:
> 
> if foo() as x:
>     ... x
> 
> meaning
> 
> x = foo()
> if x:
>     ... x
> 
> ?
> 
> I do this a lot, and it seems very un-Pythonically verbose to repeat "x" (especially when a longer variable name is appropriate).

Yes, this has come up before.
FWIW, I'm +1 on the idea,
especially if it can be also applied to while-loops.
It looks very readable

We do have a language moratorium in effect,
so your odds of success are slim.


Raymond

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100423/1e81baa3/attachment.html>

From anfedorov at gmail.com  Sat Apr 24 02:39:52 2010
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Fri, 23 Apr 2010 20:39:52 -0400
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <y2t50697b2c1004231618rae363201q6c92498fc761987@mail.gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com> 
	<y2t50697b2c1004231618rae363201q6c92498fc761987@mail.gmail.com>
Message-ID: <p2x7659cab31004231739g352ae47apbbc14ad283b2e9f5@mail.gmail.com>

On Fri, Apr 23, 2010 at 7:18 PM, Chris Rebert <pyideas at rebertia.com> wrote:

> Master Yoda had me google "python-ideas if assignment", which was fruitful:
>
> [Python-ideas] Inline assignment expression:
> http://mail.python.org/pipermail/python-ideas/2009-March/003423.html
>
> Post in same thread summarizing rejection reasons:
> http://mail.python.org/pipermail/python-ideas/2009-March/003440.html
>

Thanks! But, I'm not really thinking about creating an inline assignment
expressions: those feel un-Pythonic the same way the ++ operator is.

I'm talking about anaphoric if: that is, extending the if_stmt to include
["as" target] after its expression. Actually, that seems to be what the
original bug filed was about [1], *not* anything to do with assignment
expressions or funky "backwards assignment" syntax who-knows-where.

On Mar 15, 2009, Nick Coghlan wrote:

> If you look at the current uses for 'as' it is never for direct assignment:


Right, it's used for a different kind of assignment each time. The
commonality is that it's used for the "appropriate" assignment for the
context, with the target appearing after "as".

On Fri, Apr 23, 2010 at 8:23 PM, Jess Austin <jess.austin at gmail.com> wrote:

> A question for the sake of completeness: would "if not foo() as x: ... x"
> mean "x = foo(); if not x: ... x"?
>

No, it would mean: "x = not foo(); if x: ...x". That is, it would be part of
the "if" statement, assigning the value of the expression after "if" to the
target after "as". It doesn't make sense to me to make exceptions for one
kind of expression over another.

On Fri, Apr 23, 2010 at 8:26 PM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:

> FWIW, I'm +1 on the idea, especially if it can be also applied to
> while-loops.
>

Yup, using doing the same for while-loops makes even more sense.

It looks very readable
>

Agreed.


> We do have a language moratorium in effect, so your odds of success are
> slim.
>

Patiently counting down the days... :)

Cheers,
Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100423/ac6b4def/attachment.html>

From ncoghlan at gmail.com  Sat Apr 24 10:00:53 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 24 Apr 2010 18:00:53 +1000
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <899AD1BB-C3C8-49C6-9B0F-8E4307EA455D@gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
	<899AD1BB-C3C8-49C6-9B0F-8E4307EA455D@gmail.com>
Message-ID: <4BD2A535.80207@gmail.com>

Raymond Hettinger wrote:
> Yes, this has come up before.
> FWIW, I'm +1 on the idea,
> especially if it can be also applied to while-loops.
> It looks very readable

Agreed, of the sundry embedded assignment proposals that come up
semi-regularly, adding "as" clauses to if and while statements is the
most viable (although possibly still not a good idea).

Any such proposal would be best promoted by mining existing code (such
as the standard library) for examples that are improved by the new
syntax. The while loop case is actually probably stronger, since it can
avoid code repetition in calculating and saving the loop condition once
before the start of the loop, and then recalculating it again at the end
of the loop.

Note that both decorators and the with statement were successful in
large part due to the way that they brought visually distant code (after
a function definition, after a try block) up to a more semantically
appropriate location (before the function definition line, replacing the
opening line of the try block).

Any discussion of an "as" clause for while statements should at least
mention PEP 315 (adding a "do" block to while loops), as that has a
similar motivation for avoiding code duplication.

> We do have a language moratorium in effect,
> so your odds of success are slim.

Yes, even if a good proposal is put together for this, it won't be
seriously considered until the moratorium is over (which is still years
away).

Cheers,
Nick.

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


From rrr at ronadam.com  Sat Apr 24 19:13:51 2010
From: rrr at ronadam.com (Ron Adam)
Date: Sat, 24 Apr 2010 12:13:51 -0500
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com>
References: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com>
Message-ID: <4BD326CF.2070101@ronadam.com>



On 04/23/2010 07:23 PM, Jess Austin wrote:

 > for the sake of completeness: would the following:
 >
 > if not foo() as x:
 >      ... x
 >
 > mean this:
 >
 > x = foo()
 > if not x:
 >      ... x


I would think it would defined as

      if expression as name:
          block using name

Which would be...

     x = not foo()
     if x:
         ... x

So it could be tricky to get the correct behavior unless (expression as 
name) becomes a valid expression in it self, but then it wouldn't be 
limited to the if block, so you might as well just use (expression = name).

Another issue would be, what if x already existed? would it just write over 
it, or raise a NameError. If it wrote over it, would it be restored after 
the block to it's previous value?  All of this adds unneeded complexity to 
the language without adding any real benefits.  Yes it reduces the line 
count by one, but what meaningful use case is enabled with this that we 
can't already do?

Ron




From anfedorov at gmail.com  Sat Apr 24 20:05:03 2010
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Sat, 24 Apr 2010 14:05:03 -0400
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <4BD326CF.2070101@ronadam.com>
References: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com> 
	<4BD326CF.2070101@ronadam.com>
Message-ID: <t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>

On Sat, Apr 24, 2010 at 1:13 PM, Ron Adam <rrr at ronadam.com> wrote:

>  On 04/23/2010 07:23 PM, Jess Austin wrote:
>
> > for the sake of completeness: would the following:
> >
> > if not foo() as x:
> >      ... x
> >
> > mean this:
> >
> > x = foo()
> > if not x:
> >      ... x
>
>
> I would think it would defined as
>
>     if expression as name:
>         block using name
>
> Which would be...
>
>    x = not foo()
>    if x:
>        ... x
>
> So it could be tricky to get the correct behavior unless (expression as
> name) becomes a valid expression in it self, but then it wouldn't be limited
> to the if block, so you might as well just use (expression = name).
>

Err, that is *not* "correct behavior". This is the third time I'm repeating
myself (not including the subject): I'm talking about an *anaphoric if*.
That is an if statement which can refer back to its predicate, nothing
more.

Another issue would be, what if x already existed? would it just write over
> it, or raise a NameError. If it wrote over it, would it be restored after
> the block to it's previous value? All of this adds unneeded complexity to
> the language without adding any real benefits.


No extra complexity: make it identical to the expanded version. That also
makes it identical to how the "local" variable in [x for x in ...] behaves,
which is expected.

Yes it reduces the line count by one, but what meaningful use case is
> enabled with this that we can't already do?


The benefit isn't the line, it's the aesthetic of a direct transcription of
your intentions:

x = foo()

should be reserved for x having meaning in the local scope. Think of it this
way: is it more natural to say "if you have kids, register them for swimming
lessons", or "consider your kids. if there are any kids, register them for
swimming lessons".

- Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100424/c76e6017/attachment.html>

From brett at python.org  Sat Apr 24 20:34:06 2010
From: brett at python.org (Brett Cannon)
Date: Sat, 24 Apr 2010 11:34:06 -0700
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>
References: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com> 
	<4BD326CF.2070101@ronadam.com>
	<t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>
Message-ID: <u2tbbaeab101004241134g7ce28810z4fddc0fcbcebc1ff@mail.gmail.com>

On Sat, Apr 24, 2010 at 11:05, Andrey Fedorov <anfedorov at gmail.com> wrote:

> On Sat, Apr 24, 2010 at 1:13 PM, Ron Adam <rrr at ronadam.com> wrote:
>
>>  On 04/23/2010 07:23 PM, Jess Austin wrote:
>>
>> > for the sake of completeness: would the following:
>> >
>> > if not foo() as x:
>> >      ... x
>> >
>> > mean this:
>> >
>> > x = foo()
>> > if not x:
>> >      ... x
>>
>>
>> I would think it would defined as
>>
>>     if expression as name:
>>         block using name
>>
>> Which would be...
>>
>>    x = not foo()
>>    if x:
>>        ... x
>>
>> So it could be tricky to get the correct behavior unless (expression as
>> name) becomes a valid expression in it self, but then it wouldn't be limited
>> to the if block, so you might as well just use (expression = name).
>>
>
> Err, that is *not* "correct behavior". This is the third time I'm repeating
> myself (not including the subject): I'm talking about an *anaphoric if*.
> That is an if statement which can refer back to its predicate, nothing
> more.
>
>
Well, I suspect I am not alone with having never heard of the term
"anaphoric if" (and Google backs me up; this very thread is now search
result #4 for [anaphoric if]). It seems to come from the Lisp world and is
literally nothing more than syntactic sugar for inlining the assignment
statement of what is being tested by an 'if' statement. So no fancy
restrictive scoping of the variable; this would be dead-simple syntactic
sugar.

Unless I am wrong in which case poor Andrey will have to repeat himself a
fifth time. =)

But back to the ``if not foo() as x`` example, that does water down this
syntax for me. I would suspect that the places where this occurs I would
want what foo() returned to be assigned to x instead of ``not foo()`` as the
latter is guaranteed to be a boolean and not some false object that I might
want to populate with stuff to make true.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100424/100aff61/attachment.html>

From janssen at parc.com  Sat Apr 24 21:58:43 2010
From: janssen at parc.com (Bill Janssen)
Date: Sat, 24 Apr 2010 12:58:43 PDT
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <p2x7659cab31004231739g352ae47apbbc14ad283b2e9f5@mail.gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com>
	<y2t50697b2c1004231618rae363201q6c92498fc761987@mail.gmail.com>
	<p2x7659cab31004231739g352ae47apbbc14ad283b2e9f5@mail.gmail.com>
Message-ID: <82239.1272139123@parc.com>

Andrey Fedorov <anfedorov at gmail.com> wrote:

> On Fri, Apr 23, 2010 at 8:26 PM, Raymond Hettinger <
> raymond.hettinger at gmail.com> wrote:
> > We do have a language moratorium in effect, so your odds of success are
> > slim.
> >
> 
> Patiently counting down the days... :)

You might try adding it to Boo first, which has the same Pythonic syntax
and doesn't seem to have a language moratorium in effect.

Bill


From guido at python.org  Sun Apr 25 00:48:54 2010
From: guido at python.org (Guido van Rossum)
Date: Sat, 24 Apr 2010 15:48:54 -0700
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <4BD2A535.80207@gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com> 
	<899AD1BB-C3C8-49C6-9B0F-8E4307EA455D@gmail.com>
	<4BD2A535.80207@gmail.com>
Message-ID: <k2mca471dc21004241548ke444dfe6o4d1c7c4296807651@mail.gmail.com>

On Sat, Apr 24, 2010 at 1:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Raymond Hettinger wrote:
>> Yes, this has come up before.
>> FWIW, I'm +1 on the idea,
>> especially if it can be also applied to while-loops.
>> It looks very readable
>
> Agreed, of the sundry embedded assignment proposals that come up
> semi-regularly, adding "as" clauses to if and while statements is the
> most viable (although possibly still not a good idea).

It is not a good idea. In particular it is a mistake to assume that
endowing if- and while-statements with special syntax is going to
solve anything -- the problem is more generally that *expressions*
can't have such effects (in Python) and there's nothing particularly
special about the top-level expression in an if-statement. It would be
just as likely to have a use case that required (using C syntax)
things like

  if ((p = foo() == NULL) || (q = p->next) != HEAD && q-> next != TAIL) ...

Also note that local variable assignment is super-fast so that there
is no need to worry about the speed of things like

  x = foo()
  if x:

compared to the hypothetical

  if foo() as x:

I expect Unladen Swallow would optimize the former anyway.

-- 
--Guido van Rossum (python.org/~guido)


From anfedorov at gmail.com  Sun Apr 25 01:01:06 2010
From: anfedorov at gmail.com (Andrey Fedorov)
Date: Sat, 24 Apr 2010 19:01:06 -0400
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <k2mca471dc21004241548ke444dfe6o4d1c7c4296807651@mail.gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com> 
	<899AD1BB-C3C8-49C6-9B0F-8E4307EA455D@gmail.com>
	<4BD2A535.80207@gmail.com> 
	<k2mca471dc21004241548ke444dfe6o4d1c7c4296807651@mail.gmail.com>
Message-ID: <q2g7659cab31004241601r381412behe971eb05fd16cc26@mail.gmail.com>

On Sat, Apr 24, 2010 at 6:48 PM, Guido van Rossum <guido at python.org> wrote:

> On Sat, Apr 24, 2010 at 1:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Raymond Hettinger wrote:
> >> Yes, this has come up before.
> >> FWIW, I'm +1 on the idea,
> >> especially if it can be also applied to while-loops.
> >> It looks very readable
> >
> > Agreed, of the sundry embedded assignment proposals that come up
> > semi-regularly, adding "as" clauses to if and while statements is the
> > most viable (although possibly still not a good idea).
>
> It is not a good idea. In particular it is a mistake to assume that
> endowing if- and while-statements with special syntax is going to
> solve anything -- the problem is more generally that *expressions*
> can't have such effects (in Python) and there's nothing particularly
> special about the top-level expression in an if-statement.


What about endowing if/while statements with syntax to assign names to their
entire predicates only?

- Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100424/663922f7/attachment.html>

From guido at python.org  Sun Apr 25 01:24:18 2010
From: guido at python.org (Guido van Rossum)
Date: Sat, 24 Apr 2010 16:24:18 -0700
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <q2g7659cab31004241601r381412behe971eb05fd16cc26@mail.gmail.com>
References: <w2q7659cab31004231347k7df12153qff7058be8ad871bb@mail.gmail.com> 
	<899AD1BB-C3C8-49C6-9B0F-8E4307EA455D@gmail.com>
	<4BD2A535.80207@gmail.com> 
	<k2mca471dc21004241548ke444dfe6o4d1c7c4296807651@mail.gmail.com> 
	<q2g7659cab31004241601r381412behe971eb05fd16cc26@mail.gmail.com>
Message-ID: <o2tca471dc21004241624ne7c1486egb6c590f73d3ddf1c@mail.gmail.com>

On Sat, Apr 24, 2010 at 4:01 PM, Andrey Fedorov <anfedorov at gmail.com> wrote:
>
>
> On Sat, Apr 24, 2010 at 6:48 PM, Guido van Rossum <guido at python.org> wrote:
>>
>> On Sat, Apr 24, 2010 at 1:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> > Raymond Hettinger wrote:
>> >> Yes, this has come up before.
>> >> FWIW, I'm +1 on the idea,
>> >> especially if it can be also applied to while-loops.
>> >> It looks very readable
>> >
>> > Agreed, of the sundry embedded assignment proposals that come up
>> > semi-regularly, adding "as" clauses to if and while statements is the
>> > most viable (although possibly still not a good idea).
>>
>> It is not a good idea. In particular it is a mistake to assume that
>> endowing if- and while-statements with special syntax is going to
>> solve anything -- the problem is more generally that *expressions*
>> can't have such effects (in Python) and there's nothing particularly
>> special about the top-level expression in an if-statement.
>
> What about endowing if/while statements with syntax to assign names to their
> entire predicates only?
> - Andrey

Well my point is that it doesn't solve enough problems to make an exception.

See the zen of Python: "Special cases aren't special enough to break
the rules." Plus the problem it solves is not very important anyway
(so the clever response of looking at the next line in the zen doesn't
apply :-).

-- 
--Guido van Rossum (python.org/~guido)


From john.a.graham at gmail.com  Sun Apr 25 02:33:51 2010
From: john.a.graham at gmail.com (John Graham)
Date: Sat, 24 Apr 2010 19:33:51 -0500
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>
References: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com>
	<4BD326CF.2070101@ronadam.com>
	<t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>
Message-ID: <y2me92d6e1f1004241733gc788f357m4c19588ce45e85d2@mail.gmail.com>

not to go too far off on an unrelated tangent here but couldn't your
use case be covered by polymorphism on the return value of foo, one
potential return value representing the if x case while another value
representing the branch if none case. this would be similar to the
'maybe' monad in haskell, 'optional' in the ml languages, or the 'null
object' pattern in OO.  completely representable in python without any
addition to the syntax.

On 4/24/10, Andrey Fedorov <anfedorov at gmail.com> wrote:
> On Sat, Apr 24, 2010 at 1:13 PM, Ron Adam <rrr at ronadam.com> wrote:
>
>>  On 04/23/2010 07:23 PM, Jess Austin wrote:
>>
>> > for the sake of completeness: would the following:
>> >
>> > if not foo() as x:
>> >      ... x
>> >
>> > mean this:
>> >
>> > x = foo()
>> > if not x:
>> >      ... x
>>
>>
>> I would think it would defined as
>>
>>     if expression as name:
>>         block using name
>>
>> Which would be...
>>
>>    x = not foo()
>>    if x:
>>        ... x
>>
>> So it could be tricky to get the correct behavior unless (expression as
>> name) becomes a valid expression in it self, but then it wouldn't be
>> limited
>> to the if block, so you might as well just use (expression = name).
>>
>
> Err, that is *not* "correct behavior". This is the third time I'm repeating
> myself (not including the subject): I'm talking about an *anaphoric if*.
> That is an if statement which can refer back to its predicate, nothing
> more.
>
> Another issue would be, what if x already existed? would it just write over
>> it, or raise a NameError. If it wrote over it, would it be restored after
>> the block to it's previous value? All of this adds unneeded complexity to
>> the language without adding any real benefits.
>
>
> No extra complexity: make it identical to the expanded version. That also
> makes it identical to how the "local" variable in [x for x in ...] behaves,
> which is expected.
>
> Yes it reduces the line count by one, but what meaningful use case is
>> enabled with this that we can't already do?
>
>
> The benefit isn't the line, it's the aesthetic of a direct transcription of
> your intentions:
>
> x = foo()
>
> should be reserved for x having meaning in the local scope. Think of it this
> way: is it more natural to say "if you have kids, register them for swimming
> lessons", or "consider your kids. if there are any kids, register them for
> swimming lessons".
>
> - Andrey
>


From raymond.hettinger at gmail.com  Sun Apr 25 07:17:51 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 24 Apr 2010 22:17:51 -0700
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <u2tbbaeab101004241134g7ce28810z4fddc0fcbcebc1ff@mail.gmail.com>
References: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com>
	<4BD326CF.2070101@ronadam.com>
	<t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>
	<u2tbbaeab101004241134g7ce28810z4fddc0fcbcebc1ff@mail.gmail.com>
Message-ID: <E870F5D5-49A9-40E4-9679-5B5ABEF98D39@gmail.com>


On Apr 24, 2010, at 11:34 AM, Brett Cannon wrote:
> 
> Well, I suspect I am not alone with having never heard of the term "anaphoric if" (and Google backs me up; this very thread is now search result #4 for [anaphoric if]). It seems to come from the Lisp world and is literally nothing more than syntactic sugar for inlining the assignment statement of what is being tested by an 'if' statement. So no fancy restrictive scoping of the variable; this would be dead-simple syntactic sugar.

The term anaphoric reference seems to be from the field of linguistics.  Wikipedia gives this explanation:
"""
An anaphoric reference, when opposed to cataphora, refers to something within a text that has been previously identified. For example, in "Susan dropped the plate. It shattered loudly" the word "it" refers to the phrase "the plate".
""" 


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100424/6797804d/attachment.html>

From rrr at ronadam.com  Sun Apr 25 11:32:47 2010
From: rrr at ronadam.com (Ron Adam)
Date: Sun, 25 Apr 2010 04:32:47 -0500
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>
References: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com>
	<4BD326CF.2070101@ronadam.com>
	<t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>
Message-ID: <4BD40C3F.5020707@ronadam.com>



On 04/24/2010 01:05 PM, Andrey Fedorov wrote:
> On Sat, Apr 24, 2010 at 1:13 PM, Ron Adam <rrr at ronadam.com
> <mailto:rrr at ronadam.com>> wrote:
>
>     On 04/23/2010 07:23 PM, Jess Austin wrote:
>
>      > for the sake of completeness: would the following:
>      >
>      > if not foo() as x:
>      >      ... x
>      >
>      > mean this:
>      >
>      > x = foo()
>      > if not x:
>      >      ... x
>
>
>     I would think it would defined as
>
>          if expression as name:
>              block using name
>
>     Which would be...
>
>         x = not foo()
>         if x:
>             ... x
>
>     So it could be tricky to get the correct behavior unless (expression
>     as name) becomes a valid expression in it self, but then it wouldn't
>     be limited to the if block, so you might as well just use
>     (expression = name).

That should have been (name = expression).


> Err, that is *not* "correct behavior".

What I mean by correct behavior is what the programmer wants... or the 
intended behavior determined by what a programmer needs.


> This is the third time
> I'm repeating myself (not including the subject): I'm talking about an
> *anaphoric if*. That is an if statement which can refer back to its
> predicate, nothing more.

And we are asking you to be more specific about certain details which may 
be clear to you, but not so clear to us.  So rather than repeat yourself, 
try to give good python code examples that clarifies what will happen in 
specific situations as the posters here come up with them.  These details 
need to be worked out very precisely before any idea can be seriously 
considered.  It's nothing personal, it's just how things work here in 
python idea land.


>     Another issue would be, what if x already existed? would it just
>     write over it, or raise a NameError. If it wrote over it, would it
>     be restored after the block to it's previous value? All of this adds
>     unneeded complexity to the language without adding any real benefits.
>
>
> No extra complexity: make it identical to the expanded version. That
> also makes it identical to how the "local" variable in [x for x in ...]
> behaves, which is expected.

I'm  still not sure what you are expecting...

Python 2.6.5:
>>> x = 10
>>> [x for x in range(5)]
[0, 1, 2, 3, 4]
>>> x
4

Python 3.1.2
>>> x = 10
>>> [x for x in range(5)]
[0, 1, 2, 3, 4]
>>> x
10

The behavior of the local variable (x in this case) has been changed so it 
works the same as generator expressions.



>     Yes it reduces the line count by one, but what meaningful use case
>     is enabled with this that we can't already do?
>
>
> The benefit isn't the line, it's the aesthetic of a direct transcription
> of your intentions:
>
> x = foo()
>
> should be reserved for x having meaning in the local scope. Think of it
> this way: is it more natural to say "if you have kids, register them for
> swimming lessons", or "consider your kids. if there are any kids,
> register them for swimming lessons".

The exact order of my (or your) words isn't important to me as long as the 
intended meaning can be understood.

What is more natural has more to do with what I'm use to.  In this case the 
current way python does it is the more natural way for me to do it because 
that is what I'm use to.

Ron



From scott+python-ideas at scottdial.com  Mon Apr 26 14:09:15 2010
From: scott+python-ideas at scottdial.com (Scott Dial)
Date: Mon, 26 Apr 2010 08:09:15 -0400
Subject: [Python-ideas] Anaphoric if
In-Reply-To: <E870F5D5-49A9-40E4-9679-5B5ABEF98D39@gmail.com>
References: <u2ub8ad139e1004231723xbabca22re944490438cccd4e@mail.gmail.com>	<4BD326CF.2070101@ronadam.com>	<t2w7659cab31004241105n8678a1cdu4e8bb17cfe2bb7de@mail.gmail.com>	<u2tbbaeab101004241134g7ce28810z4fddc0fcbcebc1ff@mail.gmail.com>
	<E870F5D5-49A9-40E4-9679-5B5ABEF98D39@gmail.com>
Message-ID: <4BD5826B.8050001@scottdial.com>

On 4/25/2010 1:17 AM, Raymond Hettinger wrote:
> The term anaphoric reference seems to be from the field of linguistics.
>  Wikipedia gives this explanation:
> """
> An anaphoric reference, when opposed to cataphora, refers to something
> within a text that has been previously identified. For example, in
> /"Susan dropped the plate. It shattered loudly"/ the word /"it"/ refers
> to the phrase /"the plate"/.
> """ 

And one should take the lesson from linguistics that such constructs are
often confusing and ambiguous (e.g., "The dog ate the bird and it
died.") This is related to the problem with "if not foo() as x" and
moreover "if not foo() and bar() as x:". This doesn't appear to be an
obvious win of clarity over "x = not foo() and bar(); if x:" Let's not
inherit the bad grammar of natural languages into programming languages.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu


From cool-rr at cool-rr.com  Mon Apr 26 23:10:41 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 26 Apr 2010 23:10:41 +0200
Subject: [Python-ideas] Reversable
Message-ID: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>

Just something small that I thought of, and I haven't thought about this
deeply at all, so maybe this is way wrong. But: What about adding a
`Reversable` next to all the `Iterable` and `Container` and stuff?

(Please `cc` any replies to me, I'm not getting mail from this list.)

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100426/e3be7ab4/attachment.html>

From cool-rr at cool-rr.com  Mon Apr 26 23:12:02 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 26 Apr 2010 23:12:02 +0200
Subject: [Python-ideas] Why no sign function?
Message-ID: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>

This was probably discussed a lot. Why is there no simple `sign` function in
Python, like in the math module or something? I mean one that tells you the
sign of a number.

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100426/4e80bb9c/attachment.html>

From contact at xavierho.com  Mon Apr 26 23:13:20 2010
From: contact at xavierho.com (Xavier Ho)
Date: Tue, 27 Apr 2010 07:13:20 +1000
Subject: [Python-ideas] Reversable
In-Reply-To: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
Message-ID: <n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>

On Tue, Apr 27, 2010 at 7:10 AM, cool-RR <cool-rr at cool-rr.com> wrote:

> Just something small that I thought of, and I haven't thought about this
> deeply at all, so maybe this is way wrong. But: What about adding a
> `Reversable` next to all the `Iterable` and `Container` and stuff?
>

You mean there is something Iterable we can't reverse by doing [::-1] or
calling reversed() ? This idea feels a bit too general to be useful. Any
rationales?

Cheers,
Xav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100427/a73721d0/attachment.html>

From contact at xavierho.com  Mon Apr 26 23:16:50 2010
From: contact at xavierho.com (Xavier Ho)
Date: Tue, 27 Apr 2010 07:16:50 +1000
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
Message-ID: <h2r2d56febf1004261416k16bc024chc6593a00db02161a@mail.gmail.com>

On Tue, Apr 27, 2010 at 7:12 AM, cool-RR <cool-rr at cool-rr.com> wrote:

> This was probably discussed a lot. Why is there no simple `sign` function
> in Python, like in the math module or something? I mean one that tells you
> the sign of a number.
>
>
I really hate to shot you down man. First of all, how are you returning the
sign? True/False for positive or negative? What about zero? Is zero a
positive or a negative number?

Secondly, when you get the output, how are you using it? Comparison -- ah
wait, there is always if x > 0 ...

I think you need to carefully think about these ideas before proposing them.
I feel you're wasting your own time, here.

Cheers,
Xav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100427/3dd391c0/attachment.html>

From cool-rr at cool-rr.com  Mon Apr 26 23:18:26 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 26 Apr 2010 23:18:26 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
Message-ID: <t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>

On Mon, Apr 26, 2010 at 11:13 PM, Xavier Ho <contact at xavierho.com> wrote:

> On Tue, Apr 27, 2010 at 7:10 AM, cool-RR <cool-rr at cool-rr.com> wrote:
>
>> Just something small that I thought of, and I haven't thought about this
>> deeply at all, so maybe this is way wrong. But: What about adding a
>> `Reversable` next to all the `Iterable` and `Container` and stuff?
>>
>
> You mean there is something Iterable we can't reverse by doing [::-1] or
> calling reversed() ? This idea feels a bit too general to be useful. Any
> rationales?
>
> Cheers,
> Xav
>

As far as I know, iterables are generally not reversable. Try defining a
simple iterator, like a class with just an `__iter__` function, and run
`reversed` on it. You get `TypeError: argument to reversed() must be a
sequence`. (Which by the way is a bad error message.)

Am I missing something?

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100426/958ff8a2/attachment.html>

From cool-rr at cool-rr.com  Mon Apr 26 23:21:39 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 26 Apr 2010 23:21:39 +0200
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <h2r2d56febf1004261416k16bc024chc6593a00db02161a@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
	<h2r2d56febf1004261416k16bc024chc6593a00db02161a@mail.gmail.com>
Message-ID: <r2wa422b72d1004261421ga3056a7cwb3283337b59e7cc2@mail.gmail.com>

On Mon, Apr 26, 2010 at 11:16 PM, Xavier Ho <contact at xavierho.com> wrote:

> On Tue, Apr 27, 2010 at 7:12 AM, cool-RR <cool-rr at cool-rr.com> wrote:
>
>> This was probably discussed a lot. Why is there no simple `sign` function
>> in Python, like in the math module or something? I mean one that tells you
>> the sign of a number.
>>
>>
> I really hate to shot you down man. First of all, how are you returning the
> sign? True/False for positive or negative? What about zero? Is zero a
> positive or a negative number?
>
> Secondly, when you get the output, how are you using it? Comparison -- ah
> wait, there is always if x > 0 ...
>
> I think you need to carefully think about these ideas before proposing
> them. I feel you're wasting your own time, here.
>
> Cheers,
> Xav
>

Hey Xavier,

I don't feel I'm wasting my time. If you feel I'm wasting yours you are free
to ignore my messages.

I return 1 for positive, 0 for zero, -1 for negative. Yes, I know I can
improvise something like it, by using `x > 0` or `cmp(x, 0)`, but I like
code that reads like what it does.

Ram.


-- 
Sincerely,
Ram Rachum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100426/d3c49a85/attachment.html>

From robert.kern at gmail.com  Mon Apr 26 23:32:41 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 26 Apr 2010 16:32:41 -0500
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <r2wa422b72d1004261421ga3056a7cwb3283337b59e7cc2@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>	<h2r2d56febf1004261416k16bc024chc6593a00db02161a@mail.gmail.com>
	<r2wa422b72d1004261421ga3056a7cwb3283337b59e7cc2@mail.gmail.com>
Message-ID: <hr50pq$d38$1@dough.gmane.org>

On 4/26/10 4:21 PM, cool-RR wrote:

> I return 1 for positive, 0 for zero, -1 for negative. Yes, I know I can
> improvise something like it, by using `x > 0` or `cmp(x, 0)`, but I like
> code that reads like what it does.

That is what small utility functions are for.

Basically, there are number of different conventions a sign() function could 
choose. In floating point, there are signed zeros and NaNs. Similarly, there is 
no sign() function in the standard C math library, which the math module tries 
to wrap thinly. Since there is an important ambiguity, the standard libraries 
leave it to you to write your own small utility function which implements the 
convention you desire.

-- 
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 george.sakkis at gmail.com  Mon Apr 26 23:34:11 2010
From: george.sakkis at gmail.com (George Sakkis)
Date: Mon, 26 Apr 2010 23:34:11 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
Message-ID: <k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>

On Mon, Apr 26, 2010 at 11:18 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> On Mon, Apr 26, 2010 at 11:13 PM, Xavier Ho <contact at xavierho.com> wrote:
>>
>> On Tue, Apr 27, 2010 at 7:10 AM, cool-RR <cool-rr at cool-rr.com> wrote:
>>>
>>> Just something small that I thought of, and I haven't thought about this
>>> deeply at all, so maybe this is way wrong. But: What about adding a
>>> `Reversable` next to all the `Iterable` and `Container` and stuff?
>>
>> You mean there is something Iterable we can't reverse by doing [::-1] or
>> calling reversed() ? This idea feels a bit too general to be useful. Any
>> rationales?
>>
>> Cheers,
>> Xav
>
> As far as I know, iterables are generally not reversable. Try defining a
> simple iterator, like a class with just an `__iter__` function, and run
> `reversed` on it. You get `TypeError: argument to reversed() must be a
> sequence`. (Which by the way is a bad error message.)
> Am I missing something?

So what should reversed() (or a new Reversable()) return for, say,
itertools.count() ?

By the way, comp.lang.python [1] or the tutor mailing list [2] are
more appropriate than python-ideas for asking
questions "you haven't thought about deeply at all".

George

[1] http://mail.python.org/mailman/listinfo/python-list
[2] http://mail.python.org/mailman/listinfo/tutor


From rhamph at gmail.com  Mon Apr 26 23:34:50 2010
From: rhamph at gmail.com (Adam Olsen)
Date: Mon, 26 Apr 2010 15:34:50 -0600
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
Message-ID: <y2haac2c7cb1004261434t6f1984efv23ffbdb3f196fbac@mail.gmail.com>

On Mon, Apr 26, 2010 at 15:12, cool-RR <cool-rr at cool-rr.com> wrote:
> This was probably discussed a lot. Why is there no simple `sign` function in
> Python, like in the math module or something? I mean one that tells you the
> sign of a number.

There is one.  Python 2.6 added math.copysign().  However, it's
intended to deal with float peculiarities such as negative 0, so it's
a little obtuse.  Most code, such as that using integers, should just
use "if x > 0:".


From dickinsm at gmail.com  Mon Apr 26 23:36:14 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 26 Apr 2010 22:36:14 +0100
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
Message-ID: <m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>

On Mon, Apr 26, 2010 at 10:12 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> This was probably discussed a lot. Why is there no simple `sign` function in
> Python, like in the math module or something? I mean one that tells you the
> sign of a number.

What are your use-cases?  Can you give some examples of how you'd
expect to use it?

Given math.copysign and direct comparisons like "if x > 0", I don't
think I've ever wanted a sign function.

If a sign function were implemented, I'd probably want something like
IEEE 754's signbit function, returning 1 for negative values and -0.0,
and 0 for positive values and 0.0.  Ideally, something giving a
boolean result:  hasSignBit.  (Insert better name here.)

Mark


From cool-rr at cool-rr.com  Mon Apr 26 23:41:24 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Mon, 26 Apr 2010 23:41:24 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
Message-ID: <o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>

On Mon, Apr 26, 2010 at 11:34 PM, George Sakkis <george.sakkis at gmail.com>wrote:

> On Mon, Apr 26, 2010 at 11:18 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> > On Mon, Apr 26, 2010 at 11:13 PM, Xavier Ho <contact at xavierho.com>
> wrote:
> >>
> >> On Tue, Apr 27, 2010 at 7:10 AM, cool-RR <cool-rr at cool-rr.com> wrote:
> >>>
> >>> Just something small that I thought of, and I haven't thought about
> this
> >>> deeply at all, so maybe this is way wrong. But: What about adding a
> >>> `Reversable` next to all the `Iterable` and `Container` and stuff?
> >>
> >> You mean there is something Iterable we can't reverse by doing [::-1] or
> >> calling reversed() ? This idea feels a bit too general to be useful. Any
> >> rationales?
> >>
> >> Cheers,
> >> Xav
> >
> > As far as I know, iterables are generally not reversable. Try defining a
> > simple iterator, like a class with just an `__iter__` function, and run
> > `reversed` on it. You get `TypeError: argument to reversed() must be a
> > sequence`. (Which by the way is a bad error message.)
> > Am I missing something?
>
> So what should reversed() (or a new Reversable()) return for, say,
> itertools.count() ?
>
> By the way, comp.lang.python [1] or the tutor mailing list [2] are
> more appropriate than python-ideas for asking
> questions "you haven't thought about deeply at all".
>
> George
>
> [1] http://mail.python.org/mailman/listinfo/python-list
> [2] http://mail.python.org/mailman/listinfo/tutor
>

I'm not really understanding you, George. Am I getting something very wrong
here? When you put `itertools.count()` into `reversed()`, you get an error,
like you should, because it's not a sequence and it doesn't define
`__reversed__`. So it's not a reversable object. I'm proposing to have a
`Reversable` similar to `Iterable`, which checks the existence of
`__reversed__` instead of `__iter__`.

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100426/b977028d/attachment.html>

From cool-rr at cool-rr.com  Mon Apr 26 23:43:46 2010
From: cool-rr at cool-rr.com (Ram Rachum)
Date: Mon, 26 Apr 2010 21:43:46 +0000 (UTC)
Subject: [Python-ideas] Why no sign function?
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>	<h2r2d56febf1004261416k16bc024chc6593a00db02161a@mail.gmail.com>
	<r2wa422b72d1004261421ga3056a7cwb3283337b59e7cc2@mail.gmail.com>
	<hr50pq$d38$1@dough.gmane.org>
Message-ID: <loom.20100426T234150-603@post.gmane.org>

Robert Kern <robert.kern at ...> writes:

| That is what small utility functions are for.
| 
| Basically, there are number of different conventions a sign() function could 
| choose. In floating point, there are signed zeros and NaNs. Similarly, there
| no sign() function in the standard C math library, which the math module tries 
| to wrap thinly. Since there is an important ambiguity, the standard libraries 
| leave it to you to write your own small utility function which implements the 
| convention you desire.


That makes sense, now that you phrase it like that. Thanks Robert.

Ram.



From dickinsm at gmail.com  Mon Apr 26 23:44:43 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 26 Apr 2010 22:44:43 +0100
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
	<m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>
Message-ID: <p2i5c6f2a5d1004261444gc870e96fia7f774115f693bbf@mail.gmail.com>

On Mon, Apr 26, 2010 at 10:36 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
> If a sign function were implemented, I'd probably want something like
> IEEE 754's signbit function

Correction:  it's C99 that has a signbit function.  IEEE 754-2008
specifies an 'isSignMinus' function with exactly the same semantics:
values with the sign bit set (including -0.0, -inf, and NaNs whose
sign bit is set) return True;  other values return False.

I wouldn't object to a `math.is_signed` function or a
`float.is_signed` method with these semantics.  It's not clear where
is the better place:  we have `math.isnan` and `math.isinf`, but
`float.is_integer`.

Mark


From python at mrabarnett.plus.com  Tue Apr 27 00:09:40 2010
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 26 Apr 2010 23:09:40 +0100
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
	<m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>
Message-ID: <4BD60F24.2070601@mrabarnett.plus.com>

Mark Dickinson wrote:
> On Mon, Apr 26, 2010 at 10:12 PM, cool-RR <cool-rr at cool-rr.com> wrote:
>> This was probably discussed a lot. Why is there no simple `sign` function in
>> Python, like in the math module or something? I mean one that tells you the
>> sign of a number.
> 
> What are your use-cases?  Can you give some examples of how you'd
> expect to use it?
> 
> Given math.copysign and direct comparisons like "if x > 0", I don't
> think I've ever wanted a sign function.
> 
> If a sign function were implemented, I'd probably want something like
> IEEE 754's signbit function, returning 1 for negative values and -0.0,
> and 0 for positive values and 0.0.  Ideally, something giving a
> boolean result:  hasSignBit.  (Insert better name here.)
> 
Sometimes it's called the signum function. In exists in BASIC (SGN), for
example, although I don't know what it would return for NaN (the
versions I've used didn't have NaN).


From george.sakkis at gmail.com  Tue Apr 27 00:12:17 2010
From: george.sakkis at gmail.com (George Sakkis)
Date: Tue, 27 Apr 2010 00:12:17 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
Message-ID: <h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>

On Mon, Apr 26, 2010 at 11:41 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> On Mon, Apr 26, 2010 at 11:34 PM, George Sakkis <george.sakkis at gmail.com>
> wrote:
>>
>> On Mon, Apr 26, 2010 at 11:18 PM, cool-RR <cool-rr at cool-rr.com> wrote:
>> > On Mon, Apr 26, 2010 at 11:13 PM, Xavier Ho <contact at xavierho.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 27, 2010 at 7:10 AM, cool-RR <cool-rr at cool-rr.com> wrote:
>> >>>
>> >>> Just something small that I thought of, and I haven't thought about
>> >>> this
>> >>> deeply at all, so maybe this is way wrong. But: What about adding a
>> >>> `Reversable` next to all the `Iterable` and `Container` and stuff?
>> >>
>> >> You mean there is something Iterable we can't reverse by doing [::-1]
>> >> or
>> >> calling reversed() ? This idea feels a bit too general to be useful.
>> >> Any
>> >> rationales?
>> >>
>> >> Cheers,
>> >> Xav
>> >
>> > As far as I know, iterables are generally not reversable. Try defining a
>> > simple iterator, like a class with just an `__iter__` function, and run
>> > `reversed` on it. You get `TypeError: argument to reversed() must be a
>> > sequence`. (Which by the way is a bad error message.)
>> > Am I missing something?
>>
>> So what should reversed() (or a new Reversable()) return for, say,
>> itertools.count() ?
>>
>> By the way, comp.lang.python [1] or the tutor mailing list [2] are
>> more appropriate than python-ideas for asking
>> questions "you haven't thought about deeply at all".
>>
>> George
>>
>> [1] http://mail.python.org/mailman/listinfo/python-list
>> [2] http://mail.python.org/mailman/listinfo/tutor
>
> I'm not really understanding you, George. Am I getting something very wrong
> here? When you put `itertools.count()` into `reversed()`, you get an error,
> like you should, because it's not a sequence and it doesn't define
> `__reversed__`. So it's not a reversable object. I'm proposing to have a
> `Reversable` similar to `Iterable`, which checks the existence of
> `__reversed__` instead of `__iter__`.

Sorry, it wasn't obvious (to me at least) that you were talking about
the abstract classes under the collections module, and in your second
post you implied (again, that was my understanding at any rate) that
defining a class with just an __iter__ should be acceptable by
`reversed` instead of raising a TypeError.

On the other hand a collections.Reversable abstract class that checks
specifically for __reversed__ sounds quite reasonable.

George


From ncoghlan at gmail.com  Tue Apr 27 11:52:06 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 27 Apr 2010 19:52:06 +1000
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <p2i5c6f2a5d1004261444gc870e96fia7f774115f693bbf@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>	<m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>
	<p2i5c6f2a5d1004261444gc870e96fia7f774115f693bbf@mail.gmail.com>
Message-ID: <4BD6B3C6.8010703@gmail.com>

Mark Dickinson wrote:
> On Mon, Apr 26, 2010 at 10:36 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> If a sign function were implemented, I'd probably want something like
>> IEEE 754's signbit function
> 
> Correction:  it's C99 that has a signbit function.  IEEE 754-2008
> specifies an 'isSignMinus' function with exactly the same semantics:
> values with the sign bit set (including -0.0, -inf, and NaNs whose
> sign bit is set) return True;  other values return False.
> 
> I wouldn't object to a `math.is_signed` function or a
> `float.is_signed` method with these semantics.  It's not clear where
> is the better place:  we have `math.isnan` and `math.isinf`, but
> `float.is_integer`.

"is_signed" would probably be a bad name for this purpose. In typical
compsci parlance, all of our numeric types are signed.

For the semantics you're talking about, math.signbit would be a more
reasonable name. (since we can legitimately answer the question for both
integers and floats, whereas "is_integer" is a pretty redundant question
if you are dealing with an integer type)

Cheers,
Nick.

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


From dickinsm at gmail.com  Tue Apr 27 12:36:37 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 27 Apr 2010 11:36:37 +0100
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <4BD6B3C6.8010703@gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>
	<m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>
	<p2i5c6f2a5d1004261444gc870e96fia7f774115f693bbf@mail.gmail.com>
	<4BD6B3C6.8010703@gmail.com>
Message-ID: <g2w5c6f2a5d1004270336zdf8dfcf5t16cc2c2ef807f491@mail.gmail.com>

On Tue, Apr 27, 2010 at 10:52 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Mark Dickinson wrote:
>> On Mon, Apr 26, 2010 at 10:36 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> I wouldn't object to a `math.is_signed` function or a
>> `float.is_signed` method with these semantics. ?It's not clear where
>> is the better place: ?we have `math.isnan` and `math.isinf`, but
>> `float.is_integer`.
>
> "is_signed" would probably be a bad name for this purpose. In typical
> compsci parlance, all of our numeric types are signed.

I agree that it's not a great name.  It comes from the Decimal module:
 there's a Decimal.is_signed method.  That name in turn comes from the
specification, which calls it "is-signed".  I'd have preferred
is_negative, but that's not really right either, since -0.0 isn't
strictly speaking negative.

> For the semantics you're talking about, math.signbit would be a more
> reasonable name. (since we can legitimately answer the question for both
> integers and floats, whereas "is_integer" is a pretty redundant question
> if you are dealing with an integer type)

And if it's a function in the math module, it seems entirely
reasonable to re-use the C99 name.

So the proposal is:  add a math.signbit function, with exactly the
same semantics as the C99 signbit function:  returning 1 for values
with the signbit set (negative values, -0.0, nans with the sign bit
set) and 0 otherwise.  It would return 0 for a zero integer, too.  A
Python implementation is as simple as:

    import math
    def signbit(x):
        return 1 if math.copysign(1.0, x) == -1.0 else 0

Would this be of value to anyone?  I'd only vote +0, since I don't
feel a great need for this function.

By the way, the signbit function definitely does have uses:  for
example, it's useful for implementing odd (in the mathematical sense)
functions like asinh while making sure that signed zeros are treated
correctly:

    def asinh(x):
        if signbit(x):
            return -asinh(-x)
        # deal with nonnegative values here

If the test were simply "if x > 0.0:" then (depending on exactly what
the rest of the function looks like) you'd risk getting the wrong sign
for at least one of 0.0 and -0.0.  Of course, you can still use
copysign to do the test, as above, but it's clunkier.

Mark


From ncoghlan at gmail.com  Tue Apr 27 15:29:57 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 27 Apr 2010 23:29:57 +1000
Subject: [Python-ideas] Why no sign function?
In-Reply-To: <g2w5c6f2a5d1004270336zdf8dfcf5t16cc2c2ef807f491@mail.gmail.com>
References: <l2oa422b72d1004261412qc43d91b9ge3d1b9ae640774c9@mail.gmail.com>	
	<m2w5c6f2a5d1004261436z22d9e661g139fa5561f5d8da@mail.gmail.com>	
	<p2i5c6f2a5d1004261444gc870e96fia7f774115f693bbf@mail.gmail.com>	
	<4BD6B3C6.8010703@gmail.com>
	<g2w5c6f2a5d1004270336zdf8dfcf5t16cc2c2ef807f491@mail.gmail.com>
Message-ID: <4BD6E6D5.5000102@gmail.com>

Mark Dickinson wrote:
> Would this be of value to anyone?  I'd only vote +0, since I don't
> feel a great need for this function.

I'm in a similar position. I was merely commenting that *if* we did
anything, a C99 inspired math.signbit would probably be the thing to add.

(I don't see the value of the 3 way comparison, since that doesn't
suffer any signed zero oddities, and hence, NaN values aside, can be
handled with the ordinary comparison operators).

Cheers,
Nick.

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


From ilya_shl at alum.mit.edu  Tue Apr 27 19:55:30 2010
From: ilya_shl at alum.mit.edu (Ilya Shlyakhter)
Date: Tue, 27 Apr 2010 13:55:30 -0400
Subject: [Python-ideas] math.fsum: summing multiple running sums at once
Message-ID: <o2y4b11f87e1004271055xd07099f8ha22996aee5e7b8e5@mail.gmail.com>

A suggestion: extend math.fsum to accept an iterable that yields
tuples of floats, and returns a tuple of sums.
This would permit summing multiple running sums at once (e.g. keeping
both a sum and a sum-of-squares for computing
standard deviation from an iterable), or summing a stream of complex numbers.

An alternative would be to make an object-oriented version of fsum
that has a method for adding a number to the sum;
then an array of such objects could be used to sum multiple iterables
simultaneously.

It would also be good if other methods based on fsum were included in
the standard library, e.g. for accurately computing
the mean and stddev of an iterable.

Thanks,

ilya


From cool-rr at cool-rr.com  Wed Apr 28 12:48:36 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Wed, 28 Apr 2010 12:48:36 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
Message-ID: <v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>

On Tue, Apr 27, 2010 at 12:12 AM, George Sakkis <george.sakkis at gmail.com>wrote:

> On Mon, Apr 26, 2010 at 11:41 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> > On Mon, Apr 26, 2010 at 11:34 PM, George Sakkis <george.sakkis at gmail.com
> >
> > wrote:
> >>
> >> On Mon, Apr 26, 2010 at 11:18 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> >> > On Mon, Apr 26, 2010 at 11:13 PM, Xavier Ho <contact at xavierho.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Apr 27, 2010 at 7:10 AM, cool-RR <cool-rr at cool-rr.com>
> wrote:
> >> >>>
> >> >>> Just something small that I thought of, and I haven't thought about
> >> >>> this
> >> >>> deeply at all, so maybe this is way wrong. But: What about adding a
> >> >>> `Reversable` next to all the `Iterable` and `Container` and stuff?
> >> >>
> >> >> You mean there is something Iterable we can't reverse by doing [::-1]
> >> >> or
> >> >> calling reversed() ? This idea feels a bit too general to be useful.
> >> >> Any
> >> >> rationales?
> >> >>
> >> >> Cheers,
> >> >> Xav
> >> >
> >> > As far as I know, iterables are generally not reversable. Try defining
> a
> >> > simple iterator, like a class with just an `__iter__` function, and
> run
> >> > `reversed` on it. You get `TypeError: argument to reversed() must be a
> >> > sequence`. (Which by the way is a bad error message.)
> >> > Am I missing something?
> >>
> >> So what should reversed() (or a new Reversable()) return for, say,
> >> itertools.count() ?
> >>
> >> By the way, comp.lang.python [1] or the tutor mailing list [2] are
> >> more appropriate than python-ideas for asking
> >> questions "you haven't thought about deeply at all".
> >>
> >> George
> >>
> >> [1] http://mail.python.org/mailman/listinfo/python-list
> >> [2] http://mail.python.org/mailman/listinfo/tutor
> >
> > I'm not really understanding you, George. Am I getting something very
> wrong
> > here? When you put `itertools.count()` into `reversed()`, you get an
> error,
> > like you should, because it's not a sequence and it doesn't define
> > `__reversed__`. So it's not a reversable object. I'm proposing to have a
> > `Reversable` similar to `Iterable`, which checks the existence of
> > `__reversed__` instead of `__iter__`.
>
> Sorry, it wasn't obvious (to me at least) that you were talking about
> the abstract classes under the collections module, and in your second
> post you implied (again, that was my understanding at any rate) that
> defining a class with just an __iter__ should be acceptable by
> `reversed` instead of raising a TypeError.
>
> On the other hand a collections.Reversable abstract class that checks
> specifically for __reversed__ sounds quite reasonable.
>
> George
>

Does anyone else care to express their opinion about the Reversable
suggestion?

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100428/dcc2e831/attachment.html>

From masklinn at masklinn.net  Wed Apr 28 12:52:41 2010
From: masklinn at masklinn.net (Masklinn)
Date: Wed, 28 Apr 2010 12:52:41 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
Message-ID: <9BF1A821-F4FD-4CBD-86CA-6B032EBD0693@masklinn.net>

On 28 Apr 2010, at 12:48 , cool-RR wrote:
> 
> On Tue, Apr 27, 2010 at 12:12 AM, George Sakkis <george.sakkis at gmail.com>wrote:
> 
>> On Mon, Apr 26, 2010 at 11:41 PM, cool-RR <cool-rr at cool-rr.com> wrote:
>>> On Mon, Apr 26, 2010 at 11:34 PM, George Sakkis <george.sakkis at gmail.com
>>> 
>>> wrote:
>>>> 
>>>> On Mon, Apr 26, 2010 at 11:18 PM, cool-RR <cool-rr at cool-rr.com> wrote:
>>>>> On Mon, Apr 26, 2010 at 11:13 PM, Xavier Ho <contact at xavierho.com>
>>>>> wrote:
>>>>>> 
>>>>>> On Tue, Apr 27, 2010 at 7:10 AM, cool-RR <cool-rr at cool-rr.com>
>> wrote:
>>>>>>> 
>>>>>>> Just something small that I thought of, and I haven't thought about
>>>>>>> this
>>>>>>> deeply at all, so maybe this is way wrong. But: What about adding a
>>>>>>> `Reversable` next to all the `Iterable` and `Container` and stuff?
>>>>>> 
>>>>>> You mean there is something Iterable we can't reverse by doing [::-1]
>>>>>> or
>>>>>> calling reversed() ? This idea feels a bit too general to be useful.
>>>>>> Any
>>>>>> rationales?
>>>>>> 
>>>>>> Cheers,
>>>>>> Xav
>>>>> 
>>>>> As far as I know, iterables are generally not reversable. Try defining
>> a
>>>>> simple iterator, like a class with just an `__iter__` function, and
>> run
>>>>> `reversed` on it. You get `TypeError: argument to reversed() must be a
>>>>> sequence`. (Which by the way is a bad error message.)
>>>>> Am I missing something?
>>>> 
>>>> So what should reversed() (or a new Reversable()) return for, say,
>>>> itertools.count() ?
>>>> 
>>>> By the way, comp.lang.python [1] or the tutor mailing list [2] are
>>>> more appropriate than python-ideas for asking
>>>> questions "you haven't thought about deeply at all".
>>>> 
>>>> George
>>>> 
>>>> [1] http://mail.python.org/mailman/listinfo/python-list
>>>> [2] http://mail.python.org/mailman/listinfo/tutor
>>> 
>>> I'm not really understanding you, George. Am I getting something very
>> wrong
>>> here? When you put `itertools.count()` into `reversed()`, you get an
>> error,
>>> like you should, because it's not a sequence and it doesn't define
>>> `__reversed__`. So it's not a reversable object. I'm proposing to have a
>>> `Reversable` similar to `Iterable`, which checks the existence of
>>> `__reversed__` instead of `__iter__`.
>> 
>> Sorry, it wasn't obvious (to me at least) that you were talking about
>> the abstract classes under the collections module, and in your second
>> post you implied (again, that was my understanding at any rate) that
>> defining a class with just an __iter__ should be acceptable by
>> `reversed` instead of raising a TypeError.
>> 
>> On the other hand a collections.Reversable abstract class that checks
>> specifically for __reversed__ sounds quite reasonable.
>> 
>> George
>> 
> 
> Does anyone else care to express their opinion about the Reversable
> suggestion?
> 
> Ram.
I'm not quite sure of the point/use case for the feature, but that's about
it.



From p.f.moore at gmail.com  Wed Apr 28 13:00:53 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 28 Apr 2010 12:00:53 +0100
Subject: [Python-ideas] Reversable
In-Reply-To: <v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
Message-ID: <r2q79990c6b1004280400ub2e96aa2jc32e803c24d00e60@mail.gmail.com>

On 28 April 2010 11:48, cool-RR <cool-rr at cool-rr.com> wrote:
> Does anyone else care to express their opinion about the Reversable
> suggestion?

I think you need some more convincing use cases, and a better
explanation of how you'd see it working. As things stand, it sounds
like you're just suggesting it for completeness' sake. I assume you're
expecting an implementation which checks if the type is an instance of
Sequence or has a callable attribute __reversed__?

Then again, I'm not a great user of ABCs in any case - easier to ask
forgiveness and all that, I'd tend to just use reversed() and be
prepared to deal with an error if the caller passed something
non-reversible (maybe just by expecting the caller to deal with the
exception, because they didn't satisfy the input requirements).

Paul.


From arnodel at googlemail.com  Wed Apr 28 15:46:32 2010
From: arnodel at googlemail.com (Arnaud Delobelle)
Date: Wed, 28 Apr 2010 14:46:32 +0100
Subject: [Python-ideas] Reversable
In-Reply-To: <v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
Message-ID: <x2k9bfc700a1004280646qa19bdec7u8af191854052d699@mail.gmail.com>

On 28 April 2010 11:48, cool-RR <cool-rr at cool-rr.com> wrote:

> Does anyone else care to express their opinion about the Reversable
> suggestion?
> Ram.

Call it Reversible :)

-- 
Arnaud


From grosser.meister.morti at gmx.net  Wed Apr 28 17:59:21 2010
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Wed, 28 Apr 2010 17:59:21 +0200
Subject: [Python-ideas] why has itertools.imap other semantics as the bultin
	map?
Message-ID: <4BD85B59.7090702@gmx.net>

See:
 >>> map(None,['a','b'],[])
[('a', None), ('b', None)]
 >>> list(imap(None,['a','b'],[]))
[]

Why is that? I propose that imap should work like map (except from being a generator, of course).

System Info:
Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47)
[GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2

	-panzi


From george.sakkis at gmail.com  Wed Apr 28 18:44:49 2010
From: george.sakkis at gmail.com (George Sakkis)
Date: Wed, 28 Apr 2010 18:44:49 +0200
Subject: [Python-ideas] why has itertools.imap other semantics as the
	bultin map?
In-Reply-To: <4BD85B59.7090702@gmx.net>
References: <4BD85B59.7090702@gmx.net>
Message-ID: <m2v91ad5bf81004280944k7268677ao1a44b5de8d6a2c76@mail.gmail.com>

On Wed, Apr 28, 2010 at 5:59 PM, Mathias Panzenb?ck
<grosser.meister.morti at gmx.net> wrote:

> See:
>>>> map(None,['a','b'],[])
> [('a', None), ('b', None)]
>>>> list(imap(None,['a','b'],[]))
> []
>
> Why is that? I propose that imap should work like map (except from being a
> generator, of course).
>
> System Info:
> Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47)
> [GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2

Practically speaking, Python 2.7 is in beta so even if there was no
objection, it's pretty unlikely this lands in 2.x (and 3.x has dropped
itertools.imap so there's no confusion).

By the way, that's not the only difference of map and itertools.imap:

>>> map(None, 'abc')
['a', 'b', 'c']
>>>  list(itertools.imap(None, 'abc'))
[('a',), ('b',), ('c',)]

George


From raymond.hettinger at gmail.com  Wed Apr 28 19:19:35 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 28 Apr 2010 10:19:35 -0700
Subject: [Python-ideas] why has itertools.imap other semantics as the
	bultin map?
In-Reply-To: <4BD85B59.7090702@gmx.net>
References: <4BD85B59.7090702@gmx.net>
Message-ID: <90B3BC0D-2F30-4684-97D9-FE9FB388232C@gmail.com>


On Apr 28, 2010, at 8:59 AM, Mathias Panzenb?ck wrote:

> See:
> >>> map(None,['a','b'],[])
> [('a', None), ('b', None)]
> >>> list(imap(None,['a','b'],[]))
> []
> 
> Why is that?

Excerpt from the source file at http://svn.python.org/view/python/trunk/Modules/itertoolsmodule.c?view=markup :

/*	
imap() is an iterator version of __builtins__.map() except that it does
not have the None fill-in feature.  That was intentionally left out for
the following reasons:

  1) Itertools are designed to be easily combined and chained together.
     Having all tools stop with the shortest input is a unifying principle
     that makes it easier to combine finite iterators (supplying data) with
     infinite iterators like count() and repeat() (for supplying sequential
     or constant arguments to a function).

  2) In typical use cases for combining itertools, having one finite data 
     supplier run out before another is likely to be an error condition which
     should not pass silently by automatically supplying None.

  3) The use cases for automatic None fill-in are rare -- not many functions
     do something useful when a parameter suddenly switches type and becomes
     None.  

  4) If a need does arise, it can be met by __builtins__.map() or by 
     writing:  chain(iterable, repeat(None)).

  5) Similar toolsets in Haskell and SML do not have automatic None fill-in.
*/




> I propose that imap should work like map (except from being a generator, of course).

Sorry, this was considered and rejected a long time ago.
Changing the none fill-in behavior would break working code.

FWIW, izip_longest() supports fill-in behavior for the handful
of use cases that need it.



Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100428/10798f6e/attachment.html>

From cool-rr at cool-rr.com  Thu Apr 29 03:15:22 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Thu, 29 Apr 2010 03:15:22 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <r2q79990c6b1004280400ub2e96aa2jc32e803c24d00e60@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
	<r2q79990c6b1004280400ub2e96aa2jc32e803c24d00e60@mail.gmail.com>
Message-ID: <i2ra422b72d1004281815h903e0809ud0919d8c5758c178@mail.gmail.com>

On Wed, Apr 28, 2010 at 1:00 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 28 April 2010 11:48, cool-RR <cool-rr at cool-rr.com> wrote:
> > Does anyone else care to express their opinion about the Reversable
> > suggestion?
>
> I think you need some more convincing use cases, and a better
> explanation of how you'd see it working. As things stand, it sounds
> like you're just suggesting it for completeness' sake. I assume you're
> expecting an implementation which checks if the type is an instance of
> Sequence or has a callable attribute __reversed__?
>
> Then again, I'm not a great user of ABCs in any case - easier to ask
> forgiveness and all that, I'd tend to just use reversed() and be
> prepared to deal with an error if the caller passed something
> non-reversible (maybe just by expecting the caller to deal with the
> exception, because they didn't satisfy the input requirements).
>
> Paul.
>

I agree with your criticisms. I was indeed offering it for completeness'
sake, I think that when I needed it, I had some iterable that I didn't know
if I could use `reversed` on.

Though this leads me to another thought: Maybe we should have an argument to
`reversed` which will instruct it to make a list out of the iterable and
then return the `reversed` of that list, but only when the original iterable
is not naturally reversible. This way you could be sure that `reversed` will
work on any iterable. (When you don't care much about performance, of
course.)

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100429/e1603fb4/attachment.html>

From stefan_ml at behnel.de  Thu Apr 29 07:01:11 2010
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 29 Apr 2010 07:01:11 +0200
Subject: [Python-ideas] why has itertools.imap other semantics as the
	bultin map?
In-Reply-To: <90B3BC0D-2F30-4684-97D9-FE9FB388232C@gmail.com>
References: <4BD85B59.7090702@gmx.net>
	<90B3BC0D-2F30-4684-97D9-FE9FB388232C@gmail.com>
Message-ID: <hrb3qn$on7$1@dough.gmane.org>

Raymond Hettinger, 28.04.2010 19:19:
> On Apr 28, 2010, at 8:59 AM, Mathias Panzenb?ck wrote:
>> See:
>>>>> map(None,['a','b'],[])
>> [('a', None), ('b', None)]
>>>>> list(imap(None,['a','b'],[]))
>> []
>>
>> Why is that?
>
> Excerpt from the source file at http://svn.python.org/view/python/trunk/Modules/itertoolsmodule.c?view=markup :
>
> /*	
> imap() is an iterator version of __builtins__.map() except that it does
> not have the None fill-in feature.  That was intentionally left out for
> the following reasons:
>
>    1) Itertools are designed to be easily combined and chained together.
>       Having all tools stop with the shortest input is a unifying principle
>       that makes it easier to combine finite iterators (supplying data) with
>       infinite iterators like count() and repeat() (for supplying sequential
>       or constant arguments to a function).
>
>    2) In typical use cases for combining itertools, having one finite data
>       supplier run out before another is likely to be an error condition which
>       should not pass silently by automatically supplying None.
>
>    3) The use cases for automatic None fill-in are rare -- not many functions
>       do something useful when a parameter suddenly switches type and becomes
>       None.
>
>    4) If a need does arise, it can be met by __builtins__.map() or by
>       writing:  chain(iterable, repeat(None)).
>
>    5) Similar toolsets in Haskell and SML do not have automatic None fill-in.
> */

It's worth adding that itertools.imap() became map() in Python 3.

Stefan



From dickinsm at gmail.com  Thu Apr 29 11:54:11 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Thu, 29 Apr 2010 10:54:11 +0100
Subject: [Python-ideas] math.fsum: summing multiple running sums at once
In-Reply-To: <o2y4b11f87e1004271055xd07099f8ha22996aee5e7b8e5@mail.gmail.com>
References: <o2y4b11f87e1004271055xd07099f8ha22996aee5e7b8e5@mail.gmail.com>
Message-ID: <r2l5c6f2a5d1004290254p15650f75j3f17accd2ccc01cc@mail.gmail.com>

On Tue, Apr 27, 2010 at 6:55 PM, Ilya Shlyakhter <ilya_shl at alum.mit.edu> wrote:
> A suggestion: extend math.fsum to accept an iterable that yields
> tuples of floats, and returns a tuple of sums.
> This would permit summing multiple running sums at once (e.g. keeping
> both a sum and a sum-of-squares for computing
> standard deviation from an iterable), or summing a stream of complex numbers.
>
> An alternative would be to make an object-oriented version of fsum
> that has a method for adding a number to the sum;
> then an array of such objects could be used to sum multiple iterables
> simultaneously.

It's an interesting idea.  The second alternative appeals to me more
than the first:  I could see other uses for being able to pass a
partial sum state around.

Mark


From p.f.moore at gmail.com  Thu Apr 29 13:01:03 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 29 Apr 2010 12:01:03 +0100
Subject: [Python-ideas] Reversable
In-Reply-To: <i2ra422b72d1004281815h903e0809ud0919d8c5758c178@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
	<r2q79990c6b1004280400ub2e96aa2jc32e803c24d00e60@mail.gmail.com>
	<i2ra422b72d1004281815h903e0809ud0919d8c5758c178@mail.gmail.com>
Message-ID: <v2i79990c6b1004290401oa43fccffz7ed7d7b164df974d@mail.gmail.com>

On 29 April 2010 02:15, cool-RR <cool-rr at cool-rr.com> wrote:
> Though this leads me to another thought: Maybe we should have an argument to
> `reversed` which will instruct it to make a list out of the iterable and
> then return the `reversed` of that list, but only when the original iterable
> is not naturally reversible. This way you could be sure that `reversed` will
> work on any iterable. (When you don't care much about performance, of
> course.)

def reversed_anything(a):
    try:
        return reversed(a)
    except TypeError:
        return reversed(list(a))

Paul


From cool-rr at cool-rr.com  Thu Apr 29 13:22:41 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Thu, 29 Apr 2010 13:22:41 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <v2i79990c6b1004290401oa43fccffz7ed7d7b164df974d@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<n2y2d56febf1004261413nbaee5ca4va3a8c219c03ff4ba@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
	<r2q79990c6b1004280400ub2e96aa2jc32e803c24d00e60@mail.gmail.com>
	<i2ra422b72d1004281815h903e0809ud0919d8c5758c178@mail.gmail.com>
	<v2i79990c6b1004290401oa43fccffz7ed7d7b164df974d@mail.gmail.com>
Message-ID: <z2qa422b72d1004290422h3d516b0bi77b537067ca41405@mail.gmail.com>

On Thu, Apr 29, 2010 at 1:01 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 29 April 2010 02:15, cool-RR <cool-rr at cool-rr.com> wrote:
> > Though this leads me to another thought: Maybe we should have an argument
> to
> > `reversed` which will instruct it to make a list out of the iterable and
> > then return the `reversed` of that list, but only when the original
> iterable
> > is not naturally reversible. This way you could be sure that `reversed`
> will
> > work on any iterable. (When you don't care much about performance, of
> > course.)
>
> def reversed_anything(a):
>    try:
>        return reversed(a)
>    except TypeError:
>        return reversed(list(a))
>
> Paul
>

Yes, I'm aware the implementation is simple. I was not asking for an
implementation. I was just raising the idea that it should be part of the
builtin `reversed`. But since there are no +1s, I guess not.

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100429/3bc8f697/attachment.html>

From p.f.moore at gmail.com  Fri Apr 30 00:33:24 2010
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 29 Apr 2010 23:33:24 +0100
Subject: [Python-ideas] Reversable
In-Reply-To: <z2qa422b72d1004290422h3d516b0bi77b537067ca41405@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<t2ka422b72d1004261418h10188a32u7344325f19438d7b@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
	<r2q79990c6b1004280400ub2e96aa2jc32e803c24d00e60@mail.gmail.com>
	<i2ra422b72d1004281815h903e0809ud0919d8c5758c178@mail.gmail.com>
	<v2i79990c6b1004290401oa43fccffz7ed7d7b164df974d@mail.gmail.com>
	<z2qa422b72d1004290422h3d516b0bi77b537067ca41405@mail.gmail.com>
Message-ID: <r2l79990c6b1004291533zac3fe0c1meb5d0ce6a4e4cb59@mail.gmail.com>

On 29 April 2010 12:22, cool-RR <cool-rr at cool-rr.com> wrote:
> Yes, I'm aware the implementation is simple. I was not asking for an
> implementation. I was just raising the idea that it should be part of the
> builtin `reversed`. But since there are no +1s, I guess not.

Sorry. My point was that the gains (in terms of the difficulty of
implementing it yourself) are minor, so the cost doesn't justify it.
Specifically, the costs are (1) extra complexity when describing the
behaviour of reversed() and (2) more seriously, potential crashes if
an infinite generator (for example) is passed to reversed() in error.

Currently, reversed(infinite_gen) is a trappable error. With your
proposal, it would halt the program until all memory was consumed,
then crash. Anyone using a custom function such as my
reversed_anything can be assumed to understand its limitations,
whereas builtins can be assumed to behave "nicely".

Looking at it the other way, it's easy to build reversed_anything
given reversed, but it's not possible to build reversed given only
reversed_anything. The builtin function should be the one that can be
more easily used to build from.

My apologies for being too terse.
Paul.


From cool-rr at cool-rr.com  Fri Apr 30 00:47:58 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Fri, 30 Apr 2010 00:47:58 +0200
Subject: [Python-ideas] Reversable
In-Reply-To: <r2l79990c6b1004291533zac3fe0c1meb5d0ce6a4e4cb59@mail.gmail.com>
References: <r2pa422b72d1004261410j81eca69cu15fb33643aff4f02@mail.gmail.com>
	<k2x91ad5bf81004261434w1e6d35f6o2573551494945ce2@mail.gmail.com>
	<o2ra422b72d1004261441qb17154e2lb76287c36b292af8@mail.gmail.com>
	<h2x91ad5bf81004261512y2265db97j56b6d78af09b929a@mail.gmail.com>
	<v2ha422b72d1004280348j7dc6038avacf28658aaa268b8@mail.gmail.com>
	<r2q79990c6b1004280400ub2e96aa2jc32e803c24d00e60@mail.gmail.com>
	<i2ra422b72d1004281815h903e0809ud0919d8c5758c178@mail.gmail.com>
	<v2i79990c6b1004290401oa43fccffz7ed7d7b164df974d@mail.gmail.com>
	<z2qa422b72d1004290422h3d516b0bi77b537067ca41405@mail.gmail.com>
	<r2l79990c6b1004291533zac3fe0c1meb5d0ce6a4e4cb59@mail.gmail.com>
Message-ID: <y2xa422b72d1004291547hb0c5a41bp294dc2b98587b6e@mail.gmail.com>

On Fri, Apr 30, 2010 at 12:33 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 29 April 2010 12:22, cool-RR <cool-rr at cool-rr.com> wrote:
> > Yes, I'm aware the implementation is simple. I was not asking for an
> > implementation. I was just raising the idea that it should be part of the
> > builtin `reversed`. But since there are no +1s, I guess not.
>
> Sorry. My point was that the gains (in terms of the difficulty of
> implementing it yourself) are minor, so the cost doesn't justify it.
> Specifically, the costs are (1) extra complexity when describing the
> behaviour of reversed() and (2) more seriously, potential crashes if
> an infinite generator (for example) is passed to reversed() in error.
>
> Currently, reversed(infinite_gen) is a trappable error. With your
> proposal, it would halt the program until all memory was consumed,
> then crash. Anyone using a custom function such as my
> reversed_anything can be assumed to understand its limitations,
> whereas builtins can be assumed to behave "nicely".
>
> Looking at it the other way, it's easy to build reversed_anything
> given reversed, but it's not possible to build reversed given only
> reversed_anything. The builtin function should be the one that can be
> more easily used to build from.
>
> My apologies for being too terse.
> Paul.
>

Thanks for the apology Paul.

As I said in my message before, I proposed having an argument to `reversed`
which will cause this "violent reverse" behavior. I didn't say I want
`reversed` to do it by default. Like, I suggest you could do
`reversed(iterator, violent=True)`, and only that will cause the iterator to
be copied to a list before getting reversed.

Though actually, I don't feel very strongly about this issue. I was just
raising it to see whether it happened to be something that bothered other
people as well, and then maybe it would have been worth doing something
about. But it seems that it isn't, so I should probably let it go.

Thanks for your attention,
Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100430/1b102d61/attachment.html>