Re: Python or Java or maybe PHP?
In article <863bk66tdt.fsf @bhuda.mired.or g>, Mike Meyer <mwm@mired.or g> wrote:
In article <863bk66tdt.fsf @bhuda.mired.or g>, Mike Meyer <mwm@mired.or g> wrote:
-
-
Re: Python or Java or maybe PHP?
Hans Nowak <hans@zephyrfal con.org> wrote:
...[color=blue]
> Maybe I misunderstand, but shouldn't this be:
>
> def WHILE(cond):
> if not cond(): return
> yield None
> for x in WHILE(cond): yield x
>
> After all, the original version only yields two things: None and a
> generator.
>
> (Or is this behavior different in Python 2.5? I hope not...)[/color]
No misunderstandin g on your part, just my error on untested code -- no
changes in Python 2.5 so that yield of a generator means yielding each
of its items, my bad, sorry.
Alex
Comment
-
Re: Python or Java or maybe PHP?
While on topic of custom contructs, the topic of syntactic macros has
come up in the past. Does anyone know if the dev team ever considered
for or against them? My interest in them was renewed when I came across
Logix
It does not seem very active at the moment nor do they see Python as a
long tem platform for their project. Although it already seemed usable
in the little programs I tested it with.
I keep asking myself why isn't this more popular especially when many
prominent Python devs seem to be well aware of Lisp where macros are
done right. But then again, Gosling's great Lisp prowess did not seem
to transfer into Java at all :-). Won't macros and type inference make
Python a Lisp with a syntax that I can stand and libraries that I could
use :-) ? Unfortunately there doesn't seem to be a peep from Mike Salib
on StarKiller either. Did he move on to other pursuits?
Comment
-
Re: Python or Java or maybe PHP?
In article <1136285678.276 857.268840@g43g 2000cwa.googleg roups.com>,
James <fphsml@gmail.c om> wrote:[color=blue]
>
>I keep asking myself why isn't this more popular especially when many
>prominent Python devs seem to be well aware of Lisp where macros are
>done right.[/color]
You have confused "many Python devs" with Guido. ;-) Guido hates
macros. Oddly enough, my impression is that macros are popular only in
the Lisp community, and they may well be part of the reason Lisp has
never become popular.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/
"Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face. It's kind of like having a guy who juggles chainsaws
wearing body armor arguing with a guy who juggles rubber chickens wearing
a T-shirt about who's in more danger." --Roy Smith
Comment
-
Re: Python or Java or maybe PHP?
Guido's concerns about preserving simplicity resonate well with me.
Maybe I am just a kid excited with his new toy. I have always admired
macros. Quite a few functional languages have them now. But they have
always been in languages with sub-optimal community code base, which
meant I never went too deep into any of those languages. So I never
used any macro supported language for long to have strong opinions
about any one implementation.
However, Logix's implementation looks rather interesting. By creating
sub languages that are close to but isolated from Python, it does not
really mess with the existing language but creates nice oppurtunities
to encapsulate boiler-plate code structures when the need arises.
I would not necessarily expect such functionality to be in the standard
distribution but language oriented programming could just be another
jewel in Python's multi-paradigm crown and set it distinctly apart from
competitors like Ruby.
Do you have any specific comments towards Logix's implementation?
Comment
-
Re: Python or Java or maybe PHP?
In article <1136300150.363 299.238800@g44g 2000cwa.googleg roups.com>,
James <fphsml@gmail.c om> wrote:[color=blue]
>
>Do you have any specific comments towards Logix's implementation?[/color]
Nope. I do know that Guido is generally in favor of Python-like
languages, and one of the goals of the AST project was to make that
easier. Ditto PyPy.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/
"Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face. It's kind of like having a guy who juggles chainsaws
wearing body armor arguing with a guy who juggles rubber chickens wearing
a T-shirt about who's in more danger." --Roy Smith
Comment
-
Re: Python or Java or maybe PHP?
aahz@pythoncraf t.com (Aahz) writes:[color=blue]
> In article <1136285678.276 857.268840@g43g 2000cwa.googleg roups.com>,
> James <fphsml@gmail.c om> wrote:[color=green]
>>I keep asking myself why isn't this more popular especially when many
>>prominent Python devs seem to be well aware of Lisp where macros are
>>done right.[/color]
> You have confused "many Python devs" with Guido. ;-) Guido hates
> macros.[/color]
I vaguelly recall hearing that Guido thought about adding macros to
Python, and rejected the idea because he didn't want users to have to
deal with compile-time errors at run time. Or something to that
effect.
That doesn't sounds like "hates" to me. More like "doesn't like the
baggage."
<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Comment
-
Macros in Python? (was Re: Python or Java or maybe PHP?)
In article <86zmmdf1hp.fsf @bhuda.mired.or g>, Mike Meyer <mwm@mired.or g> wrote:[color=blue]
>aahz@pythoncra ft.com (Aahz) writes:[color=green]
>> In article <1136285678.276 857.268840@g43g 2000cwa.googleg roups.com>,
>> James <fphsml@gmail.c om> wrote:[color=darkred]
>>>
>>>I keep asking myself why isn't this more popular especially when many
>>>prominent Python devs seem to be well aware of Lisp where macros are
>>>done right.[/color]
>>
>> You have confused "many Python devs" with Guido. ;-) Guido hates
>> macros.[/color]
>
>I vaguelly recall hearing that Guido thought about adding macros to
>Python, and rejected the idea because he didn't want users to have to
>deal with compile-time errors at run time. Or something to that
>effect.
>
>That doesn't sounds like "hates" to me. More like "doesn't like the
>baggage."[/color]
The smiley applies to that whole bit. Guido's main problem with macros
is that there's no clean way to integrate them into a language with
strong syntactical structure. He also doesn't like the idea of splitting
Python itself into mini-languages (by adding new keywords). He does have
a strong distaste for functional programming and sees macros as partly an
attempt to expand inappropriate usage of functional programming in
Python.
Plus your point, that probably covers most of it.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/
"Given that C++ has pointers and typecasts, it's really hard to have a
serious conversation about type safety with a C++ programmer and keep a
straight face. It's kind of like having a guy who juggles chainsaws
wearing body armor arguing with a guy who juggles rubber chickens wearing
a T-shirt about who's in more danger." --Roy Smith
Comment
-
Re: Python or Java or maybe PHP?
On Tue, 03 Jan 2006 16:25:06 -0500,
Mike Meyer <mwm@mired.or g> wrote:
[color=blue]
> I vaguelly recall hearing that Guido thought about adding macros to
> Python, and rejected the idea because he didn't want users to have to
> deal with compile-time errors at run time. Or something to that
> effect.[/color]
That would eliminate eval and exec, too.
Regards,
Dan
--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>
Comment
-
Re: Python or Java or maybe PHP?
Mike Meyer wrote:[color=blue]
> That doesn't sounds like "hates" to me. More like "doesn't like the
> baggage."
>
> <mike[/color]
Yet anonymous functions are nice.
Wouldn't it be possible to change the `def` statement to return a
reference to the function, and allow omitting the function name thereby
bypassing the default binding (current behavior)?
Something along the lines of
[color=blue][color=green][color=darkred]
>>> # Current behavior
>>> def foo(*args, **kwargs):[/color][/color][/color]
pass[color=blue][color=green][color=darkred]
>>> print foo[/color][/color][/color]
<function foo at 0x00FA37B0>
[color=blue][color=green][color=darkred]
>>> # Extended behavior
>>> # returns a reference to the function
>>> def foo(*args, **kwargs):[/color][/color][/color]
pass
<function at 0x00FA37B0>[color=blue][color=green][color=darkred]
>>>
>>> # Anonymous functions
>>> def (*args, **kwargs):[/color][/color][/color]
pass
<function at 0x00FA3830>[color=blue][color=green][color=darkred]
>>> foo = def(*args, **kwargs): pass[/color][/color][/color]
Note that the function wouldn't "have" it's own name anymore (no more
"__name__" attribute? Or a blank one?)
Since functions can already be defined inline, the only thing that'd be
left would be to end the function's definition when the "wrapper"
structure ends:
[color=blue][color=green][color=darkred]
>>> doSomething(def (*args, **kwargs): pass, arg) # End of the function[/color][/color][/color]
definition at the end of it's argument[color=blue][color=green][color=darkred]
>>> doSomethingElse (def (*args, **kwargs):[/color][/color][/color]
.... # Multiline
.... pass
.... )
I'm not too sure about the multi line version (and it looks very ugly
with a non-monospaced font), but:
Pros (I think):
* Backwards-compatible (I think, since the new uses of `def` are
currently errors)
* Fairly obvious syntax
* No `lambda` or `macros` baggage, the new form of def would merely
define an anonymous function instead of a named one.
* No new keyword, or structure, or idiom
* Existing idioms are merely slightly extended without changing
their current meaning
Cons:
* May reduce readability when misused, and may be used in Very
Stupid Ways that reduce readability a lot (but then again most construct
may be abused in some way), e.g.:
doSomething(arg 1, arg2, arg3, def foo(a): manipulate(a)) #
binds a function to `foo` _and_ sends it to `doSomething`
...
[a few lines of code]
...
foo(value) # where the hell did that "foo" come from?
* Replaces lambdas with something much more powerful, which may go
against the goal of getting rid of lambdas (unless the aforementioned
goal is mostly because of the historical baggage of lambdas/macros)
Unsure:
* Shows that Python is the Ultimate Language, people are not ready yet.
* May allow for blocks-like constructs (I'm not sure of the current
state of the closures over Python functions though, these may have to be
extended to "full" closures if they aren't) and be considered by some as
yielding to the hype (even though the structure itself is more or less
35 years old)
Comment
-
Re: Python or Java or maybe PHP?
Xavier Morel <xavier.morel@m asklinn.net> wrote:
...[color=blue]
> Wouldn't it be possible to change the `def` statement to return a
> reference to the function, and allow omitting the function name thereby
> bypassing the default binding (current behavior)?[/color]
It's _possible_ (doesn't introduce syntax ambiguities) though it does
introduce incompatible interactive-interpreter behavior, as you say:
[color=blue][color=green][color=darkred]
> >>> # Extended behavior
> >>> # returns a reference to the function
> >>> def foo(*args, **kwargs):[/color][/color]
> pass
> <function at 0x00FA37B0>[/color]
This could be avoided if 'def <name><etc>' remained a statement like
today, and a separate expression 'def<etc>' returned a function object
as a result; this would have the aded plus of avoiding the totally new
(to Python) idea of "statement returning a value" (_expressions_ return
a value).
[color=blue]
> Note that the function wouldn't "have" it's own name anymore (no more
> "__name__" attribute? Or a blank one?)[/color]
Currently, a lambda has a __name__ of '<lambda>'; I'd assume a similar
arrangement if 'expression def' took lambda's place.
[color=blue]
> I'm not too sure about the multi line version (and it looks very ugly[/color]
Yeah, the multiline's the rub -- there's currently no multiline
expression, and it does look ugly.
[color=blue]
> * May allow for blocks-like constructs (I'm not sure of the current
> state of the closures over Python functions though, these may have to be
> extended to "full" closures if they aren't) and be considered by some as[/color]
Python's closures are 'full', but don't allow inner functions to rebind
names in the namespace of outer functions.
I'm not sure a PEP like this has ever been proposed, but the idea of
anonymous def is not new (bar some details of your proposal): if a PEP
doesn't exist, you could write one, at least to firm up all details.
Alex
Comment
-
Re: Python or Java or maybe PHP?
Alex Martelli wrote:[color=blue]
> Xavier Morel <xavier.morel@m asklinn.net> wrote:
> ...[color=green]
>> Wouldn't it be possible to change the `def` statement to return a
>> reference to the function, and allow omitting the function name thereby
>> bypassing the default binding (current behavior)?[/color]
>
> It's _possible_ (doesn't introduce syntax ambiguities) though it does
> introduce incompatible interactive-interpreter behavior, as you say:
>[color=green][color=darkred]
>> >>> # Extended behavior
>> >>> # returns a reference to the function
>> >>> def foo(*args, **kwargs):[/color]
>> pass
>> <function at 0x00FA37B0>[/color]
>
> This could be avoided if 'def <name><etc>' remained a statement like
> today, and a separate expression 'def<etc>' returned a function object
> as a result; this would have the aded plus of avoiding the totally new
> (to Python) idea of "statement returning a value" (_expressions_ return
> a value).
>[/color]
True that, I didn't even consider the possibility to create an
independent expression.
And it completely remove the possibility to generate the first "con".
[color=blue][color=green]
>> * May allow for blocks-like constructs (I'm not sure of the current
>> state of the closures over Python functions though, these may have to be
>> extended to "full" closures if they aren't) and be considered by some as[/color]
>
> Python's closures are 'full', but don't allow inner functions to rebind
> names in the namespace of outer functions.
>
> I'm not sure a PEP like this has ever been proposed, but the idea of
> anonymous def is not new (bar some details of your proposal): if a PEP
> doesn't exist, you could write one, at least to firm up all details.
>
>
> Alex[/color]
Or maybe start by creating a thread on the subject of an anonymous def
expression on this list first?
Comment
-
Re: Python or Java or maybe PHP?
Xavier Morel <xavier.morel@m asklinn.net> writes:[color=blue]
> Mike Meyer wrote:[color=green]
>> That doesn't sounds like "hates" to me. More like "doesn't like the
>> baggage."
>> <mike[/color]
> Yet anonymous functions are nice.
>
> Wouldn't it be possible to change the `def` statement to return a
> reference to the function, and allow omitting the function name
> thereby bypassing the default binding (current behavior)?[/color]
[...][color=blue][color=green][color=darkred]
> >>> # Anonymous functions
> >>> def (*args, **kwargs):[/color][/color]
> pass
> <function at 0x00FA3830>[color=green][color=darkred]
> >>> foo = def(*args, **kwargs): pass[/color][/color][/color]
This kind of thing has been proposed a number of times, by a number of
people. Including me.
[examples elided]
[color=blue]
> I'm not too sure about the multi line version (and it looks very ugly
> with a non-monospaced font), but:[/color]
The multi-line version is actually a killer problem. If you allow
newlines it, you get all kinds of problems with nesting, and the code
gets really ugly. If you don't allow newlines, what you have is barely
more powerfull than the existing lambda, and would tempt people to
write really ugly suites in a single line.
[color=blue]
> Pros (I think):
> * Backwards-compatible (I think, since the new uses of `def` are
> * currently errors)
> * Fairly obvious syntax
> * No `lambda` or `macros` baggage, the new form of def would
> * merely define an anonymous function instead of a named one.
> * No new keyword, or structure, or idiom
> * Existing idioms are merely slightly extended without changing
> * their current meaning[/color]
My version was actually even more backwards compatible - I only
returned the value in the case where you were defining an anonymous
function. Not that that makes any real difference.
[color=blue]
> Cons:
> * May reduce readability when misused, and may be used in Very
> * Stupid Ways that reduce readability a lot (but then again most
> * construct may be abused in some way), e.g.:[/color]
It's not clear that there are any useful uses that are readable. I had
examples in my proposal, and freely admitted that they were ugly. I
may even have mentioned it in the proposal.
How about some use cases with example usage? That would show us
whether or not there are uses that are both useful and not ugly. Even
if the idea is ultimately rejected, the use cases may generate
different proposals for solving them that are accepted.
<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Comment
-
Re: Python or Java or maybe PHP?
Peter Hansen wrote:[color=blue]
> Alex Martelli wrote:
>[color=green]
>>One great programming principle is "Dont' Repeat Yourself": when you're
>>having to express the same thing over and over, there IS something
>>wrong. I believe the "DYR" phrasing is due to the so-called Pragmatic
>>Programmers , who are paladins of Ruby, but I also believe it's a
>>principle most experienced programmers could accept.[/color]
>
>
> Shall we assume DYR == "Do You Ruby?" ? <wink>
>[/color]
No. it's the Forth equivalent of DRY: Don't yourself repeat.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Comment
Comment