tim wrote:
> + There are things Guido will & won't tolerate. Guessing which is an
> interesting & educational challenge <wink>. For example, adding a new
> operator like
>=20
> .+
>=20
> is fine, as the maximal-munch rule for lexing can resolve formal =
ambiguities
> easily.
Only if you're thinking as a compiler... ;-)
Besides, the proposed way to resolve "3.+x" means that the meaning
of an operator would change depending on the preceeding operand (and
the other way around). Sure sounds like Perl to me...
> This one is from me, but it's a safe bet you can view at as =
precognitive
> channeling if you oppose it: anyone suggesting to, e.g., make ".+" =
mean
> something new and exciting for ints or floats or strings=20
Why not strings? As Perl has showed, *everyone* is doing string
processing. If we're gonna add stuff, why not cater to the masses?
For a start, how about:
match =3D string .~ pattern
I'm sure we can do something fun with ?, the sre scanner, and list
comprehensions too...
> There are at least 4 variants of Python translators=20
Fwiw, a recent sunworld article says six. And don't forget syntax
checking development environments (afaik, at least two of them
does that, or will in a near future).
> Please keep this off of Python-Dev.
Okay, okay. Last time I tried to say that, everyone shouted at me.
On the other hand, now that Python has dropped from spot 10 down to
15 on the sourceforge top activity list, it's about time python-dev went
back to actually doing things, instead of just talking about what could =
be
done... ;-)
</F>=20
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4