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 s
> > > 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
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 whe
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 i
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 fo
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 cal
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 wi
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
>> af
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
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
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 fina
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
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 alrea
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
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
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 whe
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 wr
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:1
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
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[
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 synt
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
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. Ma
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
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
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
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
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):
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(...)" synta
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
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? (rem
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
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 st
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 y
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 g
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
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) immed
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
>> function
38 matches
Mail list logo
