On 7/25/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Ivan Krstic wrote:
> > Python already has
> > just enough programmable bits in place to invite abuse which emulates
> > programmable syntax; look at SQLObject or SQLalchemy for examples.
>
> Also, the "just use a string" workaround means that
> pe
Ivan Krstic wrote:
> Python already has
> just enough programmable bits in place to invite abuse which emulates
> programmable syntax; look at SQLObject or SQLalchemy for examples.
Also, the "just use a string" workaround means that
people are effectively doing this anyway, but in an
uglier and le
Guido van Rossum wrote:
> I'd like to see this fall under the blanket "Python will not have
> programmable syntax" rule in PEO 3099.
Why?
I understand your general position, but categorically rejecting anything
smelling of metasyntax seems ill-conceived to me. Python already has
just enough progr
Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > I'd like to see this fall under the blanket "Python will not have
> > programmable syntax" rule in PEO 3099.
>
> Would this also mean that you don't want people to be manipulating AST
> objects a'la Boo
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> I'd like to see this fall under the blanket "Python will not have
> programmable syntax" rule in PEO 3099.
Would this also mean that you don't want people to be manipulating AST
objects a'la Boo macros?
- Josiah
__
I'd like to see this fall under the blanket "Python will not have
programmable syntax" rule in PEO 3099.
On 7/20/06, Talin <[EMAIL PROTECTED]> wrote:
> A number of dynamic languages, such as Lisp, support the notion of an
> 'unevaluated' expression. In Lisp, a macro is simply a function that can
>
At 01:58 AM 7/20/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>I'd like to propose a standard way to represent one of these syntactical
>variables. The syntax I would like to see is '?x' - i.e. a question mark
>followed by the variable name.
>
>The reason for choosing the question mark is that this
A number of dynamic languages, such as Lisp, support the notion of an
'unevaluated' expression. In Lisp, a macro is simply a function that can
operate on the *syntax* of the expression before it is actually compiled
and interpreted.
A number of Python libraries attempt to use operator overloadi
