"Carl Banks" <[EMAIL PROTECTED]> writes:
> Douglas Alan wrote:
>
>> For instance, if Python were to have been designed so that you would
>> write:
>>
>>let myVeryLongVariableName = 3
>>
>> I would have preferred this over
>>
&
rtilley <[EMAIL PROTECTED]> writes:
> Steve Holden wrote:
>> Doug Bromley wrote:
>>> I can see Ruby overtaking Python if we don't ALL do something about it.
> I think it's the name. Python. Let's change it to something nicer.
I agree that names are very important -- Java would never have caught
Andrew Gwozdziewycz <[EMAIL PROTECTED]> writes:
> Douglas Alan wrote:
>> Ruby didn't start catching on until Ruby on Rails came out. If
>> Python has a naming problem, it's with the name of Django, rather
>> than Python. Firstly, Django doesn't h
I've noticed that there is little to no spam in comp.lang.python and
am wondering how this is accomplished. Is there a moderator who
actively cancels spam? If so, that wouldn't seem to prevent spam from
making it through to the mailing list version of the newsgroup. Is
there an exceptionally goo
I couldn't find a good algorithms forum on the Internet, so I guess
I'll ask this question here instead: Is it possible to efficiently
maintain a binary search tree in a flat array (i.e., without using
pointers), as is typically done for a binary heap?
It *is* possible, of course, to keep an order
On Jul 13, 3:57 pm, a...@pythoncraft.com (Aahz) wrote:
> Still, unless your list is large (more than thousands of elements),
> that's the way you should go. See the bisect module. Thing is, the
> speed difference between C and Python means the constant for insertion
> and deletion is very very s
On Jul 14, 7:38 am, Florian Brucker wrote:
> Douglas Alan wrote:
> > Thank you. My question wasn't intended to be Python specific, though.
> > I am just curious for purely academic reasons about whether there is
> > such an algorithm. All the sources I've skimmed
On Jul 14, 8:10 am, Piet van Oostrum wrote:
> Of course you can take any BST algorithm and replace pointers by indices
> in the array and allocate new elements in the array. But then you need
> array elements to contain the indices for the children explicitely.
And why is this a problem? This is
On Jul 14, 9:19 am, Scott David Daniels wrote:
> It may well be that there is no good simple solution, and people avoid
> writing about non-existent algorithms.
I can't imagine why that should be the case. The CLRS textbook on
algorithms, for instance, goes to some pains to mathematically prove
I wrote:
> On Jul 14, 8:10 am, Piet van Oostrum wrote:
>
> > Of course you can take any BST algorithm and replace pointers by indices
> > in the array and allocate new elements in the array. But then you need
> > array elements to contain the indices for the children explicitely.
> And why is t
A friend of mine is just learning Python, and he's a bit tweaked about
how unrecognized escape sequences are treated in Python. This is from
the Python 3.0 reference manual:
Unlike Standard C, all unrecognized escape sequences are left in
the string unchanged, i.e.,
the backslash is left
Steven D'Aprano wrote:
> Why should a backslash in a string literal be an error?
Because in Python, if my friend sees the string "foo\xbar\n", he has
no idea whether the "\x" is an escape sequence, or if it is just the
characters "\x", unless he looks it up in the manual, or tries it out
in the R
On Aug 9, 8:06 pm, Steven D'Aprano wrote:
> while the behaviour your
> friend wants is "treat a backslash as an error, except for these
> exceptions".
Besides, can't all error situations be described as, "treat the error
situation as an error, except for the exception of when the situation
isn't
On Aug 10, 2:03 am, Steven D'Aprano
wrote:
> On Sun, 09 Aug 2009 17:56:55 -0700, Douglas Alan wrote:
> > Because in Python, if my friend sees the string "foo\xbar\n", he has no
> > idea whether the "\x" is an escape sequence, or if it is just the
>
On Aug 10, 2:10 am, Steven D'Aprano
> I've never had any errors caused by this.
But you've seen an error caused by this, in this very discussion.
I.e., "foo\xbar".
"\xba" isn't an escape sequence in any other language that I've used,
which is one reason I made this error... Oh, wait a minute --
On Aug 10, 4:37 am, Steven D'Aprano
> There is at least one good reason for preferring an error, namely that it
> allows Python to introduce new escape codes without going through a long,
> slow process. But the rest of these complaints are terribly unconvincing.
What about:
o Beautiful is b
On Aug 10, 10:58 am, Scott David Daniels
wrote:
> The string rules reflect C's rules, and I see little
> excuse for trying to change them now.
No they don't. Or at least not C++'s rules. C++ behaves exactly as I
should like.
(Or at least g++ does. Or rather *almost* as I would like, as by
defau
From: Steven D'Aprano wrote:
> On Mon, 10 Aug 2009 00:32:30 -0700, Douglas Alan wrote:
> > In C++, if I know that the code I'm looking at compiles,
> > then I never need worry that I've misinterpreted what a
> > string literal means.
> If you don't k
On Aug 11, 2:00 pm, Steven D'Aprano wrote:
> > test.cpp:1:1: warning: unknown escape sequence '\y'
>
> Isn't that a warning, not a fatal error? So what does temp contain?
My "Annotated C++ Reference Manual" is packed, and surprisingly in
Stroustrup's Third Edition, there is no mention of the iss
Steven D'Aprano wrote:
> Because the cost isn't zero. Needing to write \\ in a string
> literal when you want \ is a cost,
I need to preface this entire post with the fact that I've
already used ALL of the arguments that you've provided on my
friend before I ever even came here with the topic, an
On Aug 10, 11:27 pm, Steven D'Aprano
wrote:
> On Mon, 10 Aug 2009 08:21:03 -0700, Douglas Alan wrote:
> > But you're right, it's too late to change this now.
>
> Not really. There is a procedure for making non-backwards compatible
> changes. If you care deeply eno
On Aug 11, 4:38 pm, Ethan Furman wrote:
> Mind you, I'm not really vested in how Python *should* handle
> backslashes one way or the other, but I am glad it has rules that it
> follows for consitent results, and I don't have to break out a byte-code
> editor to find out what's in my string litera
I wrote:
> But you're right, it's too late to change this now.
P.S. But if it weren't too late, I think that your idea to have "\s"
be the escape sequence for a backslash instead of "\\" might be a good
one.
|>ouglas
--
http://mail.python.org/mailman/listinfo/python-list
On Aug 12, 3:08 am, Steven D'Aprano
wrote:
> On Tue, 11 Aug 2009 14:48:24 -0700, Douglas Alan wrote:
> > In any case, my argument has consistently been that Python should have
> > treated undefined escape sequences consistently as fatal errors,
>
> A reasonable positio
On Aug 12, 3:36 am, Steven D'Aprano
wrote:
> On Tue, 11 Aug 2009 13:20:52 -0700, Douglas Alan wrote:
> > My "Annotated C++ Reference Manual" is packed, and surprisingly in
> > Stroustrup's Third Edition, there is no mention of the issue in the
> > entire
On Aug 12, 5:32 am, Steven D'Aprano
wrote:
> That problem basically boils down to a deep-seated
> philosophical disagreement over which philosophy a
> language should follow in regard to backslash escapes:
>
> "Anything not explicitly permitted is forbidden"
>
> versus
>
> "Anything not explicitl
On Aug 12, 7:19 pm, Steven D'Aprano wrote:
> You are making an unjustified assumption: \y is not an error.
You are making in an unjustified assumption that I ever made such an
assumption!
My claim is and has always been NOT that \y is inately an error, but
rather that treating unrecognized esca
On Aug 14, 12:17 pm, Grant Edwards wrote:
> On 2009-08-14, Steven D'Aprano wrote:
> > On Fri, 14 Aug 2009 07:07:31 -0700, Aahz wrote:
> >> "I saw `cout' being shifted "Hello world" times to the left and stopped
> >> right there." --Steve Gonedes
>
> > Assuming that's something real, and not i
On Aug 14, 10:25 pm, Dave Angel wrote:
> Benjamin Kaplan wrote:
> > On Fri, Aug 14, 2009 at 12:42 PM, Douglas Alan wrote:
> >> P.S. Overloading "left shift" to mean "output" does indeed seem a bit
> >> sketchy, but in 15 years of C++ programming,
On Aug 14, 1:55 pm, Steven D'Aprano wrote:
> Douglas, you and I clearly have a difference of opinion on
> this. Neither of us have provided even the tiniest amount
> of objective, replicable, reliable data on the
> error-proneness of the C++ approach versus that of
> Python. The supposed superior
On Aug 15, 5:32 pm, Jaseem wrote:
> Is python similar to actionscript 3.0
For some very rough sense of "similar" it might be, but not really.
> Which is better to create a rich gui internet application?
> Is it AS 3.0 with flex or python with its GUI libs?
Python doesn't run in your typical we
On Aug 15, 8:02 pm, Mike Paul wrote:
> I'm trying to scrap a dynamic page with lot of javascript in it.
> Inorder to get all the data from the page i need to access the
> javascript. But i've no idea how to do it.
I'm not sure exactly what you are trying to do, but scraping websites
that use a l
On Aug 15, 10:19 pm, Steven D'Aprano wrote:
> On Sat, 15 Aug 2009 13:01:43 -0700, Douglas Alan wrote:
> > P.S. I find it strange, however, that anyone who is not okay with
> > "abusing" operator overloading in this manner, wouldn't also take
> > umbra
On Aug 16, 1:05 am, Steven D'Aprano wrote:
> On Sat, 15 Aug 2009 20:00:23 -0700, Douglas Alan wrote:
> > So, as far as I can tell, Python has no real authority to throw stones
> > at C++ on this little tiny particular issue.
> I think you're being a tad over-defensiv
On Aug 16, 4:22 am, Steven D'Aprano wrote:
> I don't like normal assignment. After nearly four decades of mathematics
> and programming, I'm used to it, but I don't think it is especially good.
> It confuses beginners to programming: they get one set of behaviour
> drilled into them in maths clas
On Aug 16, 4:48 am, Erik Max Francis wrote:
> Douglas Alan wrote:
> > Personally, my favorite is Lisp, which looks like
>
> > (set! y (+ y 1))
>
> For varying values of "Lisp." `set!` is Scheme.
Yes, I'm well aware!
There are probably as many
On Aug 16, 8:45 am, MRAB wrote:
> No, APL is strictly right-to-left.
>
> -> x
>
> means "goto x".
>
> Writing to the console is:
>
> [] <- myVar
>
> Reading from the console is:
>
> myVar <- []
Ah, thanks for the correction. It's been 5,000 years since I used APL!
|>ouglas
--
ht
On Aug 16, 6:18 am, Steven D'Aprano wrote:
> On Sun, 16 Aug 2009 01:41:41 -0700, Douglas Alan wrote:
> > I would definitely not like a language that obscures assignment by
> > moving it over to the right side of lines.
> One could argue that left-assigned-from-right
101 - 138 of 138 matches
Mail list logo
