On Wednesday, June 1, 2011 5:53:26 PM UTC-7, Steven D'Aprano wrote:
> On Tue, 31 May 2011 19:45:01 -0700, Carl Banks wrote:
>
> > On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> >> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
> &g
change its meaning from one iteration to the next,
> so a complete name lookup is required at each iteration. This is very
> useful sometimes, but affects performance a lot.
It's main affect performance is that it prevents an optimizer from inlining a
function call(wh
docstring(base):
def set_docstring(f):
f.__doc__ = getattr(base,f.func_name).__doc__
return f
return set_docstring
where you have to repeat the base class every time:
class Bar(Foo):
@inherit_docstring(Foo)
def somefunction(self):
pass
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
wever, I'd be +1 easily on a little help from the language to explicitly
request to inherit the docstring.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Thursday, June 9, 2011 6:42:44 PM UTC-7, Ben Finney wrote:
> Carl Banks
> writes:
>
> > Presumably, the reason you are overriding a method in a subclass is to
> > change its behavior; I'd expect an inherited docstring to be
> > inaccurate more often than not
he worst
that can happen is missing information. If Python does inherit docstrings, it
can lead to incorrect information.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
cstrings, part of that
bargain is that the language will go out of its way to support flat-out wrong
docstrings, and that trumps any ostensible benefit.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Friday, June 10, 2011 2:51:20 AM UTC-7, Steven D'Aprano wrote:
> On Thu, 09 Jun 2011 20:36:53 -0700, Carl Banks wrote:
> > Put it this way: if Python doesn't automatically inherit docstrings, the
> > worst that can happen is missing information. If Python does inher
thing.
That is exactly what I fear, and you are wrong that "we all agree that this
would be a bad thing". Several people in this thread are arguing that
inheriting docstrings by default is the right thing, and that would lead to
heaps of inappropriate documentation.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
self.set(iterable)
def __iter__(self):
return self
def next(self):
return self.current_iter.next()
def set(self,iterable):
self.current_iter = iter(iterable)
s = IteratorByProxy(xrange(10))
for i in s:
print i
if i == 6:
s.set(xrange(15,20))
Ca
; PyMODINIT_FUNC
> initbar(void)
> {
> Py_InitModule("smt.bar", bar_methods);
> }
This should be: Py_InitModule("bar", bar_methods);
That's probably it; other than that, it looks like you did everything right.
What does the installed file layout look like after runni
On Saturday, July 2, 2011 6:35:19 AM UTC-7, H Linux wrote:
> On Jul 2, 2:28 am, Carl Banks
> wrote:
> > On Friday, July 1, 2011 1:02:15 PM UTC-7, H Linux wrote:
> > > Once I try to nest this, I cannot get the module to load anymore:
> > > >import smt.bar
>
licit that the default
arguments are executed only once, when creating the function, *not* when
calling it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ine. Code objects are also used
directly by the interpreter when executing byte code. A function object is
only one of several "interfaces" to a code object.
A minor reason is that code objects are constant (in fact, any object that is
built at compile time must be a
akwebsoft dot com
>
> ## Is it possible to get the module docstring
> ## from the module itself?
print __doc__
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
;, "copyright", "credits" or "license" for more information.
> >>> def foo():
> ... "Docstring"
> ... print __doc__
> ...
> >>> foo()
> None
> >>>
>
> What does yours do?
It prints the module docst
ure codes some mean Python!
That's pretty funny. I knew what it would be even when I saw the cut-off
subject line, and I am too young to remember it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
the top of my head, I can think of
using functools module to help with logging or to apply patches, whereas in
Java they'd have to resort to a code weaver or lots of boilerplate.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
cumentation that is
> in the 'built-in types' section (which could now be called the
> built-isssn classes section.
Built in functions and contructors?
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
rg goes down,
and will help keep the load off the server when it's up.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
#x27;.split(os.sep)
> ['C:/windows']
It's not even fullproof on Unix.
'/home//h1122/bin///ghi/'.split('/')
['','home','','bin','','','ghi','']
The whole point of the os.path functions are to take care of whatever oddities
there are in the path system. When you use string manipulation to manipulate
paths, you bypass all of that and leave yourself open to those oddities, and
then you find your applications break when a user enters a doubled slash.
So stick to os.path.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
nt processes use one mainthread!!
They don't use one main thread; it's just that each process's main thread has
the same name. Which makes sense: when you fork a process all the data in the
process has to remain valid in both parent and child, so any pointers would
have to have the same value (and the -1216477504 happens to be the value of
that pointer cast to an int).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
could have done something like this:
row = [ float(x) for x in re.findall(r'\d+\.\d+e\+d+',line) ]
And regexp matching is often overkill for a particular problem; this may be of
them. line.split() could have been sufficient:
row = [ float(x) for x in line.split() ]
Of course, thes
an argument to the lambda (v) that accepts the int argument
of the signal. If you don't have that argument there, the int argument goes
into x, which is why Python prints 0 instead of "finished".
Second, processess run asynchrously, and because of line-buffering, IO can
output asynchronously, and so there's no guarantee what order output occurs.
You might try calling the python subprocess with the '-u' switch to force
unbuffered IO, which might be enough to force synchronous output (depending on
how signal/slot and subprocess semantics are implemented).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ction like coalesce being helpful if you have a list of
several options to check, though. Also, SQL doesn't give you a lot of
flexibility, so coalesce is a lot more needed there.
But for simple arguments in Python, I'd recommend sticking with "if arg is not
None: arg = whatever"
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
eople
that it will behave this way (not to mention it's a lot more useful). It's
only for the less common and much more advanced case of creating a closure in a
loop that the other behavior would be preferred.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
reak if you need to break further. Something like this, for example:
break_level = 99
while loop1:
while loop2:
while loop3:
if some_condition:
break_level = (1, 2, or 3)
break
if break_level < 3: break
break_level = 99
if break_level < 2: break
break_level = 99
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
evelopers that this stuff would be useful for
positional arugments, too. They just dropped the ball there.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
it has a SQL
extension that allows you to specify error semantics. It looks something like
this:
UPDATE OR IGNORE
UPDATE OR FAIL
UPDATE OR ROLLBACK
I'm not sure exactly how this interacts with pysqlite3, but using one of these
might help it throw exceptions when you want it to.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Friday, September 2, 2011 11:01:17 AM UTC-7, Adam Skutt wrote:
> On Sep 2, 10:53 am, Roy Smith wrote:
> > I have a function I want to run in a thread and return a value. It
> > seems like the most obvious way to do this is to have my target
> > function return the value, the Thread object stas
ece
of data for the different properties. The API provides a void* so that the
extension writer can pass arbitrary data to the get and set functions.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
pes. But I don't want a derived class to
overwrite its parent's entry in the subtype dict--it should define its
own key.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ference, it does increase the reference
count.
I don't know if there's a simple rule to know of a function borrows or
creates a new reference; I've never noticed one.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ypes it means "this is a value of this
type as opposed to None". That causes conflicts when more than one of
those tests makes sense for a given type, as it does with Elements.
This change is only for ElementTree as far as I know. (Incidentally,
Numpy arrays are another notable type that's disabled implicit
booleans, but it did it a long time ago.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ally and reliably, doesn't mean the rest of us
> shouldn't.
Perl works deterministically and reliably. In fact, pretty much every
language works deterministically and reliably. Total non-argument.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 3, 5:16 am, Neil Cerutti wrote:
> On 2011-03-03, Tom Zych wrote:
>
> > Carl Banks wrote:
> >> Perl works deterministically and reliably. In fact, pretty much every
> >> language works deterministically and reliably. Total non-argument.
>
> > We
On Mar 3, 7:12 pm, Carl Banks wrote:
[snip]
Accidental post before I was done. To complete the thought:
I actually can think of one indeterminate behavior in C (although it's
not certain whether this qualifies as interaction with the
environment):
int main(void) {
int a;
printf(
to inline
functions for potentially big speed increases. It can't do that now
because the name of the function can always be rebound to something
else.
BTW, a function object is definitely mutable.
def squared(x):
return x*x
squared.foo = 'bar'
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
:\python32\python bug.py
>
> generates a popup:
>
> python.exe - Application Error
> The exception unknown software exception (0xcfd) occurred in the
> application at location 0x1e08a325.
>
> Click on OK to terminate the program
> Click on CAN
agree with
you. But it's ok, it's not unreasonable to call attention to (actual)
bugs here.
I was surprised, though, when several people confirmed but no one
reported it, especially since it was a crash, which is quite a rare
thing to find. (You should feel proud.)
Carl Banks
--
a clever key function or an
adapter class than the 0.2 seconds I'd save to on sorting time.
Removing cmp from sort was a mistake; it's the most straightforward
and natural way to sort in many cases. Reason enough for me to keep
it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 23, 10:51 am, Stefan Behnel wrote:
> Carl Banks, 23.03.2011 18:23:
>
>
>
>
>
> > On Mar 23, 6:59 am, Stefan Behnel wrote:
> >> Antoon Pardon, 23.03.2011 14:53:
>
> >>> On Sun, Mar 13, 2011 at 12:59:55PM +, Steven D'Aprano wrote:
&g
On Mar 23, 1:38 pm, Paul Rubin wrote:
> Carl Banks writes:
> > It's kind of ridiculous to claim that cmp adds much complexity (it's
> > maybe ten lines of extra C code), so the only reason not to include it
> > is that it's much slower than using key.
>
&
an just write their own cmp
function, and as an added bonus they can work around any peculiarities
with an incomplete comparison set.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
also
want to avoid boilerplate of binding all of them explicitly.
Not a common use case, but it happens. (I've faced it several times,
but the things I work on make it more common for me. I bit the bullet
and wrote out the boilerplate.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e to on sorting
time." (Fits your criterion "performs really badly when done so".)
3. You evidently also overlooked the use-case example posted on Python-
dev that you followed up to.
Call me crazy, but you seem to be overlooking a lot of things in your
zeal to prove your point.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
in reason they're not builtin is that they aren't
really that simple. The functions make use of a lot of knowledge
about Python types. Builtins tend to be for straightforward, simple,
building-block type functions.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
be possible but not too practical or likely.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
dler, and it is incorrect to say it is not. The
call to HomeHandler does create an instance of BaseHandler.
The Python language itself validates this usage. isinstance(test,BaseHandler)
returns True.
If you are looking for a term to indicate an object for which type(test) ==
BaseHandler, then I would suggest "proper instance". test is an instance of
BaseHandler, but it is not a proper instance.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
y in base.__dict__.keys():
u[key] += 1
for key in dct.keys():
u[key] += 1
if any(u[key] > 1 for key in u.keys()):
raise TypeError("base classes and this class share some class
attributes")
return type.__new__(metatype,na
On Thursday, April 28, 2011 6:43:35 PM UTC-7, Ethan Furman wrote:
> Carl Banks wrote:
> > The sorts of class that this decorator will work for are probably not
> > the ones that are going to have problems cooperating in the first place.
> > So you might as well just use
On Friday, April 29, 2011 2:44:56 PM UTC-7, Ian wrote:
> On Fri, Apr 29, 2011 at 3:09 PM, Carl Banks
> wrote:
> > Here is my advice on mixins:
> >
> > Mixins should almost always be listed first in the bases. (The only
> > exception is to work around a technicali
sually
catch StopIteration whenever calling send() or next() by hand. Untested:
result = None
while True:
try:
item = provider.send(result)
except StopIteration:
break
try:
consumer.handleItem(item)
except:
result = 'failure'
else:
result = 'success'
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
list tells us
nothing. In any case it's ridiculous to claim envy as factor nowadays, as
Python is clearly on the rise while Perl is on the decline. Few people are
choosing Perl for new projects.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
e I
don't have Python 3 handy to test it, but as far as I can tell it will.)
It's just one of the quirks of Python's type system.
I don't agree with Ian's recommendation not to use super() in general, but I'd
probably agree that one should stick to using it only in its intended way (to
invoke base-class methods directly).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
er looks pretty useless for .startswith() and
is probably only present for consistency with other string search methods like
.index(). Yet on .index() using None as an argument works as intended:
>>> "cbcd".index("c",None,None)
0
So it's there for consistency, yet is not consistent.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
\b # beginning of line
> (?P\w+) # a word
> \s+# some whitespace
> (?P=word)(?!\w)# the same word again
>"""
> double_word_re = re.compile(pattern, re.I | re.X)
Perl has the X fla
to handle exceptional conditions.
The only reason to keep NaN's current behavior is to adhere to IEEE, but given
that Python has trailblazed a path of correcting arcane mathematical behavior,
I definitely see an argument that Python should do the same for NaN, and if it
were done Python would be a better language.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ver be used as a dictionary key
or in a set (of course).
If it weren't for compatibility with IEEE, there would be no sane argument that
defining an object that is not equal to itself isn't a bug. But because
there's a lot of code out there that depends on NaN != NaN, Python has to
tolerate it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Sunday, May 29, 2011 6:14:58 PM UTC-7, Chris Angelico wrote:
> On Mon, May 30, 2011 at 10:55 AM, Carl Banks
> wrote:
> > If exceptions had commonly existed in that environment there's no chance
> > they would have chosen that behavior; comparison against NaN (or any
On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
>
> > Floating point arithmetic evolved more or less on languages like Fortran
> > where things like exceptions were unheard of,
>
> I
er"?
The former. Unlike the case with integers, there is no way that I know of to
represent an abstract real number on a digital computer.
Python also includes several IEEE-defined operations in its library
(math.isnan, math.frexp).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Tuesday, May 31, 2011 8:05:43 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks
> wrote:
> > On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
> >> Okay, here's a question. The Python 'float' value - is it meant to
On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks
> wrote:
> > I think you misunderstood what I was saying.
> >
> > It's not *possible* to represent a real number abstractly in any digital
> >
On Wednesday, June 1, 2011 10:17:54 AM UTC-7, OKB (not okblacke) wrote:
> Carl Banks wrote:
>
> > On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> >> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote:
> > Python has several non-integer number types
On Wednesday, June 1, 2011 11:10:33 AM UTC-7, Ethan Furman wrote:
> Carl Banks wrote:
> > For instance, say you are using an implementation that uses
> > floating point, and you define a function that uses Newton's
> > method to find a square root:
> >
> >
Reinhold Birkenfeld wrote:
> X if C else Y
Oh well. Just about any conditional is better than no conditional.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
_hash__(self):
return hash((self.obj.att_a,self.obj.att_b))
set_a = set(CmpProxy(x) for x in list_a)
set_b = set(CmpProxy(y) for y in list_b)
overlaps = [ z.obj for z in set_a.intersection(set.b) ]
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
hanging each of
> the calls to the Element(), SubElement(), XML() and tostring() methods.
Well, if you arrange it as I advise, you shouldn't have a problem.
However, if you want to change only the import statements, you don't
want to do this:
import elementtree.ElementTree
That will import ElementTree but the you'd have to access it as
elementtree.ElementTree. Instead you should do this:
from elementtree import ElementTree
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
rgs):
use(kwargs['x'])
class B(object):
def __init__(self,**kwargs):
use(kwargs['y'])
class C(A,B):
def __init__(self,**kwargs):
super(C,self).__init__(**kwargs)
C(x=1,y=2)
> I'm probably overlooking some basic stuff here
iness. For
instance, a foolproof way to avoid name clashes in mixin classes would
require a complete overhaul of namespaces in Python, and that is not
going to happen.
At best, what you might get is some sort of protocol (maybe a
decorator) that standardizes calling the base class methods, coupled
with a very strong suggestion to use it in all future code for all
classes.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ng, based on the description, and it's not like th BDFL
to throw out keywords for things that current syntax can handle. It
leads me to suspect that maybe he has something up his sleeve. Hmm.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
. >>> "abcd".encode("base64")
This is an encoding between two byte strings.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
other.
The Zen of Python says that "simple is better than complex" and
"complex is better than complicated". Java does pretty well here. C++
didn't even get "complicated is better than convoluted" right. There's
are a ton of flaws in C++ not found in Ja
r types",
which is not what you're doing, so it doesn't apply here. For built-in
types, iterators are at work. The list iterator probably doesn't even
call getitem, but accesses the items directly from the C structure.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
it'll proceed to
compare the objects themselves, which could throw an exception.
Stick the index in there, and that possibility is gone.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
r for each loop (since it's physically outside the loop
part).
One question: what do you do with a variable bound inside a while-block
that has the same name as a local variable? (Or, horrors, a
surrounding while-block?) I'm inclined to think it should be illegal,
but maybe it would be too restrictive.
Anyways, I like this idea a lot.
+1
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
you will. Under this suggestion, there
would be modified versions of various simple statements.
This wouldn't be a problem parsing, of course, because "where" would be
a keyword.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
for
clarification ;-)
That's ok. For it fly, it's got to be able to withstand the flak.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > You misunderstand.
BTW, Peter, I guess I should have said "I misunderstand, but it can be
legal if you consider it part of the statements", since it appears the
author did intend it to be part o
the if-expression and the if-block.
It (or your suggestion) could work with a while-loop too.
. while line where line=f.readline():
. do_something_with(line)
The main problem here (as some would see it) is that you can't do
something this:
. if m > 20 where (def m(): a(); b()):
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Nick Coghlan wrote:
> Carl Banks wrote:
> > What if the condition you wanted to test wasn't the same as the
thing
> > you want to save? In other words, how would you convert this?
> >
> > . where:
> > . m = something()
> > . if m > 20:
> &
expression, then m would have to be either be visible within
the whole surrounding scope, or just within that expression.
What I proposed was really nothing more than a convenient way to sneak
an extra binding inside an elif clause. (The real point here is not to
use this on if-clauses, but on elif-clauses.)
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
of LISP supports the Zen of
Python.
If I wanted to use LISP, I'd be using LISP. But I like my statements
and expressions distinct. I like things that belong in statements to
stay in statements, and things that belong in expressions to stay in
expressions.
And a suite, be it a def statement,
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > And a suite, be it a def statement, a where block, or whatever,
belongs
> > in a statement, not an expression.
>
> So do you approve of the movement to get rid of the print statement?
Any li
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > > So do you approve of the movement to get rid of the print
statement?
> >
> > Any little incremental change in Python you could make by having or
not
> > having a print stat
; it looks to me like the dogma is +12 for macros. What are your
thoughts?
Paul,
When I asked you to do this, it was just a rhetorical way to tell you
that I didn't intend to play this game. It's plain as day you're
trying to get me to admit something. I'm not falling for it.
If you have a point to make, why don't you just make it?
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
> > When I asked you to do this, it was just a rhetorical way to tell
you
> > that I didn't intend to play this game. It's plain as day you're
> > trying to get me to admit something.
to local names becomes the initial value
> of the class __dict__). So, e.g.,
>
> i = i1 = 3
> let:
> i1 = i+1
> from math import sqrt
> in:
> print i1, sqrt(i1)
> print i1,
> print sqrt(i1)
>
> would print
>
>
It's me wrote:
> The world would come to a halt if all of a sudden nobody understands
complex
> numbers anymore. :-)
Actually, it would oscillate out of control.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
ided
> a few uses, but no formal definition (maybe it's a European phrase so
> searching for it in English is futile). The closest thing I found
was
>
> Or is it another case of Belgian logic, where you believe it
because
> theres no evidence or motive whatsoever?
Maybe
types as required. :)
Ok.
http://www.urbandictionary.com/define.php?term=belgian&r=f
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
rganize the standard library into an intricate feudal hierarchy of
packages, modules, and cross-references." :)
The gist of "Flat is better than nested" is "be as nested as you have
to be, no more," because being too nested is just a mess.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
e a
duck, it's made of wood.)
The flat method of polymorphism is so much better it isn't even funny.
Again, Python chose wisely.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Timothy Fitz wrote:
> On 19 Jan 2005 15:24:10 -0800, Carl Banks
<[EMAIL PROTECTED]> wrote:
> > The gist of "Flat is better than nested" is "be as nested as you
have
> > to be, no more," because being too nested is just a mess.
>
> Which I agree with
erator" (where callable is a name, not a
description), appearing in a different context from where it was coined
that causes us to parse it differently (where callable is a
description, not a name), and accidentally stating an absurdity.
I'd say it's actually a nice bit of subtlety.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
se it, all I can think of is how much better this POS would
be if they had just extended Python (probably would even be faster).
At least they were smart enough to (try to) make it into a complete
programming language.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
Roy Smith wrote:
> "Carl Banks" <[EMAIL PROTECTED]> wrote:
>
> > > Imbed
> > EMBED.
>
> My apologies for being sloppy. And with an initial capital, so it
just
> jumps off the page at you :-)
Ok. Prescriptive language isn't normally my cup of t
pest, that his claims are untrue and his advice is not
good, and that he appears that his posts are just trolling in disguise.
(Or, you could do what I do when I feel a need to reply: follow-up with
a Flame Warriors link. For Xah, it would probably be this:
http://tinyurl.com/4vor3 )
--
CARL
eir tendency to rebind variables
too much? Just a thought.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
1 - 100 of 1709 matches
Mail list logo
