Re: [Python-Dev] Octal literals

[Bengt Richter]

On Thu, 2 Feb 2006 20:39:01 -0500, James Y Knight <[EMAIL PROTECTED]> wrote:

>On Feb 2, 2006, at 10:36 PM, Bengt Richter wrote:
>> So long as we have a distinction between int and long, IWT int will  
>> be fixed width
>> for any given implementation, and for interfacing with foreign  
>> functions it will
>> continue to be useful at times to limit the type of arguments being  
>> passed.
>
>We _don't_ have a distinction in any meaningful way, anymore. ints
Which will disappear, "int" or "long"? Or both in favor of "integer"?
What un-"meaningful" distinction(s) are you hedging your statement about? ;-)
  
>and longs are almost always treated exactly the same, other than the  
>"L" suffix. I expect that suffix will soon go away as well. If there  
>is code that _doesn't_ treat them the same, there is the bug. We  
If you are looking at them in C code receiving them as args in a call,
"treat them the same" would have to mean provide code to coerce long->int
or reject it with an exception, IWT. This could be a performance issue
that one might like to control by calling strictly with int args, or even
an implementation restriction due to lack of space on some microprocessor
for unnecessary general coercion code.

>don't need strange new syntax to work around buggy code.
It's not a matter of "buggy" if you are trying to optimize.
(I am aware of premature optimization issues, and IMO "strange"
is in the eye of the beholder. What syntax would you suggest?
I am not married to any particular syntax, just looking for
expressive control over what my programs will do ;-)

>
>Note that 10**14/10**13 is also a long, yet any interface that did  
>not accept that as an argument but did accept "10" is simply buggy.
def foo(i): assert isinstance(i, int); ... # when this becomes illegal, yes.

>Same goes for code that says it takes a 32-bit bitfield argument but  
>won't accept 0x8000.
If the bitfield is signed, it can't, unless you are glossing over
an assumed coercion rule.

 >>> int(0x8000)
 2147483648L
 >>> int(-0x8000)
 -2147483648

BTW, I am usually on the pure-abstraction-view side of discussions ;-)
Noticing-kindling-is-wet-and-about-out-of-matches-ly,

Regards,
Bengt Richter

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

Re: [Python-Dev] Octal literals

[Stefan Rank]

on 03.02.2006 00:16 Delaney, Timothy (Tim) said the following:
> Andrew Koenig wrote:
>>> I definately agree with the 0c664 octal literal. Seems rather more
>>> intuitive.
>> I still prefer 8r664.
> The more I look at this, the worse it gets. Something beginning with
> zero (like 0xFF, 0c664) immediately stands out as "unusual". Something
> beginning with any other digit doesn't.

Let me throw something into the arena :-)

I know there should only be one way to do it, but what about requiring a 
leading 0 for any 'special' number format, and then allow::

   0x1AFFE

and::

   016r1AFFE

   02r010001000101001

   08r1234567

and maybe have 0b be a synonym of 02r, and some other nice character 
(o/c) for octals.

For backwards compatibility you could even allow classic octal literals, 
though I think it would be better to have a Syntax Error for any literal 
starting with 0 but missing a radix code.

cheers

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Michael Hudson]

Alex Martelli <[EMAIL PROTECTED]> writes:

> I was recently reviewing a lot of the Python 2.4 code I have written,
> and I've noticed one thing: thanks to the attrgetter and itemgetter
> functions in module operator, I've been using (or been tempted to use)
> far fewer lambdas, particularly but not exclusively in key= arguments
> to sort and sorted.

Interesting.  Something I'd noticed was that *until* the key= argument
to sort appeared, I was hardly using any lambdas at all (most of the
places I had used them were rendered obsolete by list comprehensions).

> Most of those "lambda temptations" will be
> removed by PEP 309 (functional.partial), and most remaining ones are
> of the form:
> lambda x: x.amethod(zip, zop)
>
> So I was thinking -- wouldn't it be nice to have (possibly in module
> functional, like partial; possibly in module operator, like itemgetter
> and attrgetter -- I'm partial to functional;-) a methodcaller entry
> akin to (...possibly with a better name...):
>
> def methodcaller(methodname, *a, **k):
> def caller(self):
> getattr(self, methodname)(*a, **k)
> caller.__name__ = methodname
> return caller
>
> ...?  This would allow removal of even more lambdas.
>
> I'll be glad to write a PEP, but I first want to check whether the
> Python-Dev crowd would just blast it out of the waters, in which case
> I may save writing it...

Hmm.

>>> funcTakingCallback(lamda x:x.method(zip, zop))
>>> funcTakingCallback(methodcaller("method", zip, zop))

I'm not sure which of these is clearer really.  Are lambdas so bad?
(FWIW, I haven't internalized itemgetter/attrgetter yet and still tend
to use lambdas instead those too).

A class I wrote (and lost) ages ago was a "placeholder" class, so if
'X' was an instance of this class, "X + 1" was roughly equivalent to
"lambda x:x+1" and "X.method(zip, zop)" was roughly equivalent to your
"methodcaller("method", zip, zop)".  I threw it away when listcomps
got implemented.  Not sure why I mention it now, something about your
post made me think of it...

Cheers,
mwh


-- 
  If you give someone Fortran, he has Fortran.
  If you give someone Lisp, he has any language he pleases.
-- Guy L. Steele Jr, quoted by David Rush in comp.lang.scheme.scsh
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Octal literals

[Nick Coghlan]

Bengt Richter wrote:
> On Fri, 3 Feb 2006 10:16:17 +1100, "Delaney, Timothy (Tim)" <[EMAIL 
> PROTECTED]> wrote:
> 
>> Andrew Koenig wrote:
>>
 I definately agree with the 0c664 octal literal. Seems rather more
 intuitive.
>>> I still prefer 8r664.
>> The more I look at this, the worse it gets. Something beginning with
>> zero (like 0xFF, 0c664) immediately stands out as "unusual". Something
>> beginning with any other digit doesn't. This just looks like noise to
>> me.
>>
>> I found the suffix version even worse, but they're blown out of the
>> water anyway by the fact that FFr16 is a valid identifier.
>>
> Are you sure you aren't just used to the x in 0xff? I.e., if the leading
> 0 were just an alias for 16, we could use 8x664 instead of 8r664.

No, I'm with Tim - it's definitely the distinctive shape of the '0' that helps 
the non-standard base stand out. '0c' creates a similar shape, also helping it 
to stand out. More on distinctive shapes below, though.

That said, I'm still trying to figure out exactly what problem is being solved 
here. Thinking out loud. . .

The full syntax for writing integers in any base is:

   int("LITERAL", RADIX)
   int("LITERAL", base=RADIX)

5 prefix chars, 3 or 8 in the middle (counting the space, and depending on 
whether the keyword is used or not), one on the end, and one or two to specify 
the radix. That's quite verbose, so its unsurprising that many would like 
something nicer in the toolkit when they need to write multiple numeric 
literals in a base other than ten. This can typically happen when writing Unix 
system admin scripts, bitbashing to control a piece of hardware or some other 
low-level task.

The genuine use cases we have for integer literals are:
   - decimal (normal numbers)
   - hex (compact bitmasks)
   - octal (unix file permissions)
   - binary (explicit bitmasks for those that don't speak fluent hex)

Currently, there is no syntax for binary literals, and the syntax for octal 
literals is both magical (where else in integer mathematics does a leading 
zero matter?) and somewhat error prone (int and eval will give different 
answers for a numeric literal with a leading zero - int ignores the leading 
zero, eval treats it as signifying that the value is in octal. The charming 
result is that the following statement fails: assert int('0123') == 0123).

Looking at existing precedent in the language, a prefix is currently used when 
the parsing of the subsequent literal may be affected (that is, the elements 
that make up the literal may be interpreted differently depending on the 
prefix). This is the case for hex and octal literals, and also for raw and 
unicode strings.

Suffixes are currently used when the literal as a whole is affected, but the 
meaning of the individual elements remains the same. This is the case for both 
long integer and imaginary number literals. A suffix also makes sense for 
decimal float literals, as the individual elements would still be interpreted 
as base 10 digits.

So, since we want to affect the parsing process, this means we want a prefix. 
The convention of using '0x' to denote hex extends far beyond Python, and 
doesn't seem to provoke much in the way of objection.

This suggests options like '0o' or '0c' for octal literals. Given that '0x' 
matches the '%x' in string formatting, the least magical option would be '0o' 
(to match the existing '%o' output format). While '0c' is cute and quite 
suggestive, it creates a significant potential for confusion , as it most 
emphatically does *not* align with the meaning of the '%c' format specifier.

I'd be +0 on changing the octal literal prefix from '0' to '0o', and also +0 
on adding an '0b' prefix and '%b' format specifier for binary numbers.

Whether anyone will actually care enough to implement a patch to change the 
syntax for any of these is an entirely different question ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] any support for a methodcaller HOF?

[Ben . Young]

Michael Hudson wrote on 03/02/2006 09:36:30:

> 
> Hmm.
> 
> >>> funcTakingCallback(lamda x:x.method(zip, zop))
> >>> funcTakingCallback(methodcaller("method", zip, zop))
> 
> I'm not sure which of these is clearer really.  Are lambdas so bad?
> (FWIW, I haven't internalized itemgetter/attrgetter yet and still tend
> to use lambdas instead those too).
> 
> A class I wrote (and lost) ages ago was a "placeholder" class, so if
> 'X' was an instance of this class, "X + 1" was roughly equivalent to
> "lambda x:x+1" and "X.method(zip, zop)" was roughly equivalent to your
> "methodcaller("method", zip, zop)".  I threw it away when listcomps
> got implemented.  Not sure why I mention it now, something about your
> post made me think of it...
> 

The C++ library Boost makes use of this method, but has a number of 
"placeholder" variables _1, _2, _3 ... _9 which can be combined to form 
expressions. e.g _1 + _2 is the same as lambda x,y: x+y so maybe there 
could be a lambda module that exposes placeholders like this. Pythons ones 
will be better that the C++ ones because we would be able to delay 
function calls as above with a much nicer syntax than the C++ versions. 
E.g

_1.method(_2+_3) !

Cheers,
Ben

> Cheers,
> mwh
> 
> 
> -- 
>   If you give someone Fortran, he has Fortran.
>   If you give someone Lisp, he has any language he pleases.
> -- Guy L. Steele Jr, quoted by David Rush in comp.lang.scheme.scsh
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-
> dev/python%40theyoungfamily.co.uk
> 

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

Re: [Python-Dev] Octal literals

[Bob Ippolito]

On Feb 3, 2006, at 2:07 AM, Nick Coghlan wrote:

> Bengt Richter wrote:
>> On Fri, 3 Feb 2006 10:16:17 +1100, "Delaney, Timothy (Tim)"  
>> <[EMAIL PROTECTED]> wrote:
>>
>>> Andrew Koenig wrote:
>>>
> I definately agree with the 0c664 octal literal. Seems rather more
> intuitive.
 I still prefer 8r664.
>>> The more I look at this, the worse it gets. Something beginning with
>>> zero (like 0xFF, 0c664) immediately stands out as "unusual".  
>>> Something
>>> beginning with any other digit doesn't. This just looks like  
>>> noise to
>>> me.
>>>
>>> I found the suffix version even worse, but they're blown out of the
>>> water anyway by the fact that FFr16 is a valid identifier.
>>>
>> Are you sure you aren't just used to the x in 0xff? I.e., if the  
>> leading
>> 0 were just an alias for 16, we could use 8x664 instead of 8r664.
>
> Currently, there is no syntax for binary literals, and the syntax  
> for octal
> literals is both magical (where else in integer mathematics does a  
> leading
> zero matter?) and somewhat error prone (int and eval will give  
> different
> answers for a numeric literal with a leading zero - int ignores the  
> leading
> zero, eval treats it as signifying that the value is in octal. The  
> charming
> result is that the following statement fails: assert int('0123') ==  
> 0123).

That's just a misunderstanding on your part.  The default radix is  
10, not DWIM.  0 signifies that behavior::

assert int('0123', 0) == 0123
assert int('0x123', 0) == 0x123

-bob

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Nick Coghlan]

Michael Hudson wrote:
> Alex Martelli <[EMAIL PROTECTED]> writes:
>> I'll be glad to write a PEP, but I first want to check whether the
>> Python-Dev crowd would just blast it out of the waters, in which case
>> I may save writing it...
> 
> Hmm.
> 
 funcTakingCallback(lamda x:x.method(zip, zop))
 funcTakingCallback(methodcaller("method", zip, zop))
> 
> I'm not sure which of these is clearer really.  Are lambdas so bad?
> (FWIW, I haven't internalized itemgetter/attrgetter yet and still tend
> to use lambdas instead those too).

I've been convinced for a while that the proliferation of features like 
operator.itemgetter and attrgetter (and some uses of functional.partial) 
demonstrate that the ability to defer a single expression (as lambda currently 
allows) is a very useful feature to have in the language. Unfortunately that 
utility gets overshadowed by the ugliness of the syntax, the mathematical 
baggage associated with the current keyword, and the fact that lambda gets 
pitched as an "anonymous function limited to a single expression", rather than 
as "the ability to defer an expression for later evaluation" (the former 
sounds like a limitation that should be fixed, the latter sounds like the 
deliberate design choice that it is).

At the moment it looks like the baby is going to get thrown out with the 
bathwater in Py3k, but I'd love to be able to simply write the following 
instead of some byzantine mixture of function calls to get the same effect:

 funcTakingCallback(x.method(zip, zop) def (x))

Consider these comparisons:

   itemgetter(1) <=> (x[1] def (x))
   attrgetter('foo') <=> (x.foo def (x))
   partial(y, arg)   <=> (y(arg) def)

So rather than yet another workaround for lambda being ugly, I'd rather see a 
PEP that proposed "Let's make the syntax for deferring an expression not be 
ugly anymore, now that we have generator expressions and conditionals as an 
example of how to do it right".

Guido was rather unenthused the last time this topic came up, though, so maybe 
it isn't worth the effort. . . (although he did eventually change his mind on 
PEP 308, so I haven't entirely given up hope yet).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Octal literals

[Donovan Baarda]

On Wed, 2006-02-01 at 19:09 +, M J Fleming wrote:
> On Wed, Feb 01, 2006 at 01:35:14PM -0500, Barry Warsaw wrote:
> > The proposal for something like 0xff, 0o664, and 0b1001001 seems like
> > the right direction, although 'o' for octal literal looks kind of funky.
> > Maybe 'c' for oCtal?  (remember it's 'x' for heXadecimal).
> >
> > -Barry
> >
> 
> +1

+1 too. 

It seems like a "least changes" way to fix the IMHO strange 0123 != 123
behaviour. 

Any sort of arbitrary base syntax is overkill; decimal, hexadecimal,
octal, and binary cover 99.9% of cases. The 0.1% of other cases are very
special, and can use int("LITERAL",base=RADIX).

For me, binary is far more useful than octal, so I'd be happy to let
octal languish as legacy support, but I definitely want "0b10110101".

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

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

Re: [Python-Dev] Octal literals

[Nick Coghlan]

Bob Ippolito wrote:
> 
> On Feb 3, 2006, at 2:07 AM, Nick Coghlan wrote:
>> Currently, there is no syntax for binary literals, and the syntax for 
>> octal
>> literals is both magical (where else in integer mathematics does a 
>> leading
>> zero matter?) and somewhat error prone (int and eval will give different
>> answers for a numeric literal with a leading zero - int ignores the 
>> leading
>> zero, eval treats it as signifying that the value is in octal. The 
>> charming
>> result is that the following statement fails: assert int('0123') == 
>> 0123).
> 
> That's just a misunderstanding on your part.  The default radix is 10, 
> not DWIM.  0 signifies that behavior::
> 
> assert int('0123', 0) == 0123
> assert int('0x123', 0) == 0x123

How does that make the situation any better? The fact remains that a leading 
zero on an integer string may be significant, depending on the exact method 
used to convert the string to a number. The fact that int() can be made to 
behave like eval() doesn't change the fact that the default behaviours are 
different, and in a fashion that allows errors to pass silently.

You've highlighted a nice way to turn this into a real bug, though - use the 
DWIM feature of int() to accept numbers in either decimal or hex, and wait 
until someone relying on the mathematics they learned in high school enters a 
decimal number with a leading zero (leading zeros don't matter, right?).

I think it's a bad thing that Python defaults to handling numbers differently 
from high school mathematics. One of the virtues of '0x' and '0o' is that the 
resulting strings aren't actually legal numbers, leading to people wondering 
what the prefixes mean. The danger of the leading 0 denoting octal is that 
programmers without a background in C (or one of its successors that use the 
same convention) may *think* they know what it means, only to discover they're 
wrong the hard way (when their program doesn't work right).

Do I think this *really* matters? Nope - I think most bugs due to this will be 
pretty shallow. That's why I was only +0 on doing anything about it.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] syntactic support for sets

[Donovan Baarda]

On Wed, 2006-02-01 at 13:55 -0500, Greg Wilson wrote:
> Hi,
> 
> I have a student who may be interested in adding syntactic support for
> sets to Python, so that:
> 
> x = {1, 2, 3, 4, 5}
> 
> and:
> 
> y = {z for z in x if (z % 2)}

Personally I'd like this. currently the "set(...)"  syntax makes sets
feel tacked on compared to tuples, lists, dicts, and strings which have
nice built in syntax support. Many people don't realise they are there
because of this.

Before set() the standard way to do them was to use dicts with None
Values... to me the "{1,2,3}" syntax would have been a logical extension
of the "a set is a dict with no values, only keys" mindset. I don't know
why it wasn't done this way in the first place, though I missed the
arguments where it was rejected.

As for frozenset vs set, I would be inclined to make them normal mutable
sets. This is in line with the "dict without values" idea.

Frozensets are to sets what tuples are to lists. It would be nice if
there was another type of bracket that could be used for frozenset...
something like ':1,2,3:'... yuk... I dunno.

Alternatively you could to the same thing we do with strings; add a
prefix char for different variants; {1,2,3} is a set, f{1,2,3} is a
frozen set...

For Python 3000 you could extend this approach to lists and dicts;
[1,2,3] is a list, f[1,2,3] is a "frozen list" or tuple, {1:'a',2:'b'}
is a dict, f{1:'a',2:'b'} is a "frozen dict" which can be used as a key
in other dicts... etc.

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

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

Re: [Python-Dev] syntactic support for sets

[Fredrik Lundh]

Donovan Baarda wrote:

> For Python 3000 you could extend this approach to lists and dicts;
> [1,2,3] is a list, f[1,2,3] is a "frozen list" or tuple, {1:'a',2:'b'}
> is a dict, f{1:'a',2:'b'} is a "frozen dict" which can be used as a key
> in other dicts... etc.

Traceback (most recent call last):
  File "pythondev.py", line 219, in monitor
HyperGeneralizationViolationError: please let your brain cool down before 
proceeding




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

Re: [Python-Dev] any support for a methodcaller HOF?

[Alex Martelli]

On Feb 3, 2006, at 1:36 AM, Michael Hudson wrote:

> Alex Martelli <[EMAIL PROTECTED]> writes:
>
>> I was recently reviewing a lot of the Python 2.4 code I have written,
>> and I've noticed one thing: thanks to the attrgetter and itemgetter
>> functions in module operator, I've been using (or been tempted to  
>> use)
>> far fewer lambdas, particularly but not exclusively in key= arguments
>> to sort and sorted.
>
> Interesting.  Something I'd noticed was that *until* the key= argument
> to sort appeared, I was hardly using any lambdas at all (most of the
> places I had used them were rendered obsolete by list comprehensions).

Mine too, but many new places appeared, especially in itertools.

> A class I wrote (and lost) ages ago was a "placeholder" class, so if
> 'X' was an instance of this class, "X + 1" was roughly equivalent to
> "lambda x:x+1" and "X.method(zip, zop)" was roughly equivalent to your
> "methodcaller("method", zip, zop)".  I threw it away when listcomps
> got implemented.  Not sure why I mention it now, something about your
> post made me think of it...

Such a placeholder would certainly offer better syntax and more power  
than methodcaller (and itemgetter and attrgetter, too).  A lovely idea!


Alex

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Giovanni Bajo]

Nick Coghlan <[EMAIL PROTECTED]> wrote:

> Consider these comparisons:
>
>itemgetter(1) <=> (x[1] def (x))
>attrgetter('foo') <=> (x.foo def (x))
>partial(y, arg)   <=> (y(arg) def)
>
> So rather than yet another workaround for lambda being ugly, I'd rather
see
> a PEP that proposed "Let's make the syntax for deferring an expression not
> be ugly anymore, now that we have generator expressions and conditionals
as
> an example of how to do it right".

+1000. Instead of keep on adding arcane functions which return objects which
(when called) do things not obvious if not by knowing the function
beforehand, a generic syntax should be added for deferred execution. I too
use itemgetter and friends but the "correct" way of doing a defferred "x[1]"
*should* let you write "x[1]" in the code. This is my main opposition to
partial/itemgetter/attrgetter/methodcaller: they allow deferred execution
using a syntax which is not equivalent to that of immediate execution.
Unless we propose to deprecate "x[1]" in favor of "itemgetter(1)(x)"...
-- 
Giovanni Bajo

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Alex Martelli]

On Feb 3, 2006, at 6:47 AM, Giovanni Bajo wrote:
...
> use itemgetter and friends but the "correct" way of doing a  
> defferred "x[1]"
> *should* let you write "x[1]" in the code. This is my main  
> opposition to
> partial/itemgetter/attrgetter/methodcaller: they allow deferred  
> execution
> using a syntax which is not equivalent to that of immediate execution.

I understand your worry re the syntax issue.  So what about Michael  
Hudson's "placeholder class" idea, where X[1] returns the callable  
that will do x[1] when called, etc?  Looks elegant to me...


Alex

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Bengt Richter]

On Fri, 03 Feb 2006 20:44:47 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:

>Michael Hudson wrote:
>> Alex Martelli <[EMAIL PROTECTED]> writes:
>>> I'll be glad to write a PEP, but I first want to check whether the
>>> Python-Dev crowd would just blast it out of the waters, in which case
>>> I may save writing it...
>> 
>> Hmm.
>> 
> funcTakingCallback(lamda x:x.method(zip, zop))
> funcTakingCallback(methodcaller("method", zip, zop))
>> 
>> I'm not sure which of these is clearer really.  Are lambdas so bad?
>> (FWIW, I haven't internalized itemgetter/attrgetter yet and still tend
>> to use lambdas instead those too).
If you are familiar with lambda, it's clearer, because the expression
evaluation is just deferred, and you can see that zip and zop are going
to be accessed at lambda call time. methodcaller could potentially hide
an alternate binding of zip and zop like lambda x, zip=zip, 
zop=zop:x.method(zip,zop)
So you have to know what methodcaller does rather than just reading the 
expression.
And if you want to customize with def-time (lambda eval time) bindings as well 
as
call arg bindings, you can't easily AFAICS.

BTW, re def-time bindings, the default arg abuse is a hack, so I would like to
see a syntax that would permit default-arg-like def-time function-local 
bindings without
affecting the call signature. E.g., if def foo(*args, **keywords, ***bindings): 
...
would use bindings as a dict at def-time to create local namespace bindings 
like **keywords,
but not affecting the call signature. This would allow a nicer version of 
above-mentioned
   lambda x, zip=zip, zop=zop:x.method(zip,zop)
as
   lambda x, ***dict(zip=zip, zop=zop):x.method(zip,zop)
or
   lambda x, ***{'zip':zip, 'zop':zop}:x.method(zip,zop)
This could also be used to do currying without the typical cost of wrapped 
nested calling.

>
>I've been convinced for a while that the proliferation of features like 
>operator.itemgetter and attrgetter (and some uses of functional.partial) 
>demonstrate that the ability to defer a single expression (as lambda currently 
>allows) is a very useful feature to have in the language. Unfortunately that
note that "deferring" is a particular case of controlling evaluation time.
The other direction in time goes towards reader macros & such.
>utility gets overshadowed by the ugliness of the syntax, the mathematical 
>baggage associated with the current keyword, and the fact that lambda gets 
>pitched as an "anonymous function limited to a single expression", rather than 
>as "the ability to defer an expression for later evaluation" (the former 
>sounds like a limitation that should be fixed, the latter sounds like the 
>deliberate design choice that it is).
>
>At the moment it looks like the baby is going to get thrown out with the 
>bathwater in Py3k, but I'd love to be able to simply write the following 
>instead of some byzantine mixture of function calls to get the same effect:
>
> funcTakingCallback(x.method(zip, zop) def (x))
>
>Consider these comparisons:
>
This looks a lot like the "anonymous def" expression in a postfix form ;-)
>   itemgetter(1) <=> (x[1] def (x))
  <=> def(x):x[1]
>   attrgetter('foo') <=> (x.foo def (x))
  <=> def(x):x.foo
>   partial(y, arg)   <=> (y(arg) def)
  <=> def(***{'arg':arg}):y()  # ?? (not sure about 
semantics of partial)
>
>So rather than yet another workaround for lambda being ugly, I'd rather see a 
>PEP that proposed "Let's make the syntax for deferring an expression not be 
>ugly anymore, now that we have generator expressions and conditionals as an 
>example of how to do it right".
I guess you can guess my vote is for anonymous def ;-)
>
>Guido was rather unenthused the last time this topic came up, though, so maybe 
>it isn't worth the effort. . . (although he did eventually change his mind on 
>PEP 308, so I haven't entirely given up hope yet).
Likewise ;-)

Regards,
Bengt Richter

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

Re: [Python-Dev] syntactic support for sets

[Donovan Baarda]

On Fri, 2006-02-03 at 12:04 +, Donovan Baarda wrote:
> On Wed, 2006-02-01 at 13:55 -0500, Greg Wilson wrote:
[...]
> Personally I'd like this. currently the "set(...)"  syntax makes sets
> feel tacked on compared to tuples, lists, dicts, and strings which have
> nice built in syntax support. Many people don't realise they are there
> because of this.
[...]
> Frozensets are to sets what tuples are to lists. It would be nice if
> there was another type of bracket that could be used for frozenset...
> something like ':1,2,3:'... yuk... I dunno.

One possible bracket option for frozenset would be "<1,2,3>" which I
initially rejected because of the possible syntactic clash with the <
and > operators... however, there may be a way this could work... dunno.

The other thing that keeps nagging me is set, frozenset, tuple, and list
all overlap in functionality to fairly significant degrees. Sometimes it
feels like just implementation or application differences... could a
list that is never modified be optimised under the hood as a tuple?
Could the immutability constraint of tuples be just acquired by a list
when it is used as a key? Could a set simply be a list with unique
values? etc.

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Jean-Paul Calderone]

On Fri, 3 Feb 2006 07:00:26 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>On Feb 3, 2006, at 6:47 AM, Giovanni Bajo wrote:
>...
>> use itemgetter and friends but the "correct" way of doing a
>> defferred "x[1]"
>> *should* let you write "x[1]" in the code. This is my main
>> opposition to
>> partial/itemgetter/attrgetter/methodcaller: they allow deferred
>> execution
>> using a syntax which is not equivalent to that of immediate execution.
>
>I understand your worry re the syntax issue.  So what about Michael
>Hudson's "placeholder class" idea, where X[1] returns the callable
>that will do x[1] when called, etc?  Looks elegant to me...
>

FWIW,




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

Re: [Python-Dev] any support for a methodcaller HOF?

[Giovanni Bajo]

Alex Martelli <[EMAIL PROTECTED]> wrote:

>> use itemgetter and friends but the "correct" way of doing a
>> defferred "x[1]"
>> *should* let you write "x[1]" in the code. This is my main
>> opposition to
>> partial/itemgetter/attrgetter/methodcaller: they allow deferred
>> execution
>> using a syntax which is not equivalent to that of immediate execution.
>
> I understand your worry re the syntax issue.  So what about Michael
> Hudson's "placeholder class" idea, where X[1] returns the callable
> that will do x[1] when called, etc?  Looks elegant to me...

Depends on how the final API looks like. "deffered(x)[1]" isn't that bad,
but "def x: x[1]" still looks clearer as the 'def' keyword immediatly makes
clear you're DEFining a DEFerred function  :) Of course we can paint our
bikeshed of whatever color we like, but I'm happy enough if we agree with
the general idea of keeping the same syntax in both deferred and immediate
execution.

There is an also an issue with deferred execution without arguments. By
grepping my code it turned out that many lambda instances are in calls to
assertRaises() (unittest), where I stricly prefer the syntax:

self.assertRaises(TypeError, lambda: int("ABK", 16))

to the allowed:

self.assertRaises(TypeError, int, "ABK", 16)

With the inline def proposal we'd get something along the lines of:

self.assertRaises(TypeError, def(): int("ABK", 16))
self.assertRaises(TypeError, (int("ABK", 16) def))   # it's not lisp,
really, I swear

while I'm not sure how this would get with the placeholder class.
-- 
Giovanni Bajo

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Hye-Shik Chang]

On 2/4/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Fri, 3 Feb 2006 07:00:26 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
> >
> >I understand your worry re the syntax issue.  So what about Michael
> >Hudson's "placeholder class" idea, where X[1] returns the callable
> >that will do x[1] when called, etc?  Looks elegant to me...
> >
>
> FWIW,
>
> 
> 
>

Yet another implementation,

http://mail.python.org/pipermail/python-announce-list/2004-January/002801.html

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

Re: [Python-Dev] syntactic support for sets

[Josiah Carlson]

Donovan Baarda <[EMAIL PROTECTED]> wrote:
> 
> On Wed, 2006-02-01 at 13:55 -0500, Greg Wilson wrote:
> > Hi,
> > 
> > I have a student who may be interested in adding syntactic support for
> > sets to Python, so that:
> > 
> > x = {1, 2, 3, 4, 5}
> > 
> > and:
> > 
> > y = {z for z in x if (z % 2)}
> 
> Personally I'd like this. currently the "set(...)"  syntax makes sets
> feel tacked on compared to tuples, lists, dicts, and strings which have
> nice built in syntax support. Many people don't realise they are there
> because of this.

Sets are tacked on.  That's why you need to use 'import sets' to get to
them, in a similar fashion that you need to use 'import array' to get
access to C-like arrays.

People don't realize that sets are there because they tend to not read
the "what's new in Python X.Y", and also fail to read through the
"global module index" every once and a while.

I personally object to making syntax for sets for the same reasons I
object to making arrays, heapqs, Queues, deques, or any of the other
data structure-defining modules in the standard library into syntax.

 - Josiah

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

Re: [Python-Dev] syntactic support for sets

[Donovan Baarda]

On Fri, 2006-02-03 at 09:00 -0800, Josiah Carlson wrote:
[...]
> Sets are tacked on.  That's why you need to use 'import sets' to get to
> them, in a similar fashion that you need to use 'import array' to get
> access to C-like arrays.

No you don't;

$ python
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> v=set((1,2,3))
>>> f=frozenset(v)
>>>

set and frozenset are now builtin.

> I personally object to making syntax for sets for the same reasons I
> object to making arrays, heapqs, Queues, deques, or any of the other
> data structure-defining modules in the standard library into syntax.

Nuff was a fairy... though I guess it depends on where you draw the
line; should [1,2,3] be list(1,2,3)?

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Michael Hudson]

Jean-Paul Calderone <[EMAIL PROTECTED]> writes:

> On Fri, 3 Feb 2006 07:00:26 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>
>>On Feb 3, 2006, at 6:47 AM, Giovanni Bajo wrote:
>>...
>>> use itemgetter and friends but the "correct" way of doing a
>>> defferred "x[1]"
>>> *should* let you write "x[1]" in the code. This is my main
>>> opposition to
>>> partial/itemgetter/attrgetter/methodcaller: they allow deferred
>>> execution
>>> using a syntax which is not equivalent to that of immediate execution.
>>
>>I understand your worry re the syntax issue.  So what about Michael
>>Hudson's "placeholder class" idea, where X[1] returns the callable
>>that will do x[1] when called, etc?  Looks elegant to me...

I'd just like to point out here that I only mentioned this class; I
didn't suggest it for anything :)

> FWIW,
>
> 
> 

Yow.  My implementation was somewhere in between those for length, I
think (and pre-dated new style classes, which probably changes
things).

Cheers,
mwh

-- 
  I'm sorry, was my bias showing again? :-)
  -- William Tanksley, 13 May 2000
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] any support for a methodcaller HOF?

[Georg Brandl]

Alex Martelli wrote:

>> A class I wrote (and lost) ages ago was a "placeholder" class, so if
>> 'X' was an instance of this class, "X + 1" was roughly equivalent to
>> "lambda x:x+1" and "X.method(zip, zop)" was roughly equivalent to your
>> "methodcaller("method", zip, zop)".  I threw it away when listcomps
>> got implemented.  Not sure why I mention it now, something about your
>> post made me think of it...
> 
> Such a placeholder would certainly offer better syntax and more power  
> than methodcaller (and itemgetter and attrgetter, too).  A lovely idea!

Yep. And it would make Python stand out of the crowd another time ;)

The question is: is it "serious" and deterministic enough to be builtin?

Georg

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Bengt Richter]

On Thu, 2 Feb 2006 14:43:51 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:

>I was recently reviewing a lot of the Python 2.4 code I have written,
>and I've noticed one thing: thanks to the attrgetter and itemgetter
>functions in module operator, I've been using (or been tempted to use)
>far fewer lambdas, particularly but not exclusively in key= arguments
>to sort and sorted.  Most of those "lambda temptations" will be
>removed by PEP 309 (functional.partial), and most remaining ones are
>of the form:
>lambda x: x.amethod(zip, zop)
>
>So I was thinking -- wouldn't it be nice to have (possibly in module
>functional, like partial; possibly in module operator, like itemgetter
>and attrgetter -- I'm partial to functional;-) a methodcaller entry
>akin to (...possibly with a better name...):
>
>def methodcaller(methodname, *a, **k):
>def caller(self):
>getattr(self, methodname)(*a, **k)
>caller.__name__ = methodname
>return caller
>
>...?  This would allow removal of even more lambdas.
>
Yes, but what semantics do you really want? The above, as I'm sure you know, is
not a direct replacement for the lambda:

 >>> import dis
 >>> foo = lambda x: x.amethod(zip, zop)
 >>>
 >>> def methodcaller(methodname, *a, **k):
 ... def caller(self):
 ... getattr(self, methodname)(*a, **k)
 ... caller.__name__ = methodname
 ... return caller
 ...
 >>> bar = methodcaller('amethod', zip, zop)
 Traceback (most recent call last):
   File "", line 1, in ?
 NameError: name 'zop' is not defined
 >>> zop = 'must exist at methodcaller call time'
 >>> bar = methodcaller('amethod', zip, zop)
 >>> dis.dis(foo)
   1   0 LOAD_FAST0 (x)
   3 LOAD_ATTR1 (amethod)
   6 LOAD_GLOBAL  2 (zip)
   9 LOAD_GLOBAL  3 (zop)
  12 CALL_FUNCTION2
  15 RETURN_VALUE
 >>> dis.dis(bar)
   3   0 LOAD_GLOBAL  0 (getattr)
   3 LOAD_FAST0 (self)
   6 LOAD_DEREF   2 (methodname)
   9 CALL_FUNCTION2
  12 LOAD_DEREF   0 (a)
  15 LOAD_DEREF   1 (k)
  18 CALL_FUNCTION_VAR_KW 0
  21 POP_TOP
  22 LOAD_CONST   0 (None)
  25 RETURN_VALUE

>I'll be glad to write a PEP, but I first want to check whether the
>Python-Dev crowd would just blast it out of the waters, in which case
>I may save writing it...
-0 ;-)

Regards,
Bengt Richter

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Christian Tismer]

Bengt Richter wrote:

...

> BTW, re def-time bindings, the default arg abuse is a hack, so I would like to
> see a syntax that would permit default-arg-like def-time function-local 
> bindings without
> affecting the call signature. E.g., if def foo(*args, **keywords, 
> ***bindings): ...
> would use bindings as a dict at def-time to create local namespace bindings 
> like **keywords,
> but not affecting the call signature. This would allow a nicer version of 
> above-mentioned
>lambda x, zip=zip, zop=zop:x.method(zip,zop)
> as
>lambda x, ***dict(zip=zip, zop=zop):x.method(zip,zop)
> or
>lambda x, ***{'zip':zip, 'zop':zop}:x.method(zip,zop)
> This could also be used to do currying without the typical cost of wrapped 
> nested calling.

Just in case that you might be not aware of it (like I was):
lambda does support local scope, like here:

 >>> def locallambda(x, y):
... func = lambda: x+y
... return func
...
 >>> f=locallambda(2, 3)
 >>> f()
5
 >>>

ciao - chris

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Octal literals

[Martin v. Löwis]

Bengt Richter wrote:
> If you are looking at them in C code receiving them as args in a call,
> "treat them the same" would have to mean provide code to coerce long->int
> or reject it with an exception, IWT.

The typical way of processing incoming ints in C is through
PyArg_ParseTuple, which already has the code to coerce long->int
(which in turn may raise an exception for a range violation).

So for typical C code, 0x8004 is a perfect bit mask in Python 2.4.

> It's not a matter of "buggy" if you are trying to optimize.
> (I am aware of premature optimization issues, and IMO "strange"
> is in the eye of the beholder. What syntax would you suggest?

The question is: what is the problem you are trying to solve?
If it is "bit masks", then consider the problem solved already.

>>Same goes for code that says it takes a 32-bit bitfield argument but  
>>won't accept 0x8000.
> 
> If the bitfield is signed, it can't, unless you are glossing over
> an assumed coercion rule.

Just have a look at the 'k' specifier in PyArg_ParseTuple.

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

Re: [Python-Dev] syntactic support for sets

[Martin v. Löwis]

Donovan Baarda wrote:
> Before set() the standard way to do them was to use dicts with None
> Values... to me the "{1,2,3}" syntax would have been a logical extension
> of the "a set is a dict with no values, only keys" mindset. I don't know
> why it wasn't done this way in the first place, though I missed the
> arguments where it was rejected.

There might be many reasons; one obvious reason is that you can't spell
the empty set that way.

> Frozensets are to sets what tuples are to lists. It would be nice if
> there was another type of bracket that could be used for frozenset...
> something like ':1,2,3:'... yuk... I dunno.

Readability counts.

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Robert Brewer]

Giovanni Bajo wrote:
> Alex Martelli <[EMAIL PROTECTED]> wrote:
> > I understand your worry re the syntax issue.  So what about Michael
> > Hudson's "placeholder class" idea, where X[1] returns the callable
> > that will do x[1] when called, etc?  Looks elegant to me...
> 
> Depends on how the final API looks like. "deffered(x)[1]" 
> isn't that bad, but "def x: x[1]" still looks clearer as
> the 'def' keyword immediatly makes clear you're DEFining
> a DEFerred function  :) Of course we can paint our
> bikeshed of whatever color we like, but I'm happy enough if 
> we agree with the general idea of keeping the same syntax
> in both deferred and immediate execution.

I don't agree with that "general idea" at all. Sorry. ;) I think the
semantic emphasis should not be on "execution", but rather on
"expression". The word "execution" to me implies "statements", and
although some functions somewhere are called behind the scenes to
evaluate any expression, the lambda (and its potential successors)
differ from "def" by not allowing statements. They may be used to "defer
execution" but to me, their value lies in being static
expressions--object instances which are portable and introspectable.

This is where LINQ [1] is taking off: expressions are declared with
"var" (in C#). I used Expression() in Dejavu [2] for the same reasons
(before LINQ came along ;), and am using it to build SQL from Python
lambdas. I had to use lambda because that's Python's only builtin
support for expressions-as-objects at the moment, but I'd like to see
Python grow a syntax like:

e = expr(x: x + 1)

...where expr() does early binding like dejavu.logic does. [Looking back
over my logic module, I'm noticing it requires boolean return values,
but it would not be difficult to extend to return abitrary values--even
easier if it were rewritten as builtin functionality. Guess I need to
write myself another ticket. ;)]


Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]

[1] http://msdn.microsoft.com/netframework/future/linq/
[2] http://projects.amor.org/dejavu/browser/trunk/logic.py
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] any support for a methodcaller HOF?

[Giovanni Bajo]

Robert Brewer <[EMAIL PROTECTED]> wrote:


> The word "execution" to me implies "statements", and
> although some functions somewhere are called behind the scenes to
> evaluate any expression, the lambda (and its potential successors)
> differ from "def" by not allowing statements. They may be used to "defer
> execution" but to me, their value lies in being static
> expressions--object instances which are portable and introspectable.

> This is where LINQ [1] is taking off: expressions are declared with
> "var" (in C#). I used Expression() in Dejavu [2] for the same reasons
> (before LINQ came along ;), and am using it to build SQL from Python
> lambdas. I had to use lambda because that's Python's only builtin
> support for expressions-as-objects at the moment, but I'd like to see
> Python grow a syntax like:
>
> e = expr(x: x + 1)


I see what you mean, but in a way you're still agreeing with me :) Your
expression-as-objects proposal is very clever, but to me (and as far as this
thread is concerned) it still allows to write a "decorated" piece of code
(expression), pass it around, and execute (evaluate) it later. This is what
I (and others) mainly use lambda for, and your expr() thing would still
serve me well. Instead, itemgetter() and friends are going to a different
direction (the expression which is later evaluated is not clearly expressed
in familiar Python terms), and that's what I find inconvenient.
-- 
Giovanni Bajo

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

Re: [Python-Dev] syntactic support for sets

[Josiah Carlson]

Donovan Baarda <[EMAIL PROTECTED]> wrote:
> 
> On Fri, 2006-02-03 at 09:00 -0800, Josiah Carlson wrote:
> [...]
> > Sets are tacked on.  That's why you need to use 'import sets' to get to
> > them, in a similar fashion that you need to use 'import array' to get
> > access to C-like arrays.
> 
> No you don't;
> 
> $ python
> Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
> [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> v=set((1,2,3))
> >>> f=frozenset(v)
> >>>
> 
> set and frozenset are now builtin.

Indeed they are.  My apologies for being incorrect, I'm still using 2.3
for all of my commercial work.


> > I personally object to making syntax for sets for the same reasons I
> > object to making arrays, heapqs, Queues, deques, or any of the other
> > data structure-defining modules in the standard library into syntax.
> 
> Nuff was a fairy... though I guess it depends on where you draw the
> line; should [1,2,3] be list(1,2,3)?

Who is "Nuff"?

Along the lines of "not every x line function should be a builtin", "not
every builtin should have syntax".  I think that sets have particular
uses, but I don't believe those uses are sufficiently varied enough to
warrant the creation of a syntax.  I suggest that people take a walk
through their code. How often do you use other sequence and/or mapping
types? How many lists, tuples and dicts are there?  How many sets? Ok,
now how many set literals?

Syntax for sets is only really useful for the equivalent of a set
literal, and with minimal syntax for a set literal being some sort of
start and ending character pair, the only thing gained is a 3 key
reduction in the amount of typing necessary, and a possible compiler
optimization to call the set creation code instead of the local, global,
then builtin namespaces.

Essentially, I'm saying that "set(...)" isn't significantly worse than
"{...}" (or some other pair) for set creation.  One can say the same
thing about list(), tuple(), and dict(), but I think that their millions
of uses far overwhelms the minimal uses (and usage) of set(), and puts
them in a completely different class.


 - Josiah

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Bengt Richter]

On Fri, 03 Feb 2006 19:10:42 +0100, Christian Tismer <[EMAIL PROTECTED]> wrote:

>Bengt Richter wrote:
>
>...
>
>> BTW, re def-time bindings, the default arg abuse is a hack, so I would like 
>> to
>> see a syntax that would permit default-arg-like def-time function-local 
>> bindings without
>> affecting the call signature. E.g., if def foo(*args, **keywords, 
>> ***bindings): ...
>> would use bindings as a dict at def-time to create local namespace bindings 
>> like **keywords,
>> but not affecting the call signature. This would allow a nicer version of 
>> above-mentioned
>>lambda x, zip=zip, zop=zop:x.method(zip,zop)
>> as
>>lambda x, ***dict(zip=zip, zop=zop):x.method(zip,zop)
>> or
>>lambda x, ***{'zip':zip, 'zop':zop}:x.method(zip,zop)
>> This could also be used to do currying without the typical cost of wrapped 
>> nested calling.
>
>Just in case that you might be not aware of it (like I was):
>lambda does support local scope, like here:
>
> >>> def locallambda(x, y):
>...func = lambda: x+y
>...return func
>...
> >>> f=locallambda(2, 3)
> >>> f()
>5
Yes, thanks, I really did know that ;-/ Just got thinking along another line. So
lambda x, zip=zip, zop=zop:x.method(zip,zop)
and
lambda x, ***{'zip':zip, 'zop':zop}:x.method(zip,zop)
would better have been
(lambda zip,zop:lambda x:x.method(zip,zop))(zip, zop)

Regards,
Bengt Richter

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

Re: [Python-Dev] Octal literals

[Bengt Richter]

On Fri, 03 Feb 2006 19:56:20 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= 
<[EMAIL PROTECTED]> wrote:

>Bengt Richter wrote:
>> If you are looking at them in C code receiving them as args in a call,
>> "treat them the same" would have to mean provide code to coerce long->int
>> or reject it with an exception, IWT.
>
>The typical way of processing incoming ints in C is through
>PyArg_ParseTuple, which already has the code to coerce long->int
>(which in turn may raise an exception for a range violation).
>
>So for typical C code, 0x8004 is a perfect bit mask in Python 2.4.
Ok, I'll take your word that 'k' coercion takes no significant time for longs 
vs ints.
I thought there might be a case in a hot loop where it could make a difference.
I confess not having done a C extension since I wrote one to access RDTSC quite 
some time ago.

>
>> It's not a matter of "buggy" if you are trying to optimize.
>> (I am aware of premature optimization issues, and IMO "strange"
>> is in the eye of the beholder. What syntax would you suggest?
>
>The question is: what is the problem you are trying to solve?
>If it is "bit masks", then consider the problem solved already.
Well, I was visualizing having a homogeneous bunch of bit mask
definitions all as int type if they could fit. I can't express
them all in hex as literals without some processing. That got me started ;-)
Not that some one-time processing at module import time is a big deal.
Just that it struck me as a wart not to be able to do it without processing,
even if constant folding is on the way.

>
>>>Same goes for code that says it takes a 32-bit bitfield argument but  
>>>won't accept 0x8000.
>> 
>> If the bitfield is signed, it can't, unless you are glossing over
>> an assumed coercion rule.
>
>Just have a look at the 'k' specifier in PyArg_ParseTuple.
Ok, well that's the provision for the coercion then.
BTW, is long mandatory for all implementations? Is there a doc that
defines minimum features for a conforming Python implementation?
E.g., IIRC Scheme has a list naming what's optional and not.

Regards,
Bengt Richter

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Brett Cannon]

On 2/3/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
> > Alex Martelli <[EMAIL PROTECTED]> wrote:
> > > I understand your worry re the syntax issue.  So what about Michael
> > > Hudson's "placeholder class" idea, where X[1] returns the callable
> > > that will do x[1] when called, etc?  Looks elegant to me...
> >
> > Depends on how the final API looks like. "deffered(x)[1]"
> > isn't that bad, but "def x: x[1]" still looks clearer as
> > the 'def' keyword immediatly makes clear you're DEFining
> > a DEFerred function  :) Of course we can paint our
> > bikeshed of whatever color we like, but I'm happy enough if
> > we agree with the general idea of keeping the same syntax
> > in both deferred and immediate execution.
>
> I don't agree with that "general idea" at all. Sorry. ;) I think the
> semantic emphasis should not be on "execution", but rather on
> "expression". The word "execution" to me implies "statements", and
> although some functions somewhere are called behind the scenes to
> evaluate any expression, the lambda (and its potential successors)
> differ from "def" by not allowing statements. They may be used to "defer
> execution" but to me, their value lies in being static
> expressions--object instances which are portable and introspectable.
>
> This is where LINQ [1] is taking off: expressions are declared with
> "var" (in C#). I used Expression() in Dejavu [2] for the same reasons
> (before LINQ came along ;), and am using it to build SQL from Python
> lambdas. I had to use lambda because that's Python's only builtin
> support for expressions-as-objects at the moment, but I'd like to see
> Python grow a syntax like:
>
> e = expr(x: x + 1)
>
> ...where expr() does early binding like dejavu.logic does. [Looking back
> over my logic module, I'm noticing it requires boolean return values,
> but it would not be difficult to extend to return abitrary values--even
> easier if it were rewritten as builtin functionality. Guess I need to
> write myself another ticket. ;)]
>

Well, maybe what we really want is lambda but under a different name. 
``expr x: x + 1`` seems fine to me and it doesn't have the issue of
portraying Python has having a crippled lambda expression.  I do think
that a general solution can be found that can allow us to do away with
itemgetter, itergetter, and Alex's methodcaller (something like
Michael's Placeholder class).

The problem is when we want deferred arguments to a function call.  We
have functional.partial, but it can't do something like ``lambda x:
func(1, 2, x, 4, 5)`` unless everything is turned to keyword arguments
but that doesn't work when something only take positional arguments. 
This does not seem to have a good solution outside of lambda in terms
of non-function definition.

But then again small functions can be defined for those situations. 
So I think that functional.partial along with some deferred object
implementation should deal with most uses of lambda and then allow us
to use custom functions to handle all the other cases of when we would
want lambda.

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Nick Coghlan]

Bengt Richter wrote:
> On Fri, 03 Feb 2006 20:44:47 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> funcTakingCallback(x.method(zip, zop) def (x))
>>
>> Consider these comparisons:
>>
> This looks a lot like the "anonymous def" expression in a postfix form ;-)

If you think about the way a for-loop statement maps to the looping portion of 
a listcomp or genexp, or the way an if statement maps to a conditional 
expression, you might notice that this is *not* a coincidence :)

   def g(_seq):
 for x in _seq:
   yield x*x
   g = g(seq)

=> g = (x*x for x in seq)


   l = []
   for x in seq:
 l.append(x*x)

=> l = [x*x for x in seq]

   if cond:
 val = x
   else:
 val = y

=> val = x if cond else y


In all three of the recent cases where a particular usage of a statement has 
been converted to an expression, the variable portion of the innermost part of 
the the first suite is pulled up and placed to the left of the normal 
statement keyword. A bracketing syntax is used when the expression creates a 
new object. All I'm suggesting is that a similarly inspired syntax is worth 
considering when it comes to deferred expressions:

   def f(x):
 return x*x

=> f = (x*x def (x))

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] any support for a methodcaller HOF?

[Eric Nieuwland]

On 4 feb 2006, at 3:18, Nick Coghlan wrote:
> All I'm suggesting is that a similarly inspired syntax is worth
> considering when it comes to deferred expressions:
>
>def f(x):
>  return x*x
>
> => f = (x*x def (x))

It's not the same, as x remains free whereas in g = [x*x for x in seq] 
x is bound.

Yours is

f = lambda x: x*x

and it will die by Guido hand...
--eric

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

Re: [Python-Dev] any support for a methodcaller HOF?

[Nick Coghlan]

Eric Nieuwland wrote:
> On 4 feb 2006, at 3:18, Nick Coghlan wrote:
>> All I'm suggesting is that a similarly inspired syntax is worth
>> considering when it comes to deferred expressions:
>>
>>def f(x):
>>  return x*x
>>
>> => f = (x*x def (x))
> 
> It's not the same, as x remains free whereas in g = [x*x for x in seq] x 
> is bound.

That's like saying "it's not the same because '(x*x def (x)' creates a 
function while '(x*x for x in seq)' creates a generator-iterator". Well, 
naturally - if the expression didn't do something different, what would be the 
point in having it?

The parallel I'm trying to draw is at the syntactic level, not the semantic. 
I'm quite aware that the semantics will be very different ;)

> Yours is
> 
> f = lambda x: x*x
> 
> and it will die by Guido hand...

In the short term, probably. I'm hoping that the progressive accumulation of 
workarounds like itemgetter, attrgetter and partial (and Alex's suggestion of 
'methodcaller') and the increasing use of function arguments for things like 
sorting and the itertools module will eventually convince Guido that deferring 
expressions is a feature that needs to be *fixed* rather than discarded 
entirely.

But until the BDFL is willing to at least entertain the notion of fixing 
deferred expressions rather than getting ridding of them, there isn't much 
point in writing a PEP or a patch to tweak the parser (with the AST in place, 
this is purely a change to the parser front-end - the AST and code generation 
back end don't need to be touched).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] syntactic support for sets

[Greg Wilson]

> > > Raymond:
> > > Accordingly,Guido rejected the braced notation for set comprehensions.
> > > See:  http://www.python.org/peps/pep-0218.html

> > Greg:
> > "...however, the issue could be revisited for Python 3000 (see PEP 3000)."
> > So I'm only 1994 years early ;-)

> Alex:
> Don't be such a pessimist, it's ONLY 994 years to go!

Greg:
I was allowing for likely schedule slippage... ;-)

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

[Python-Dev] Path PEP and the division operator

[Nick Coghlan]

I was tinkering with something today, and wondered whether it would cause 
fewer objections if the PEP used the floor division operator (//) to combine 
path fragments, instead of the true division operator?

The parallel to directory separators is still there, but the syntax isn't tied 
quite so strongly to the Unix path separator.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com