Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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

Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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

Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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

Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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

Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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

Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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

Re: Python- javascript

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

Re: Python or ActionScript 3.0

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

Re: Unrecognized escape sequences in string literals

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

Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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,

Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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 >

Re: Unrecognized escape sequences in string literals

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

Re: Unrecognized escape sequences in string literals

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

Unrecognized escape sequences in string literals

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

Re: Efficient binary search tree stored in a flat array?

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

Re: Efficient binary search tree stored in a flat array?

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

Re: Efficient binary search tree stored in a flat array?

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

Re: Efficient binary search tree stored in a flat array?

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

Re: Efficient binary search tree stored in a flat array?

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

Efficient binary search tree stored in a flat array?

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

Re: Finding the instance reference of an object

Joe Strout <[EMAIL PROTECTED]> writes: >> Q. What type of calling semantics do Python and Java use? >> >> A. Call-by-sharing. > > Fair enough, but if the questioner then says "WTF is call-by-sharing," > we should answer "call-by-sharing is the term we prefer for call-by- > value in the case wh

Re: Finding the instance reference of an object

greg <[EMAIL PROTECTED]> writes: > Steven D'Aprano wrote: >> At least some sections of the Java community seem to prefer a >> misleading and confusing use of the word "value" over clarity and >> simplicity, but I for one do not agree with them. > I don't see anything inherently confusing or misl

Re: Finding the instance reference of an object

Joe Strout <[EMAIL PROTECTED]> writes: > Yes, OK, that's great. But there are several standard pass-by- > somethings that are defined by the CS community, and which are simple > and clear and apply to a wide variety of languages. "Pass by object" > isn't one of them. "Call-by-sharing" *is* one

Re: Finding the instance reference of an object

Joe Strout <[EMAIL PROTECTED]> writes: > As for where I get my definitions from, I draw from several sources: > > 1. Dead-tree textbooks You've been reading the wrong textbooks. Read Liskov -- she's called CLU (and hence Python's) calling strategy "call-by-sharing" since the 70s. > 2. Wikipedia

Re: Finding the instance reference of an object

greg <[EMAIL PROTECTED]> writes: > Douglas Alan wrote: >> greg <[EMAIL PROTECTED]> writes: > >>> This holds for *all* languages that I know about, both static and >>> dynamic. > >> Then you don't know about all that many languages. There ar

Re: Finding the instance reference of an object

greg <[EMAIL PROTECTED]> writes: > Douglas Alan wrote: >> greg <[EMAIL PROTECTED]> writes: >> >>>Seems to me that (1) describes exactly how parameter passing >>>works in Python. So why insist that it's *not* call by value? >> Beca

Re: Finding the instance reference of an object

Joe Strout <[EMAIL PROTECTED]> writes: > There are only the two cases, which Greg quite succinctly and > accurately described above. One is by value, the other is by > reference. Python quite clearly uses by value. You make a grave error in asserting that there are only two cases. Algol, for in

Re: Finding the instance reference of an object

greg <[EMAIL PROTECTED]> writes: > Seems to me that (1) describes exactly how parameter passing > works in Python. So why insist that it's *not* call by value? Because there's an important distinction to be made, and the distinction has been written up in the Computer Science literature since Lis

Re: Finding the instance reference of an object

Steven D'Aprano <[EMAIL PROTECTED]> writes: > I understand that Python's object and calling semantics are exactly the > same as Emerald (and likely other languages as well), and that both > Emerald and Python are explicitly based on those of CLU, as described by > by Barbara Liskov in 1979: > >

Re: The best platform and editor for Python

[EMAIL PROTECTED] (Alex Martelli) writes: > Kay Schluehr <[EMAIL PROTECTED]> wrote: >> half of the community is happy with Emacs and the other half wants to >> program in a VS-like environment, neither consensus nor progress has > Calling all vi/vim users (and we'll heartily appreciate the suppo

Re: Python's "only one way to do it" philosophy isn't good?

Steve Holden <[EMAIL PROTECTED]> writes: >> I'm relying on a feature that has worked fine since the early '90s, >> and if it is ever changed in the future, I'm sure that plenty of other >> language changes will come along with it that will make adapting code >> that relies on this feature to be th

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: >> And why would you do that? People rely very heavily in C++ on when >> destructors will be called, and they are in fact encouraged to do so. >> They are, in fact, encouraged to do so *so* much that constructs like >> "finally" and "with" have been reje

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: > Sure, but thats part of the general refcounting vs GC argument - > refcounting gives (a certain level of) timeliness in resource > collection, GC often only runs under memory pressure. If you're > saying that we should keep refcounting because it provid

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: >> Some people here have been arguing that all code should use "with" to >> ensure that the files are closed. But this still wouldn't solve the >> problem of the large data structures being left around for an >> arbitrary amount of time. > I don't think

Re: Python's "only one way to do it" philosophy isn't good?

Lenard Lindstrom <[EMAIL PROTECTED]> writes: >> Also, any caught exception is automatically cleared when >> the catching procedure returns anyway, so it's not like Python has >> ever considered a caught exception to be precious information that >> ought to be preserved long past the point where it

Re: Python's "only one way to do it" philosophy isn't good?

Lenard Lindstrom <[EMAIL PROTECTED]> writes: >> I'm not sure I understand you here. You're saying that I should have >> the foresight to wrap all my file opens is a special class to >> facilitate debugging? > Obviously you had the foresight to realize with statements could > compromise debugging

Re: Python's "only one way to do it" philosophy isn't good?

Lenard Lindstrom <[EMAIL PROTECTED]> writes: >> You don't necessarily want a function that raises an exception to >> deallocate all of its resources before raising the exception, since >> you may want access to these resources for debugging, or what have >> you. > No problem: > > [...] > > >>> c

Re: Python's "only one way to do it" philosophy isn't good?

Lenard Lindstrom <[EMAIL PROTECTED]> writes: >>> Explicitly clear the exception? With sys.exc_clear? >> Yes. Is there a problem with that? > As long as nothing tries to re-raise the exception I doubt it breaks > anything: > > >>> import sys > >>> try: > raise StandardError("Hello") > ex

Re: Python's "only one way to do it" philosophy isn't good?

I wrote: > P.S. The last time I took a language class (about five or six years > ago), the most interesting languages I thought were descended from > Self, not any functional language. (And Self, of course is descended > from Smalltalk, which is descended from Lisp.) I think that Cecil is the p

Re: Python's "only one way to do it" philosophy isn't good?

Lenard Lindstrom <[EMAIL PROTECTED]> writes: > Explicitly clear the exception? With sys.exc_clear? Yes. Is there a problem with that? |>oug -- http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

Paul Rubin writes: > Haskell and ML are both evaluate typed lambda calculus unlike Lisp > which is based on untyped lambda calculus. Certainly the most > familiar features of Lisp (dynamic typing, S-expression syntax, > programs as data (Lisp's macro system results from

Re: Python's "only one way to do it" philosophy isn't good?

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Douglas Alan <[EMAIL PROTECTED]> writes: >> P.S. Besides Haskell is basically a refinement of ML, which is a >> dialect of Lisp. > I'd say Haskell and ML are descended from Lisp, just like mammals are > de

Re: Python's "only one way to do it" philosophy isn't good?

Michele Simionato <[EMAIL PROTECTED]> writes: >> Right. So? I understand this issue completely and I code >> accordingly. > What does it mean you 'code accordingly'? IMO the only clean way out > of this issue is to NOT rely on the garbage collector and to manage > resource deallocation explicit

Re: Python's "only one way to do it" philosophy isn't good?

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Douglas Alan <[EMAIL PROTECTED]> writes: >> But that's a library issue, not a language issue. The technology >> exists completely within Lisp to accomplish these things, and most >> Lisp programmers ev

Re: Python's "only one way to do it" philosophy isn't good?

Lenard Lindstrom <[EMAIL PROTECTED]> writes: > Douglas Alan wrote: >> [I]n Python, you can be 100% sure that your files >> will be closed in a timely manner without explicitly closing them, as >> long as you are safe in making certain assumptions about how your

Re: Python's "only one way to do it" philosophy isn't good?

Duncan Booth <[EMAIL PROTECTED]> writes: >> A precondition of much of my Python code is that callers won't >> squirrel away large numbers of tracebacks for long periods of time. I >> can live with that. Another precondition of much of my code is that >> the caller doesn't assume that it is threa

Re: Python's "only one way to do it" philosophy isn't good?

Steve Holden <[EMAIL PROTECTED]> writes: > "Python" doesn't *have* any refcounting semantics. I'm not convinced that Python has *any* semantics at all outside of specific implementations. It has never been standardized to the rigor of your typical barely-readable language standards document. >

Re: Python's "only one way to do it" philosophy isn't good?

Hrvoje Niksic <[EMAIL PROTECTED]> writes: >> Generators aren't slower than hand-coded iterators in *Python*, but >> that's because Python is a slow language. > But then it should be slow for both generators and iterators. Python *is* slow for both generators and iterators. It's slow for *everyt

Re: Python's "only one way to do it" philosophy isn't good?

Jean-Paul Calderone <[EMAIL PROTECTED]> writes: >>On the other hand, in Python, you can be 100% sure that your files >>will be closed in a timely manner without explicitly closing them, as >>long as you are safe in making certain assumptions about how your code >>will be used. Such assumptions ar

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: >> On the other hand, in Python, you can be 100% sure that your files >> will be closed in a timely manner without explicitly closing them, as >> long as you are safe in making certain assumptions about how your code >> will be used. Such assumptions are

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: > You're arguing against explicit resource management with the argument > that you don't need to manage resources. Can you not see how > ridiculously circular this is? No. It is insane to leave files unclosed in Java (unless you know for sure that your

Re: Python's "only one way to do it" philosophy isn't good?

Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > LISP and FORTH are cousins... Not really. Their only real similarity (other than the similarities shared by most programming languages) is that they both use a form of Polish notation. |>oug -- http://mail.python.org/mailman/listinfo/python

Re: Python's "only one way to do it" philosophy isn't good?

Michele Simionato <[EMAIL PROTECTED]> writes: >> I've written plenty of Python code that relied on destructors to >> deallocate resources, and the code always worked. > You have been lucky: No I haven't been lucky -- I just know what I'm doing. > $ cat deallocating.py > import logging > > class

Re: Python's "only one way to do it" philosophy isn't good?

Hrvoje Niksic <[EMAIL PROTECTED]> writes: > Douglas Alan <[EMAIL PROTECTED]> writes: >> I think you overstate your case. Lispers understand iteration >> interfaces perfectly well, but tend to prefer mapping fuctions to >> iteration because mapping functions are

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: > Obviously. But theres nothing about the with statement that's > different than using smart pointers in this regard. Sure there is -- smart pointers handle many sorts of situations, while "with" only handles the case where the lifetime of the object cor

Re: Python's "only one way to do it" philosophy isn't good?

Steve Holden <[EMAIL PROTECTED]> writes: >> Actually, it's "chacun". And the "à" may precede the "chacun". >> |>oug > "chacun" is an elision of the two words "Chaque" (each) and "un" > (one), and use of those two words is at least equally correct, though > where it stands in modern usage I must

Re: Python's "only one way to do it" philosophy isn't good?

Steve Holden <[EMAIL PROTECTED]> writes: > Douglas Woodrow wrote: >> On Wed, 27 Jun 2007 01:45:44, Douglas Alan <[EMAIL PROTECTED]> wrote >>> A chaque son gout >> I apologise for this irrelevant interruption to the conversation, >> but this isn'

Re: Python's "only one way to do it" philosophy isn't good?

Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > But if these "macros" are supposed to allow one to sort of extend > Python syntax, are you really going to code things like > > macrolib1.keyword > everywhere? No -- I would expect that macros (if done the way that I would like them to b

Re: Python's "only one way to do it" philosophy isn't good?

Douglas Woodrow <[EMAIL PROTECTED]> writes: > On Wed, 27 Jun 2007 01:45:44, Douglas Alan <[EMAIL PROTECTED]> wrote >>A chaque son gout > I apologise for this irrelevant interruption to the conversation, but > this isn't the first time you've written that.

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: > On 6/27/07, Douglas Alan <[EMAIL PROTECTED]> wrote: >> The C++ folks feel so strongly about this, that they refuse to provide >> "finally", and insist instead that you use destructors and RAII to do

Re: Python's "only one way to do it" philosophy isn't good?

"Chris Mellon" <[EMAIL PROTECTED]> writes: > Is this where I get to call Lispers Blub programmers, because they > can't see the clear benefit to a generic iteration interface? I think you overstate your case. Lispers understand iteration interfaces perfectly well, but tend to prefer mapping fuct

Re: Python's "only one way to do it" philosophy isn't good?

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Douglas Alan <[EMAIL PROTECTED]> writes: >> > In the Maclisp era functions like mapcar worked on lists, and >> > generated equally long lists in memory. >> I'm aware, but there were various different

Re: Python's "only one way to do it" philosophy isn't good?

Paul Rubin writes: > Andy Freeman <[EMAIL PROTECTED]> writes: >> Compare that with what a programmer using Python 2.4 has to do if >> she'd like the functionality provided by 2.5's with statement. Yes, >> with is "just syntax", but it's extremely useful syntax, syntax

Re: Python's "only one way to do it" philosophy isn't good?

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Douglas Alan <[EMAIL PROTECTED]> writes: >> I will certainly admit that Lisp programmers at the time were (and >> likely still are) much more enamored of mapping functions than of >> iterators. Mapping functi

Re: Python's "only one way to do it" philosophy isn't good?

Alexander Schmolck <[EMAIL PROTECTED]> writes: > Douglas Alan <[EMAIL PROTECTED]> writes: >>> Python has built-in abstractions for a few container types like >>> lists and dicts, and now a new and more general one (iterators), so >>> it's the n

Re: Python's "only one way to do it" philosophy isn't good?

Paul Rubin <http://[EMAIL PROTECTED]> writes: > Douglas Alan <[EMAIL PROTECTED]> writes: >> And likewise, good macro programming can solve some problems that no >> amount of linting could ever solve. > I think Lisp is more needful of macros than other langu

Re: Python's "only one way to do it" philosophy isn't good?

Michele Simionato <[EMAIL PROTECTED]> writes: > You should really be using pychecker (as well as Emacs autocompletion > feature ...): I *do* use Emacs's autocompletion, but sometimes these sorts of bugs creep in anyway. (E.g., sometimes I autocomplete in the wrong variable!) > ~$ pychecker -v x

Re: Python's "only one way to do it" philosophy isn't good?

Graham Breed <[EMAIL PROTECTED]> writes: > Another way is to decorate functions with their local variables: from strict import my @my("item") > ... def f(x=1, y=2.5, z=[1,2,4]): > ... x = float(x) > ... w = float(y) > ... return [item+x-y for item in z] Well, I suppose that

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: >> You seem oblivious to the fact that one of the huge benefits of Python >> is its elegant and readable syntax. The problem with not having a >> "flexible syntax", is that a programming language can't provide >> off-the-shelf an elegant syntax for all

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Sat, 23 Jun 2007 14:56:35 -0400, Douglas Alan wrote: > >>> How long did it take you to write the macros, and use them, compared >>> to running Pylint or Pychecker or equivalent? >> An hour? Who cares? Y

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: > But if you really want declarations, you can have them. > import variables variables.declare(x=1, y=2.5, z=[1, 2, 4]) variables.x = None variables.w = 0 > Traceback (most recent call last): > File "", line 1, in > File "variabl

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: >> So one use for macros would be so that I can define "let" and "set" >> statements so that I might code like this: >> >> let longVariableName = 0 >> set longVarableName = foo(longVariableName) >> >> Then if longVarableName didn't already ex

Re: Python's "only one way to do it" philosophy isn't good?

Michele Simionato <[EMAIL PROTECTED]> writes: > Been there, done that. So what? Your example will not convince any > Pythonista. I'm a Pythonista, and it convinces me. > The Pythonista expects Guido to do the language job and the > application developer to do the application job. I'm happy to h

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: > Nevertheless, in Python 1+2 always equals 3. You can't say the same thing > about Lisp. Well, I can't say much of *anything* about "1 + 2" in Lisp, since that's not the syntax for adding numbers in Lisp. In Lisp, numbers are typically added using the

Re: Python's "only one way to do it" philosophy isn't good?

"Terry Reedy" <[EMAIL PROTECTED]> writes: > "Douglas Alan" <[EMAIL PROTECTED]> wrote in message > | "Terry Reedy" <[EMAIL PROTECTED]> writes: > | > I think this points to where Sussman went wrong in his footnote > | > and Al

Re: Python's "only one way to do it" philosophy isn't good?

"Terry Reedy" <[EMAIL PROTECTED]> writes: > | But why is the ability to abstract syntax good? > I think this points to where Sussman went wrong in his footnote and > Alan in his defense thereof. Flexibility of function -- being able > to do many different things -- is quite different from flexib

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Thu, 21 Jun 2007 15:25:37 -0400, Douglas Alan wrote: >> You are imagining something very different from what is proposed. >> Lisp-like macros don't allow "anything goes". > Provided people avoid do

Re: Python's "only one way to do it" philosophy isn't good?

"Terry Reedy" <[EMAIL PROTECTED]> writes: > "Douglas Alan" <[EMAIL PROTECTED]> wrote in message > | > But why is the ability to abstract syntax good? > | It allows the community to develop language features in a modular way > | without having

Re: Python's "only one way to do it" philosophy isn't good?

Neil Cerutti <[EMAIL PROTECTED]> writes: > That said, I wouldn't give up the summer I spent studying _Simply > Scheme_. Sounds like fun. Is this like a kinder, gentler version of SICP? I'm not sure, though, that I could have learned computer science properly without the immortal characters of B

Re: Python's "only one way to do it" philosophy isn't good?

"Terry Reedy" <[EMAIL PROTECTED]> writes: > | It allows the community to develop language features in a modular way > | without having to sully the code base for the language itself. > [etc] > Some of the strongest opposition to adding macros to Python comes > from people like Alex Martelli who h

Re: Python's "only one way to do it" philosophy isn't good?

Neil Cerutti <[EMAIL PROTECTED]> writes: >>> But why is the ability to abstract syntax good? >> It allows the community to develop language features in a >> modular way without having to sully the code base for the >> language itself. > That's not an advantage exclusive to macros, though. No,

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Wed, 20 Jun 2007 17:23:42 -0400, Douglas Alan wrote: >> Macros are a way to abstract syntax the way that objects are used to >> abstract data types and that iterators and generators abstract control, >> etc. >

Re: Python's "only one way to do it" philosophy isn't good?

Robert Kern <[EMAIL PROTECTED]> writes: >> The problem with Python's model is that you >> have to wait for a rather centralized process to agree on and >> implement such a feature. > No, you don't. Philip Eby has been working on various incarnations > of generic functions for some time now. The o

Re: Python's "only one way to do it" philosophy isn't good?

Michele Simionato <[EMAIL PROTECTED]> writes: > In practice Scheme follows exactly the opposite route: there are > dozens of different and redundant object systems, module systems, > even record systems, built just by piling up feature over feature. The solution to this is to have a standard libr

Re: Python's "only one way to do it" philosophy isn't good?

asses, and that those people have created Python so I don't have > to. And I suspect that for every Douglas Alan enamored with Scheme, > there are ten thousand programmers who just want to use a handful of > pre-built tools to get the work done, never mind using macros to > cre

Re: Python's "only one way to do it" philosophy isn't good?

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Tue, 19 Jun 2007 20:16:28 -0400, Douglas Alan wrote: >> Steven D'Aprano <[EMAIL PROTECTED]> writes: >>> On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote: >> The problem with using Scheme for re

  1   2   >