[Baypiggies] Frequently Argued Objections

[Seth Friedman]

Andrew,

Could not agree more re: the nerdraging, I am prone to it myself and I think
it's worthwhile to take special care in avoiding.    One of the reasons I
even bothered to find out why Python is different from other language (or
language communities, rather), and ultimately start learning it, is the
relative civility I observed in the community early on (and appreciate
still).   It's perhaps a subtle difference, but an important one.

My suggestions for the FAO list:

- Why whitespace?

Produces concise code, where blocks of code have an instant visual cue to
represent depth that is faster, nearly automatic evaluation of how deeply
nested arbitrary statement can be than counting {{{}}}'s, at an understood
up-front cost in learning the language.

- Duck typing?

Yeah, I'm probably not a good person to answer this because I don't really
comprehend the tradeoffs involved in the choice.   It strikes me as odd,
other people seem to care more than I.

- How do I trust the garbage collection isn't doing weird things along the
lines of the stop-the-world collector default in some versions of Java?

Again here, I'd love to learn more about how Python frees memory structures
in detail, but don't really know how/where.    I've worked with Java enough
to be (in my opinion) healthily paranoid, I haven't run into problems with
this in Python, but I would love some understanding of what's going on under
the covers sufficient to believe it's not just a matter of time, e.g.
growing complexity of my code, until I start seeing utterly bizarre
behavior.   I prefer to understand special-care-and-feeding cases up front
and avoid them in design, rather than end up with a pile of years-old code I
have to maintain, that only shows oddities of a language at the point where
the complexity factor is high.

- Why such difficulty with extensibility?

OK, there are cases that are valid, I don't know of a library that I can
natively read an OODoc spreadsheet in python where that exists in perl for
example.    However, I think this is a biproduct of the "batteries included"
mindset, which i interpret as -- the python community has an acknowledged
preference for libraries that work to a fairly sound definition of "good
enough", and maybe there's no good-enough OODoc python library yet.
Still, in terms of discovery, perl has CPAN, and perl folks seem to like
...  well no, they seem to tolerate it.     Does Python need an improved
CPAN?    Or is Python so "batteries included" that it's either - the
language has it standard, or you're going to need google to find it?
There's probably a related question of how large are the community of
contributers and what are the barriers to entry, what is the relative merit
of 10 half-baked libraries targeted at slightly different use cases, vs 1
that kicks butt.

Still, I get "poor extensibility" as a top critique of python probably more
than anything else these days.

~seth

On Thu, Jun 19, 2008 at 3:28 PM, Andrew Toulouse <baypiggies at atoulou.se>
wrote:

> Those answers come off as somewhat insular or holier-than-thou. More than a
> few people I know factored the Python community's lack of nerdraging into
> their decision to learn it over Ruby. Not that you intended that, but some
> people might take it as such.
>
> I'd change a few answers. Forgive me if the answers are wrong, I'm a
> journeyman, not a master of Python. Here are my answers to the first four:
>
> A1. There are many reasons to make a language case-sensitive, not the least
> of which being that many (possibly even most) other languages are also
> case-sensitive. Case-sensitivity also encourages a sensible and consistent
> naming style.
>
> A2. Since Python's internals are standardizing on Unicode, strings are, by
> default, Unicode. The 'u' tag no longer has a purpose, and with the break in
> compatibility from 2.x to 3.0, now is the ideal time to remove it from the
> language.
>
> A3. There are many things that make languages faster or slower. It is often
> the case that the more flexibility a language gives you, the harder it is to
> optimize. C++ is fast because it is extremely explicit and much of its logic
> can be optimized and transformed into machine code at compile-time. Python,
> on the other hand, is much more dynamic, and allows the programmer a great
> deal of functionality at run-time. With respect to the lack of lambdas, this
> isn't entirely true. There are lambdas that aren't quite as useful as full
> functions, but Python also supports nested function definitions, and
> functions are first class. Anywhere a lambda can be used, a function can be
> used, and you can define these within a local scope. If most of this flew
> over your head, then take our word for it that Python is how it is to make
> it easier to quickly write solid code. It should also be noted that Python
> makes it easy to write C or C++ extensions, bypassing the overhead when
> speed is needed more than flexibility.
>
> A4. --- see A3
>
> Andy Toulouse
>
>
> On Thu, Jun 19, 2008 at 1:54 PM, Charles Merriam <
> charles.merriam at gmail.com> wrote:
>
>> Hello Shandy,
>>
>> While there isn't a link, here are the frequent questions I see:
>>
>> Q1.  Why is Python case-sensitive?  That is, why is
>> 'bob_is_your_uncle" different from "Bob_is_your_uncle" and
>> "BobIsYourUncle"?
>> A1.  Because Guido said so, it would be too much of a break with older
>> languages, and it encourages a consistent style.
>>
>> Q2.  Why is Python moving to 3.0?  Why is the 'u' tag breaking?  Why
>> change?
>> A2.  Languages evolve or die.  The 'u' tag disappears because purists
>> like to write.
>>
>> Q3.  Why isn't Python the same speed as C++, have lambdas like Lisp,
>> strong typing like Java, etc?
>> A3.  Because it is Python.
>>
>> Q4.  Why isn't Python faster?
>> A4.  It's fast enough for almost everything, and links easily to C/C++
>> code.  It is aimed at quickly writing solid code.
>>
>> Q5.  Why is Pep-8 hard to read?  Why isn't rgruet's quick reference
>> guide part of the Python documentation?  Why don't Python docs link to
>> sample code and a wiki?  Why aren't usual "gotcha's" pointed out in
>> the Python documentation.
>> A5.  Because you haven't rewritten the Python documentation.
>>
>> Q6.  Why is Python so complicated and concise?
>> A7.  Many common problems can be written concisely, so as to save
>> space.  Python works on some consistent rules under the hood, like
>> linear execution within a namespace, which provides an understanding
>> of the concise syntax.
>>
>> Have fun!
>>
>> Charles Merriam
>> _______________________________________________
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
>> http://mail.python.org/mailman/listinfo/baypiggies
>>
>
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20080619/4f2e10e6/attachment-0001.htm>