Python or Java or maybe PHP?

[li...@noks.com]

Hi everyone,

I need to write a web app, that will support millions of user accounts,
template-based user pages and files upload. The client is going to be
written in Flash. I wondered if I coudl get your opinions - what do you
think is the best language to use for the server? Python or Java? And
I'm talking scalability, object oriented, development tools etc.

Thansk for any idea! I'd love to hear it
Happy New 2006,
Lior

[Alex Martelli]

<li...@noks.com> wrote:

> Hi everyone,
>
> I need to write a web app, that will support millions of user accounts,
> template-based user pages and files upload. The client is going to be
> written in Flash. I wondered if I coudl get your opinions - what do you
> think is the best language to use for the server? Python or Java? And
> I'm talking scalability, object oriented, development tools etc.

I would personally not consider PHP, in terms of "human" scalability (if
the server needs to grow to substantially rich logic etc). However,
Ruby (with Rails, of course, as the server-side framework), Python (many
options server-side, from Twisted to Django), and Java (even more
options server-side), are, I believe, all worthy candidates. They're
all "object oriented" enough that the fine distinctions among them don't
really matter; choice of developer tools is probably widest for Java and
least wide for Ruby (and the same for server-side web frameworks), but
this cuts both ways (once you've decided on Java as the language you
still have many weeks of evaluation to pick tools and frameworks -- if
you decide on Ruby, tools and framework are more or less fixed -- Python
is "in between" in both fields).

The "etc." is where the fun is;-). Java is statically typed, Ruby and
Python are dynamically typed: you will perhaps find more flamewars on
the web about this one aspect of programming languages than about all
others combined. On the basis of extensive personal experience, I'm
firmly in the dynamical-typing camp -- firmly convinced that Ruby or
Python make developers and teams more productive, or, in other words,
that Ruby and Python are "higher-level" than Java, requiring much less
code to implement a given amount of functionality, and developers'
productivity is tied mostly to the "amount of code" they need to
develop, debug, maintain (functional specs and user documentation OTOH
depend on functionality, not on code needed to implement the
functionality, and so don't depend on the choice of implementation
language[s]).

You'll also find lots of flamewars on each side about side issue such as
"community", or "the quality of programmers" that you can easily get for
language A vs language B (for just about any choice of A and B;-). I'm
not sure how much weight you should give to these considerations, or
other "soft and fuzzy" ones such as the issue of "philosophy" reflected
by each language's design and community.

All things considered, I would tentatively suggest Python, but if you
examined both languages a little and then picked Ruby (or, given a
suitable number of CS PhD's in your development team, Common Lisp, or
Haskell, but that's another issue) I'd have no basis for predicting that
your choice would be wrong; if you picked Java, I would strongly suspect
you made the wrong choice; if you picked PHP, I would personally feel
_certain_ that you made the wrong choice;-).

And just to give the devil its due, if it's an acceptable trade-off for
your server to be shackled to Microsoft systems forevermore, you might
even want to consider ASP.NET -- I have no experience with it
whatsoever, but some people whose technical judgment I respect do claim
it's a good choice. Personally, I would consider the 'strategic' cost
(the above-mentioned MS shackes) too high in any case, but only you can
make such decisions for your own circumstances. Similarly, Apple's
WebObjects have also been widely praised, but they would shackle you to
Apple systems (language choice directly supported by Apple for
WebObjects is Objective C, Java, and WebScript, a proprietary
very-high-level language; but I believe that thanks to PyObjC you could
use Python instead or side by side with ObjC, just as, of course, you
always have the option of Jython, instead or side by side with Java,
whenever you choose a "Java"-based platform).

Alex

[NOKs]

Thanks! That's really useful. I'm not sure if I'm a "dynamically typed"
guy - coming form C#, very strict language, and C++, statically typed,
but i definetly searched and see the debate going strong. Not try to
start it here, but do you think that statically typed - namely, if I
undertood correctly, the fact that there's no need to declare the
variables - do you think it has such an effect on productivity?

thanks again!
Lior

[Alex Martelli]

NOKs <li...@noks.com> wrote:

> Thanks! That's really useful. I'm not sure if I'm a "dynamically typed"
> guy - coming form C#, very strict language, and C++, statically typed,

C#'s pretty close to Java, typing-wise, and C++'s not that far away. I
did mention one GOOD statically typed language in my previous post...
unfortunately it's one of those for which you need a bunch of CS PhD's
-- Haskell.

> but i definetly searched and see the debate going strong. Not try to
> start it here, but do you think that statically typed - namely, if I
> undertood correctly, the fact that there's no need to declare the
> variables - do you think it has such an effect on productivity?

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.

So, when in Java you have to code:

FooBar zap = (FooBar) glak;

you KNOW there must definitely be something wrong -- what's the POINT of
making you say "FooBar" TWICE?!

There are two ways to let you avoid declaring variables, enabling DYR
and enhancing productivity:

a. do everything at runtime (as Java will of course do for the check, in
the above code, that glak CAN be properly "cast to a FooBar"); if you do
ALL the typechecks at runtime, consistently, you get a dynamically typed
language. "Dynamically" is much the same as "at runtime". And it turns
out that the only check you really need is:
-- when you call bleep.zupdok(), DOES whatever object bleep
refer to support a 'zupdok' method that is callable with no args?
Runtime typing is enabled, as a productive programming approach, by the
fact that, whatever your language's approach to typing, you NEED
unit-tests anyway (because they're indispensable to check, necessarily
at runtime, a lot of things nobody can check statically)... and, as a
side effect, good unit-tests will also duplicate all the (very modest)
checks a statically typed language could do for you.

b. do everything at compile time. The typesystems of Java, C#, C++ are
substantially too weak and inconsistent for that; however, language such
as ML (in its several variants) and Haskell prove that a typesystem CAN
be designed to allow that. With a properly designed typesystem, you
don't NEED declarations either: you code something like (in Python
syntax)
def f(a, b): return a+b
and the compiler deduces "a and b must be variables of a typeclass that
supports addition, and function f's return value is going to be of the
same typeclass as a and b". So, if you later call f(2,3), the compiler
accepts that and knows the result must be an int, but if you try to code
f('zap', 67) the compiler screams at you because it knows you can't add
a string and an int. This "type inference" is very powerful, and
practically equivalent (at least in the Haskell variant, based on
"classes of types", aka "typeclasses", not mere types) to the "dynamic
typing" you get with Python, with further benefits (you get some errors
diagnosed faster, without even needing to run your unit-tests, which
saves you a few seconds when it happens).

Unfortunately, I believe Haskell (and SML, etc) only really suit
programmers who have a very particular qualification and mindset --
essentially, higher degrees in mathematics or CS, or the equivalent
(some people will have that knack without formal titles, of course, but
it's somewhat hard to predict who will). If you have the rare fortune
that your programming team can be counted on to be composed only of such
people, do give Haskell a try (and don't forget Common Lisp, another
language of uncanny power), and you may be even happier than with
dynamic language (not necessarily -- a high-profile site has just been
recoded from Lisp to Python, essentially for highly pragmatic reasons,
for example -- but Python-friendly, Lisp-centered authorities such as
Norvig and Graham still think Lisp would have an advantage in such
circumstances, assuming of course the pragmatical issues can be swep
away in your case).

If "really good" static typing, as in Haskell, is not a real possibility
-- that is, in the real world, given the choice between dynamic typing
as in Python and faulty semi-static "but with some inevitable runtime
aspects AND lots of redundancy required of the programmer" typing as in,
say, Java -- I really have no doubt that dynamic typing increases
programmer productivity quite substantially. At Google, I see the same
brilliant engineers code in Python, C++, and Java (the three general
purpose languages Google uses), and the productivity results that I
observe appear to fully confirm my opinions (already formed on the basis
of other experiences, both regarding my own coding and that of other
programmers, of varying skills, I observed in the past).

Once you've decided to give dynamic-typing languages a try, the issue
still remains open between Ruby and Python, of course (there are others,
from Tcl to Perl, from Lua to Applescript, etc, etc, but I see no real
reasons to consider any other but Python and Ruby for your task).
Despite the many differences of detail (mostly, though not exclusively,
details of "syntax sugar"), I consider Ruby and Python to be essentially
equivalent *as languages*, so I would suggest you choose on a strictly
pragmatical basis -- quality of framework and library, execution speed,
tools, books, third-party extensions, &c. I see it as a tribute to both
languages that (not having much real-world experience with Rails vs,
say, Django) I don't know for sure which one would suit you best, though
I suspect that, if nothing else for reasons of "maturity", it might be
Python. Be aware, though, that at least one Ruby fanatic has verbally
assaulted me quite intensely for daring to express these, which I
consider to be very even-handed, judgments (apparently, by considering
"a mere syntax sugar issue" the fact that in Python you code, e.g., "if
a>b: c=d", while in Ruby you may code the other way 'round, "c=d if
a>b", I must have insulted some gods at whose altar such fanatics
worship...); if you choose to listen to such fanatics, you should then
definitely get a second opinion rather than trust my own assessment of
these issues.

Alex

[Peter Hansen]

Alex Martelli wrote:
> 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.

Shall we assume DYR == "Do You Ruby?" ? <wink>

[Ilias Lazaridis]

You may want to review some basic evaluations, which can simplify the
selection process:

(note that this is a work in progress)

http://lazaridis.com/case/lang/index.html

and some community evaluations:

http://lazaridis.com/core/eval/index.html

-

You have to define your requirements.

This way you can manage the complexity of the evaluation.

-

please feel free to contact me with private email.

.

--
http://lazaridis.com

[Alex Martelli]

Peter Hansen <pe...@engcorp.com> wrote:

Heh, I _did_ mean "DRY" of course;-)

Alex

[Cameron Laird]

In article <1h8ia95.qy2gkbzh9jmcN%al...@mail.comcast.net>,
Alex Martelli <al...@mail.comcast.net> wrote:
.
[much valuable and
correct detail that
somehow managed to
avoid mentioning
Forth or Smalltalk]
.

.
>Despite the many differences of detail (mostly, though not exclusively,
>details of "syntax sugar"), I consider Ruby and Python to be essentially
>equivalent *as languages*, so I would suggest you choose on a strictly
>pragmatical basis -- quality of framework and library, execution speed,
>tools, books, third-party extensions, &c. I see it as a tribute to both

.
.
.
I think it's worth repeating, Alex, a point you've made in the
past, and that tangentially supports your elided example about
"c = d unless ...": it's possible to distinguish Python from
Ruby in another way. Python is arguably better for group work,
or at least more standard for team projects, because it more
consistently exposes "one correct solution", while Ruby both
admits more stylistic variation, *and* encourages construction
of novel control structures.

[Alex Martelli]

Cameron Laird <cla...@lairds.us> wrote:
...

> "c = d unless ...": it's possible to distinguish Python from
> Ruby in another way. Python is arguably better for group work,
> or at least more standard for team projects, because it more
> consistently exposes "one correct solution", while Ruby both
> admits more stylistic variation, *and* encourages construction
> of novel control structures.

Arguably, yes; but in the end any team (or firm working as a set of
fluid teams) that really wants such uniformity (and, it _should_;-),
can't rely on just the language, but must supplement it with an internal
"coding style" guide. It will supplement Python's rules by (say) PEP 8
and more rigid choices about capitalization of names (such guidance
about capitalization IS embedded in Ruby, btw -- one aspect where Ruby
promotes uniformity more than Python does); it will supplement Ruby's
rules by similar sets of style constraints. You can construct novel
control structures with Python's generators (particularly in 2.5, with
the already-accepted enrichments of generator functionality) just as you
can in Ruby by passing blocks to methods; whether you DO so on a routine
basis (rather than, say, in a few specific "common modules" that are
collectively accepted and maintained by the whole team or firm) does not
depend so much on the language, as on the team's/firm's central
collective coordination. (Much the same, in spades, could be said of
macros in Common Lisp, of course).

Yes, Python has a cultural, community value of "uniformity" -- that may
make it easier to convince Python enthusiasts of the need to agree
collectively on strict coding-style standards, compared to doing the
same convincing on enthusiasts of languages whose cultural values
include enthusiastic, exhuberant acceptance of individual variation.
But I do not think that such "cultural and philosophical differences" as
they apply to a whole community are more than a secondary factor in
determining the culture and philosophy of a specific team, or firm...

Alex

[Mike Meyer]

Alex Martelli gave an excellent overview of this question, and his
answer ("Yes"). However, you're in a forum for dynamically typed
languages, so that's to be expected. In a forum devoted to statically
typed languages, you'll find people who will answer the other way,
using their experience and observations as the grounds for that
conclusion. What's notably lacking for both camps is any real research
on the subject. I've seen it claimed that the SPARK folks have that
research, but have been unable to find such. What SPARK papers I have
found concentrate more on correctness than productivity: IIRC, they
claim millions of lines of production code with no errors.

I wanted to point out that there are other more sides to this
issue. To start with, when you say "declare variables", you really
mean "declare variables TYPES". There are dynamically typed languages
where you have to declare every variable, and others where variables
spring into existence when mentioned. Python is halfway between the
two, requiring you to declare arguments, and only creating variables
when they are assigned to. As Alex mentioned, there are statically
typed languages where you don't have to declare the variables types
either. I'm just starting to look into this, and I don't know of any
that don't require you to declare all your variables as well.

Finally, there's a camp that pushes static typing up a notch,
practicing what's called "Design by Contract" (DbC). Languages like
Eiffel and D incluce DbC facilities. With these, you add extra code
that provides checks on the preconditions to a method invocation,
postconditions when it exits, invariants for an object, and various
conditions on a loop. This help with the DRY principle, as a good set
of unit tests would check all these things before and after each test,
so you'd have to code the checks (or invocations of them) for every
method invocation in every test. With language support, you only code
them once, and the compiler generates code to check them
automatically. Again, people who use them swear by them - but have no
hard data to back up their believes.

<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Steven D'Aprano]

On Mon, 02 Jan 2006 19:35:10 -0500, Mike Meyer wrote:

> What SPARK papers I have
> found concentrate more on correctness than productivity: IIRC, they
> claim millions of lines of production code with no errors.

Writing error-free code is easy. That's just a matter of incremental
improvement of error-full code.

Writing error-free code *the first time* is hard. One wonders how many
edit-compile-test cycles it takes to get these millions of lines of
error-free code.

--
Steven.

[Mike Meyer]

Steven D'Aprano <st...@REMOVETHIScyber.com.au> writes:
> On Mon, 02 Jan 2006 19:35:10 -0500, Mike Meyer wrote:
>> What SPARK papers I have
>> found concentrate more on correctness than productivity: IIRC, they
>> claim millions of lines of production code with no errors.
> Writing error-free code is easy. That's just a matter of incremental
> improvement of error-full code.

*Proving* that it's error-free is the hard part.

> Writing error-free code *the first time* is hard. One wonders how many
> edit-compile-test cycles it takes to get these millions of lines of
> error-free code.

Dunno. But the SPARK folks are doing things where errors kill people
(airplane flight control systems being the example that comes to
mind). The amount they're willing to spend getting error-free code is
probably more than it is for most people.

[James]

Now I am curious. How do Python 2.5 and Ruby create new control
structures? Any code samples or links?

Thanks.

[Alex Martelli]

James <fph...@gmail.com> wrote:

> Now I am curious. How do Python 2.5 and Ruby create new control
> structures? Any code samples or links?

A Ruby example of reimplementing while:

def WHILE(cond)
| return if not cond
| yield
| retry
| end
i=0; WHILE(i<3) { print i; i+=1 }

Python's a bit less direct here, but:

def WHILE(cond):
if not cond(): return
yield None
yield WHILE(cond)

i = 0
for blah in WHILE(lambda: i<3):
print i; i += 1

You need to explicitly guard the condition with a lambda to defer
execution (while Ruby's retry repeats deferred execution directly), and
explicitly use recursion to "loop forever", but conceptually the
differences are not all that deep.

Of course nobody would write such WHILE functions in either Ruby or
Python, since the built-in 'while' statement of each language is
perfectly sufficient, but I hope this suffices to show what we mean...

Alex

[Hans Nowak]

Alex Martelli wrote:

> A Ruby example of reimplementing while:
>
> def WHILE(cond)
> | return if not cond
> | yield
> | retry
> | end
> i=0; WHILE(i<3) { print i; i+=1 }
>
> Python's a bit less direct here, but:
>
> def WHILE(cond):
> if not cond(): return
> yield None
> yield WHILE(cond)

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...)

--
Hans Nowak
http://zephyrfalcon.org/

[Cameron Laird]

In article <863bk66...@bhuda.mired.org>, Mike Meyer <m...@mired.org> wrote:
.
[valuable remarks
on scientific
evidence and so on]
.

.
>Finally, there's a camp that pushes static typing up a notch,
>practicing what's called "Design by Contract" (DbC). Languages like
>Eiffel and D incluce DbC facilities. With these, you add extra code
>that provides checks on the preconditions to a method invocation,
>postconditions when it exits, invariants for an object, and various
>conditions on a loop. This help with the DRY principle, as a good set
>of unit tests would check all these things before and after each test,
>so you'd have to code the checks (or invocations of them) for every
>method invocation in every test. With language support, you only code
>them once, and the compiler generates code to check them
>automatically. Again, people who use them swear by them - but have no
>hard data to back up their believes.

.
.
.
... and it's even possible, as has already been hinted
several times in slightly different aspects in this
thread already, to combine these concepts to yield, for
example, DbC practices with a dynamic language such as
Python ("Design By Contract for Python", PyDBC, Contracts
for Python, ...).

[Alex Martelli]

Hans Nowak <ha...@zephyrfalcon.org> wrote:
...

> 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...)

No misunderstanding 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

[James]

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
http://www.livelogix.net/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?

[Aahz]

In article <1136285678.2...@g43g2000cwa.googlegroups.com>,

James <fph...@gmail.com> wrote:
>
>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.

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 (aa...@pythoncraft.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

[James]

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?

[Aahz]

In article <1136300150.3...@g44g2000cwa.googlegroups.com>,

James <fph...@gmail.com> wrote:
>
>Do you have any specific comments towards Logix's implementation?

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.

[Mike Meyer]

aa...@pythoncraft.com (Aahz) writes:
> In article <1136285678.2...@g43g2000cwa.googlegroups.com>,
> James <fph...@gmail.com> wrote:
>>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.
> You have confused "many Python devs" with Guido. ;-) Guido hates
> macros.

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."

[Aahz]

In article <86zmmdf...@bhuda.mired.org>, Mike Meyer <m...@mired.org> wrote:
>aa...@pythoncraft.com (Aahz) writes:
>> In article <1136285678.2...@g43g2000cwa.googlegroups.com>,
>> James <fph...@gmail.com> wrote:
>>>
>>>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.
>>
>> You have confused "many Python devs" with Guido. ;-) Guido hates
>> macros.
>
>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."

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.

[Dan Sommers]

On Tue, 03 Jan 2006 16:25:06 -0500,
Mike Meyer <m...@mired.org> wrote:

> 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 would eliminate eval and exec, too.

Regards,
Dan

--
Dan Sommers
<http://www.tombstonezero.net/dan/>

[Xavier Morel]

Mike Meyer wrote:
> That doesn't sounds like "hates" to me. More like "doesn't like the
> baggage."
>
> <mike

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

>>> # Current behavior
>>> def foo(*args, **kwargs):
pass
>>> print foo
<function foo at 0x00FA37B0>

>>> # Extended behavior
>>> # returns a reference to the function
>>> def foo(*args, **kwargs):
pass
<function at 0x00FA37B0>
>>>
>>> # Anonymous functions
>>> def (*args, **kwargs):
pass
<function at 0x00FA3830>
>>> foo = def(*args, **kwargs): pass

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:

>>> doSomething(def (*args, **kwargs): pass, arg) # End of the function
definition at the end of it's argument
>>> doSomethingElse(def (*args, **kwargs):
... # 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(arg1, 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)

[Alex Martelli]

Xavier Morel <xavier...@masklinn.net> wrote:
...

> 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)?

It's _possible_ (doesn't introduce syntax ambiguities) though it does
introduce incompatible interactive-interpreter behavior, as you say:

> >>> # Extended behavior
> >>> # returns a reference to the function
> >>> def foo(*args, **kwargs):
> pass
> <function at 0x00FA37B0>

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).

> Note that the function wouldn't "have" it's own name anymore (no more
> "__name__" attribute? Or a blank one?)

Currently, a lambda has a __name__ of '<lambda>'; I'd assume a similar
arrangement if 'expression def' took lambda's place.

> I'm not too sure about the multi line version (and it looks very ugly

Yeah, the multiline's the rub -- there's currently no multiline
expression, and it does look ugly.

> * 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

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

[Xavier Morel]

Alex Martelli wrote:
> Xavier Morel <xavier...@masklinn.net> wrote:
> ...
>> 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)?
>
> It's _possible_ (doesn't introduce syntax ambiguities) though it does
> introduce incompatible interactive-interpreter behavior, as you say:
>
>> >>> # Extended behavior
>> >>> # returns a reference to the function
>> >>> def foo(*args, **kwargs):
>> pass
>> <function at 0x00FA37B0>
>
> 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).
>

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".

>> * 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
>
> 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

Or maybe start by creating a thread on the subject of an anonymous def
expression on this list first?

[Mike Meyer]

Xavier Morel <xavier...@masklinn.net> writes:
> Mike Meyer wrote:
>> That doesn't sounds like "hates" to me. More like "doesn't like the
>> baggage."
>> <mike
> 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)?

[...]

> >>> # Anonymous functions
> >>> def (*args, **kwargs):
> pass
> <function at 0x00FA3830>
> >>> foo = def(*args, **kwargs): pass

This kind of thing has been proposed a number of times, by a number of
people. Including me.

[examples elided]

> I'm not too sure about the multi line version (and it looks very ugly
> with a non-monospaced font), but:

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.

> 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

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.

> 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.:

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.

[Steve Holden]

Peter Hansen wrote:

> Alex Martelli wrote:
>
>>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.
>
>

> Shall we assume DYR == "Do You Ruby?" ? <wink>
>

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/