Canonical way of dealing with null-separated lines?

Is there a canonical way of iterating over the lines of a file that are null-separated rather than newline-separated? Sure, I can implement my own iterator using read() and split(), etc., but considering that using "find -print0" is so common, it seems like there should be a more cannonical way.

Re: Canonical way of dealing with null-separated lines?

Christopher De Vries <[EMAIL PROTECTED]> writes: > I'm not sure if there is a canonical method, but I would > recommending using a generator to get something like this, where 'f' > is a file object: Thanks for the generator. It returns an extra blank line at the end when used with "find -print0"

Re: Canonical way of dealing with null-separated lines?

Okay, here's the definitive version (or so say I). Some good doobie please make sure it makes its way into the standard library: def fileLineIter(inputFile, newline='\n', leaveNewline=False, readSize=8192): """Like the normal file iter but you can set what string indicates newline. You can

Re: Canonical way of dealing with null-separated lines?

I wrote: > Okay, here's the definitive version (or so say I). Some good doobie > please make sure it makes its way into the standard library: Oops, I just realized that my previously definitive version did not handle multi-character newlines. So here is a new definition version. Oog, now my br

yield_all needed in Python

While writing a generator, I was just thinking how Python needs a "yield_all" statement. With the help of Google, I found a pre-existing discussion on this from a while back in the Lightweight Languages mailing list. I'll repost it here in order to improve the chances of this enhancement actually

Re: Canonical way of dealing with null-separated lines?

I wrote: > Oops, I just realized that my previously definitive version did not > handle multi-character newlines. So here is a new definitive > version. Oog, now my brain hurts: I dunno what I was thinking. That version sucked! Here's a version that's actually comprehensible, a fraction of th

Re: yield_all needed in Python

Andrew Dalke <[EMAIL PROTECTED]> writes: > On Mon, 28 Feb 2005 18:25:51 -0500, Douglas Alan wrote: >> While writing a generator, I was just thinking how Python needs a >> "yield_all" statement. With the help of Google, I found a >> pre-existing discus

Re: yield_all needed in Python

"Terry Reedy" <[EMAIL PROTECTED]> writes: > Cetainly, if iterator> == , I don't see how anything > is gained except for a few keystrokes. What's gained is making one's code more readable and maintainable, which is the one of the primary reasons that I use Python. |>oug -- http://mail.python.or

Re: Canonical way of dealing with null-separated lines?

"John Machin" <[EMAIL PROTECTED]> writes: >>lines = (partialLine + charsJustRead).split(newline) > The above line is prepending a short string to what will typically be a > whole buffer full. There's gotta be a better way to do it. If there is, I'm all ears. In a previous post I provide

Re: yield_all needed in Python

Duncan Booth <[EMAIL PROTECTED]> writes: > Douglas Alan wrote: >> "Terry Reedy" <[EMAIL PROTECTED]> writes: >>> Cetainly, if >> iterator> == , I don't see how anything >>> is gained except for a few keystrokes. >> What'

Re: yield_all needed in Python

Francis Girard <[EMAIL PROTECTED]> writes: > Therefore, the suggestion you make, or something similar, would have > actually ease my learning, at least for me. Yes, I agree 100%. Not having something like "yield_all" hurt my ability to learn to use Python's generators quickly because I figured t

Re: yield_all needed in Python

David Eppstein <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > Douglas Alan <[EMAIL PROTECTED]> wrote: >> > Cetainly, if > > iterator> == , I don't see how anything >> > is gained except for a few keystrokes. >> Wha

Re: yield_all needed in Python

Steve Holden <[EMAIL PROTECTED]> writes: > Guido has generally observed a parsimony about the introduction of > features such as the one you suggest into Python, and in particular > he is reluctant to add new keywords - even in cases like decorators > that cried out for a keyword rather than the u

Re: Canonical way of dealing with null-separated lines?

"John Machin" <[EMAIL PROTECTED]> writes: >> In Python, >>longString + "" is longString >> evaluates to True. I don't know how you can do nothing more >> gracefully than that. > And also "" + longString is longString > The string + operator provides those graceful *external* results by >

Re: yield_all needed in Python

Steven Bethard <[EMAIL PROTECTED]> writes: > I'm guessing the * syntax is pretty unlikely to win Guido's > approval. There have been a number of requests[1][2][3] for syntax > like: > x, y, *rest = iterable Oh, it is so wrong that Guido objects to the above. Python needs fully destructurin

Re: yield_all needed in Python

Isaac To <[EMAIL PROTECTED]> writes: >> "Isaac" == Isaac To <[EMAIL PROTECTED]> writes: > > def gen_all(gen): > for e in gen: > yield e > > def foogen(arg1): > def foogen1(arg2): > # Some code here > # Some code here > gen_all(arg3) > ^ I mean foogen

Re: yield_all needed in Python

Nick Coghlan <[EMAIL PROTECTED]> writes: > If you do write a PEP, try to get genexp syntax supported by the > yield keyword. > That is, the following currently triggers a syntax error: >def f(): > yield x for x in gen1(arg) Wouldn't yield *(x for x in gen1(arg)) be sufficient, and

Re: Use empty string for self

Roy Smith <[EMAIL PROTECTED]> writes: > Terry Hancock <[EMAIL PROTECTED]> wrote: >> However, there is a slightly less onerous method which >> is perfectly legit in present Python -- just use "s" >> for "self": > This is being different for the sake of being different. Everybody *knows* > what

Proper licensing and copyright attribution for extracted Python code

rived carries the // following copyright: // // Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007 Python // Software Foundation. // // The modifications to the original software, which are contained herein, // are

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > Try suggesting on a Lisp or Scheme group that having only one type > of syntax (prefix expressions) lacks something and that they should > add variety in the form of statement syntax ;-) Hint: some Lispers > have bragged here about the simplicity of 'one

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > My only point was that Sussman is an odd person to be criticizing > (somewhat mistakingly) Python for being minimalist. I think that being a language minimalist is very different from believing that there should be exactly one obvious way to do everythi

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > Here's the situation. Python is making inroads at MIT, Scheme home turf. > The co-developer of Scheme, while writing about some other subject, tosses > in an off-the-wall slam against Python. Someone asks what we here think. > I think that the comme

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

Kay Schluehr <[EMAIL PROTECTED]> writes: > On 15 Jun., 22:58, Douglas Alan <[EMAIL PROTECTED]> wrote: >> For instance, I believe that Python is now too big, and that much >> of what is in the language itself should be replaced with more >> general Scheme-

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

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Fri, 15 Jun 2007 17:05:27 -0400, Douglas Alan wrote: >> You are ignoring the fact that Scheme has a powerful syntax extension >> mechanism (i.e., hygenic macros), which means that anyone in the world >> can ba

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > > You are ignoring the fact that > This prefactory clause is false and as such it turns what was a true > statement into one that is not. Better to leave off such ad hominisms and > stick with the bare true statement. You went on about how Gerry Sus

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

Dennis Lee Bieber <[EMAIL PROTECTED]> writes: > Macros? Unfortunately to my world, macros are those things > found in C, high-powered assemblers, and pre-VBA Office. As such, > they do anything but keep a language small, and one encounters > multiple implementations of similar functionality

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > |>oug writes: >> Scheme has a powerful syntax extension mechanism > I did not and do not see this as relevant to the main points of my > summary above. Python has powerful extension mechanisms too, but > comparing the two languages on this basis is a

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > The main point of my original post was that the quoted slam at Python was > based on a misquote of Tim Peters But it wasn't based on a "misquote of Tim Peters"; it was based on an *exact* quotation of Tim Peters. > and a mischaracterization of Python

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

Neil Cerutti <[EMAIL PROTECTED]> writes: > |>oug writes: >> Sussman's statements are not ironic because Scheme is a >> language that is designed to be extended by the end-user (even >> syntactically), while keeping the core language minimal. This >> is a rather different design philosophy from t

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > Nonetheless, picking on and characterizing Tim's statement as > anti-flexibility and un-scientific is to me writing of a sort that I > would not tolerate from my middle-school child. Now it is you who are taking Sussman's comments out of context. Sussma

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

Steven D'Aprano <[EMAIL PROTECTED]> writes: > On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote: >> I think that most people who program in Scheme these days don't do it >> to write practical software. They either do it to have fun, or for >> academ

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

"Terry Reedy" <[EMAIL PROTECTED]> writes: > | I think you are missing the point. Sussman is making a broad > | criticism software engineering in general, as it is understood > | today. > On the contrary, I understood exactly that and said so. *My* point > is that in doing so, he made one jab at

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

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?

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?

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?

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?

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?

"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: > 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?

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?

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

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

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?

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?

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

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

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?

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?

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?

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

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

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

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

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?

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?

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?

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?

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

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?

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?

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

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

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?

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?

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?

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?

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?

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?

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

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?

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?

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

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

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

"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: >> 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?

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

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

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

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

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

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: >> 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: Any advantage in LISPs having simpler grammars than Python?

Terry Hancock <[EMAIL PROTECTED]> writes: > I think experienced Lisp programmers must learn to visually parse > the *words* in the Lisp program to determine the structure, but I > find that really unhelpful, myself. Experienced Lisp programmers use indentation to visually parse the program struct

Re: Any advantage in LISPs having simpler grammars than Python?

Grant Edwards <[EMAIL PROTECTED]> writes: > On 2006-03-07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Is there any advantage to a language having a nice mathematically >> compact grammar like LISP does? (or at least used to?) Yes, Lisp's syntax allows for a very powerful macro mechanism tha

  1   2   >