Bengt Richter wrote:
>OTOH, there is precedent in e.g. fortran (IIRC) for named operators of
the
>form .XX. -- e.g., .GE. for >= so maybe there could be room for both.
Yes, but in Fortran 90 "==", ">=" etc. are equivalent to ".EQ." and
".GE.". It is also possible to define operators on native an
On Sat, 08 Jan 2005 18:22:53 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> IOW, I think there is a fix: keep tokenizing greedily and tokenize floating
>> point as
>> a sequence of integers and operators, and let be
>> translated by
>> the compiler to floating point, an
Bengt Richter wrote:
IOW, I think there is a fix: keep tokenizing greedily and tokenize floating
point as
a sequence of integers and operators, and let be
translated by
the compiler to floating point, and be translated to
the
appropriate generator expression implementation.
That would be:
->
On Fri, 07 Jan 2005 06:04:01 GMT, Andrew Dalke <[EMAIL PROTECTED]> wrote:
>Bengt Richter:
>> But it does look ahead to recognize += (i.e., it doesn't generate two
>> successive also-legal tokens of '+' and '=')
>> so it seems it should be a simple fix.
>
>But that works precisely because of the gr
Andrew Dalke wrote:
Bengt Richter:
But it does look ahead to recognize += (i.e., it doesn't generate two
successive also-legal tokens of '+' and '=')
so it seems it should be a simple fix.
But that works precisely because of the greedy nature of tokenization.
Given "a+=2" the longest token it find
Bengt Richter:
> But it does look ahead to recognize += (i.e., it doesn't generate two
> successive also-legal tokens of '+' and '=')
> so it seems it should be a simple fix.
But that works precisely because of the greedy nature of tokenization.
Given "a+=2" the longest token it finds first is "a"
On Thu, 06 Jan 2005 19:24:52 GMT, Andrew Dalke <[EMAIL PROTECTED]> wrote:
>Me
> (BTW, it needs to be 1 .. 12 not 1..12 because 1. will be interpreted
> as the floating point value "1.0".)<
>
>Steve Holden:
>> Indeed, but if ".." is defined as an acceptable token then there's
>> nothing to
Me
(BTW, it needs to be 1 .. 12 not 1..12 because 1. will be interpreted
as the floating point value "1.0".)<
Steve Holden:
> Indeed, but if ".." is defined as an acceptable token then there's
> nothing to stop a strict LL(1) parser from disambiguating the cases in
> question. "Token"
Timo Virkkala wrote:
[EMAIL PROTECTED] wrote:
Andrew Dalke:
(BTW, it needs to be 1 .. 12 not 1..12 because 1. will be interpreted
as the floating point value "1.0".)<
Uhm, I have to fix my ignorance about parsers.
Cannot a second "." after the first tell that the first "." isn't in
the middle of a
[EMAIL PROTECTED] wrote:
Andrew Dalke:
(BTW, it needs to be 1 .. 12 not 1..12 because 1. will be interpreted
as the floating point value "1.0".)<
Uhm, I have to fix my ignorance about parsers.
Cannot a second "." after the first tell that the first "." isn't in
the middle of a floating point number
Thank you to all the gentle people that has given me some comments, and
sorry for bothering you...
Doug Holton:
>This will also likely never appear in Python.
I know, that's why I've defined it "wild".
>Also, you might request the NetLogo and StarLogo developers to support
Jython (in addition
On Thu, 30 Dec 2004 15:16:42 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>Jp Calderone <[EMAIL PROTECTED]> writes:
>
> > On Wed, 29 Dec 2004 12:38:02 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
> >>Jp Calderone <[EMAIL PROTECTED]> writes:
> >> > This aside, not even Python 3.0 will be flexible
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> "Mike Meyer" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Steve Holden <[EMAIL PROTECTED]> writes:
>>> Well, perhaps you can explain how a change that's made at run time
>>> (calling the decorator) can affect the parser's compile tim
Steve Holden <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>
>> Steve Holden <[EMAIL PROTECTED]> writes:
>>
> [...]
>>>
>>>Well, perhaps you can explain how a change that's made at run time
>>>(calling the decorator) can affect the parser's compile time behavior,
>>>then. At the moment, IIRC, th
Jp Calderone <[EMAIL PROTECTED]> writes:
> On Wed, 29 Dec 2004 12:38:02 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>>Jp Calderone <[EMAIL PROTECTED]> writes:
>> > This aside, not even Python 3.0 will be flexible enough to let you define
>> > an infix decorator. The language developers are str
Bengt Richter wrote:
On Wed, 29 Dec 2004 13:11:43 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
[...]
Well, perhaps you can explain how a change that's made at run time
(calling the decorator) can affect the parser's compile time behavior,
then. At the moment, IIRC, the only way Python code can
On Thu, 30 Dec 2004 04:46:25 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote:
[...]
>Ok, well, that's happened to me before ;-)
>We'll have to find a way to make it illegal, but it's not likely to be quite
>as clean.
>
>x ..OP y
>x ./OP y
>x .x .. y
>X ._OP_. y
Bzzzt! ;-/
>x
On Thu, 30 Dec 2004 03:55:12 GMT, [EMAIL PROTECTED] (Bengt Richter) wrote:
[.. buncha stuff alzheimersly based on x.attr not being parsed as
x.attr ;-/ ]
> from rational import rat as RAT
>
> if x .RAT. y > 1 .RAT. 3: do_it()
>
>or
> your turn ;-)
>
Andrew got there first ;-)
Still, see my
On Thu, 30 Dec 2004 03:37:38 GMT, Andrew Dalke <[EMAIL PROTECTED]> wrote:
>Bengt Richter:
>> OTOH, there is precedent in e.g. fortran (IIRC) for named operators of the
>> form .XX. -- e.g., .GE. for >= so maybe there could be room for both.
>
>> Hm, you could make
>>
>> x .infix. y
>
>
>>
On Wed, 29 Dec 2004 13:11:43 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>Mike Meyer wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>
>>>@infix
>>>def interval(x, y): return range(x, y+1) # 2 parameters needed
>>>
>>>This may allow:
>>>assert 5 interval 9 == interval(5,9)
>>
>>
>> I don't like t
Bengt Richter:
> OTOH, there is precedent in e.g. fortran (IIRC) for named operators of the
> form .XX. -- e.g., .GE. for >= so maybe there could be room for both.
> Hm, you could make
>
> x .infix. y
> x .op1. y .op2. z => op2(op1(x, y), z)
The problem being that that's already legal s
On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
>
>> @infix
>> def interval(x, y): return range(x, y+1) # 2 parameters needed
>>
>> This may allow:
>> assert 5 interval 9 == interval(5,9)
>
>I don't like the idea of turning words into operators.
"Mike Meyer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Steve Holden <[EMAIL PROTECTED]> writes:
>> Well, perhaps you can explain how a change that's made at run time
>> (calling the decorator) can affect the parser's compile time behavior,
>> then. At the moment, IIRC, the onl
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'll second that. Please, "Bearophile", do us the courtesy of checking
>
> (1) Google groups archive of the mailing list:
> http://groups-beta.google.com/group/comp.lang.python
>
> and
>
> (2) The Python Enhancement P
Mike Meyer wrote:
Steve Holden <[EMAIL PROTECTED]> writes:
[...]
Well, perhaps you can explain how a change that's made at run time
(calling the decorator) can affect the parser's compile time behavior,
then. At the moment, IIRC, the only way Python code can affect the
parser's behavior is in the _
On Wed, 29 Dec 2004 12:38:02 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>Jp Calderone <[EMAIL PROTECTED]> writes:
>
> > On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
> >>[EMAIL PROTECTED] writes:
> >>
> >> > @infix
> >> > def interval(x, y): return range(x, y+1) # 2
Steve Holden <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
>
>> [EMAIL PROTECTED] writes:
>>
>>>@infix
>>>def interval(x, y): return range(x, y+1) # 2 parameters needed
>>>
>>>This may allow:
>>>assert 5 interval 9 == interval(5,9)
>> I don't like the idea of turning words into operators. I'd mu
Jp Calderone <[EMAIL PROTECTED]> writes:
> On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] writes:
>>
>> > @infix
>> > def interval(x, y): return range(x, y+1) # 2 parameters needed
>> >
>> > This may allow:
>> > assert 5 interval 9 == interval(5,9)
>
On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
>
> > @infix
> > def interval(x, y): return range(x, y+1) # 2 parameters needed
> >
> > This may allow:
> > assert 5 interval 9 == interval(5,9)
>
> I don't like the idea of turning words into ope
Mike Meyer wrote:
[EMAIL PROTECTED] writes:
@infix
def interval(x, y): return range(x, y+1) # 2 parameters needed
This may allow:
assert 5 interval 9 == interval(5,9)
I don't like the idea of turning words into operators. I'd much rather
see something like:
@infix('..')
def interval(x, y):
re
[EMAIL PROTECTED] writes:
> @infix
> def interval(x, y): return range(x, y+1) # 2 parameters needed
>
> This may allow:
> assert 5 interval 9 == interval(5,9)
I don't like the idea of turning words into operators. I'd much rather
see something like:
@infix('..')
def interval(x, y):
return ra
Title: RE: Other notes
[EMAIL PROTECTED]
#- Here are some questions and suggestions of mine that I've
#- collected in
#- the last weeks on the language (please note that some (most?) of them
#- are probably wrong/useless/silly, but I've seen that such
#- notes help me
#- unders
Paul Rubin wrote:
> ".." just becomes an operator like + or whatever, which you can define
> in your class definition:
>
> class MyClass:
>def __dotdot__(self, other):
> return xrange(self.whatsit(), other.whatsit())
>
> The .. operation is required to return an iterator.
A
Andrew Dalke wrote:
I must say it's getting pretty annoying to say things like
"when would this be useful?" and "have you read the documentation?"
for your statements.
I'll second that. Please, "Bearophile", do us the courtesy of checking
(1) Google groups archive of the mailing list:
http://group
[EMAIL PROTECTED] wrote:
4) The printf-style formatting is powerful, but I still think it's
quite complex for usual purposes, and I usually have to look its syntax
in the docs. I think the Pascal syntax is nice and simpler to remember
(especially for someone with a little Pascal/Delphi experience ^
Andrew Dalke <[EMAIL PROTECTED]> writes:
> What does
> a = MyClass()
> b = AnotherClass()
> for x in a .. b:
> print x
>
> do? That is, what's the generic protocol?
".." just becomes an operator like + or whatever, which you can define
in your class definition:
class MyClass:
bearophileHUGS:
[on Python's O(n) list insertion/deletion) at any place other than tail
> (My hypothesis: to keep list implementation a bit simpler, to avoid
> wasting memory for the head buffer, and to keep them a little faster,
> avoiding the use of the skip index S).
Add its relative infrequent
[EMAIL PROTECTED] wrote:
for i in 1..12: pass
for c in "a".."z": pass
> @infix
> def interval(x, y): return range(x, y+1) # 2 parameters needed
> assert 5 interval 9 == interval(5,9)
> 10) There can be something in the middle between the def statement and
> the lambda.
These will likely n
Here are some questions and suggestions of mine that I've collected in
the last weeks on the language (please note that some (most?) of them
are probably wrong/useless/silly, but I've seen that such notes help me
understand a lot of things and to find my weak spots.)
1) I've seen that list pop/app
39 matches
Mail list logo
