Magnus Lycka <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > I don't think these headaches and difficulties justify dumping the whole
> > field of reasoning about programs, nor the subfield of PbC. The concept
> > of "immutable" is really just a tiny corner of these fields, and it's a
> > long way from being the hardest or most problematic one in them;-).
>
> Agreed. I also think that it's good practice to make methods do *one*
> thing, so when methods grow into both changing state and returning
> some substantial value, I usually split them. While the distinction
> between "functions" and "procedures" to speak Pascalese is a useful
> guidline at times, it's still a generalization though, and I doubt
> that it's very useful to have a syntactic marker for this distinction
> such as e.g. Pascal has.
The distinction is theoretically nice, but pragmatically it can get in
your way when a result is a "natural side effect" of the state change.
As a (perhaps overly) simple example, heapq.heapreplace is very natural
for some use cases of heaps as priority queues, and frequent enough that
having to replace it throughout with
result = heapq.heappop...
heapq.heappush...
return result
would be mildly annoying. At the other extreme, if Queue.Queue.get
couldn't BOTH alter queue state (remove one item) AND return the removed
item, within one threadsafe ("atomic") operation, that would be way more
than just annoying... it would just about destroy the usefulness of
Queue.Queue!
Alex
--
http://mail.python.org/mailman/listinfo/python-list
