Mike Meyer wrote:
Ron_Adam <[EMAIL PROTECTED]> writes:
Here's yet another way to do it, but it has some limitations as well.
import pickle
def pickle_it(filename, obj, commands):
try:
f = open(filename, 'r')
obj = pickle.load(f)
f.close()
except IOError:
pass
Ron_Adam <[EMAIL PROTECTED]> writes:
> Here's yet another way to do it, but it has some limitations as well.
>
> import pickle
> def pickle_it(filename, obj, commands):
> try:
> f = open(filename, 'r')
> obj = pickle.load(f)
> f.close()
> except IOError:
>
Greg Ewing wrote:
Brian Sabbey wrote:
do f in with_file('file.txt'):
print f.read()
I don't like this syntax. Try to read it as an English sentence:
"Do f in with file 'file.txt'". Say what???
To sound right it would have to be something like
with_file('file.txt') as f do:
print f.read()
Brian Sabbey wrote:
do f in with_file('file.txt'):
print f.read()
I don't like this syntax. Try to read it as an English sentence:
"Do f in with file 'file.txt'". Say what???
To sound right it would have to be something like
with_file('file.txt') as f do:
print f.read()
But, while that wo
On Mon, 18 Apr 2005 21:11:52 -0700, Brian Sabbey
<[EMAIL PROTECTED]> wrote:
>Ron_Adam wrote:
>> The load and dump would be private to the data class object. Here's a
>> more complete example.
>>
>> import pickle
>> class PickledData(object):
>> def __init__(self, filename):
>> se
Ron_Adam wrote:
The load and dump would be private to the data class object. Here's a
more complete example.
import pickle
class PickledData(object):
def __init__(self, filename):
self.filename = filename
self.L = None
try:
On Sun, 17 Apr 2005 19:56:10 -0700, Brian Sabbey
<[EMAIL PROTECTED]> wrote:
>I also wouldn't do it that way. I don't see a class as being much better,
>though. If I understand you correctly, with classes you would have
>something like:
>
>p = Pickled('pickled.txt')
>p.load()
>p.data.append('mo
Brian Sabbey wrote:
do f in with_file('file.txt'):
print f.read()
def with_file(filename):
f = open(filename)
yield f
f.close()
for f in with_file('file.txt'):
print f.read()
t = "no file read yet"
do f in with_file('file.txt'):
t = f.read()
t = "no file read yet"
for f in w
On Sun, 17 Apr 2005 15:32:56 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> Hm, one thing my syntax does, I just noticed, is allow you
>> to pass several thunks to a thunk-accepter, if desired, e.g.,
>> (parenthesizing this time, rather than ending (): with
>> dedented com
Ron_Adam wrote:
def pickled_file(thunk, name):
f = open(name, 'r')
l = pickle.load(f)
f.close()
thunk(l)
f = open(name, 'w')
pickle.dump(l, f)
f.close()
Now I can re-use pickled_file whenever I have to modify a pickled file:
do data in pickled
Brian Sabbey wrote:
used, but rarely is because doing so would be awkward. Probably the
simplest real-world example is opening and closing a file. Rarely will
you see code like this:
def with_file(callback, filename):
f = open(filename)
callback(f)
f.close()
def print_file(file):
On Sun, 17 Apr 2005 15:02:12 -0700, Brian Sabbey
<[EMAIL PROTECTED]> wrote:
Brian Sabbey wrote:
> I'm kicking myself for the first example I gave in my original post in
> this thread because, looking at it again, I see now that it really gives
> the wrong impression about what I want thunks to
Bengt Richter wrote:
Hm, one thing my syntax does, I just noticed, is allow you
to pass several thunks to a thunk-accepter, if desired, e.g.,
(parenthesizing this time, rather than ending (): with
dedented comma)
each(
((i): # normal thunk
print i),
((j): # alternative
Ron_Adam wrote:
On Sat, 16 Apr 2005 17:25:00 -0700, Brian Sabbey
Yes, much of what thunks do can also be done by passing a function
argument. But thunks are different because they share the surrounding
function's namespace (which inner functions do not), and because they can
be defined in a more r
On 17 Apr 2005 01:46:14 -0700, "Kay Schluehr" <[EMAIL PROTECTED]>
wrote:
>Ron_Adam wrote:
>
>> I sort of wonder if this is one of those things that looks like it
>> could be useful at first, but it turns out that using functions and
>> class's in the proper way, is also the best way. (?)
>
>I thin
Ron_Adam wrote:
> I sort of wonder if this is one of those things that looks like it
> could be useful at first, but it turns out that using functions and
> class's in the proper way, is also the best way. (?)
I think Your block is more low level. It is like copying and pasting
code-fragments tog
On Sat, 16 Apr 2005 18:46:28 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:
[...]
>> In that case, my version would just not have a do, instead defining the do
>> suite
>> as a temp executable suite, e.g., if instead
>>
>>
>> we make an asignment in the suite, to make it clear it's not just a call
On Sat, 16 Apr 2005 17:25:00 -0700, Brian Sabbey
<[EMAIL PROTECTED]> wrote:
>> You can already do this, this way.
>>
> def f(thunk):
>> ... before()
>> ... thunk()
>> ... after()
>> ...
> def before():
>> ... print 'before'
>> ...
> def after():
>> ... print 'after'
Bengt Richter wrote:
Good background on thunks can be found in ref. [1].
UIAM most of that pre-dates decorators. What is the relation of thunks
to decorators and/or how might they interact?
Hmm, I think you answered this below better than I could ;).
def f(thunk):
before()
thunk()
after()
[EMAIL PROTECTED] wrote:
Keep in mind that most of the problems come from the "space is
significant" thing, which is IMHO a very good idea, but prevents us from
putting code in expressions, like :
func( a,b, def callback( x ):
print x
)
or does it ? maybe this s
On Sat, 16 Apr 2005, Ron_Adam wrote:
Thunks are, as far as this PEP is concerned, anonymous functions that
blend into their environment. They can be used in ways similar to code
blocks in Ruby or Smalltalk. One specific use of thunks is as a way to
abstract acquire/release code. Another use is as a
Leif K-Brooks wrote:
Brian Sabbey wrote:
Thunk statements contain a new keyword, 'do', as in the example below. The
body of the thunk is the suite in the 'do' statement; it gets passed to the
function appearing next to 'do'. The thunk gets inserted as the first
argument to the function, reminisc
On Fri, 15 Apr 2005 16:44:58 -0700, Brian Sabbey
<[EMAIL PROTECTED]> wrote:
>
>Simple Thunks
>-
>
>Thunks are, as far as this PEP is concerned, anonymous functions that
>blend into their environment. They can be used in ways similar to code
>blocks in Ruby or Smalltalk. One specific
On Fri, 15 Apr 2005 16:44:58 -0700, Brian Sabbey <[EMAIL PROTECTED]> wrote:
>Here is a first draft of a PEP for thunks. Please let me know what you
>think. If there is a positive response, I will create a real PEP.
>
>I made a patch that implements thunks as described here. It is available
>at:
Brian Sabbey wrote:
> def get_items(thunk):# <-- "thunk-accepting function"
> f = acquire()
> try:
> for i in f:
> thunk(i) # A-OK
> finally:
> f.release()
>
> do i in get_items():
> print i
Seems like You want to solve the addressed gene
I think your proposal is very interesting, I've been missing code blocks
in Python more and more as time goes by.
I'll answer to both the 'thunks" proposal and the "suite-based keywords"
proposal here.
I find the Ruby syntax rather dirty though, because it has a lot of
implicit stuff, tre
Brian Sabbey wrote:
Thunk statements contain a new keyword, 'do', as in the example below.
The body of the thunk is the suite in the 'do' statement; it gets passed
to the function appearing next to 'do'. The thunk gets inserted as the
first argument to the function, reminiscent of the way 'self'
Here is a first draft of a PEP for thunks. Please let me know what you
think. If there is a positive response, I will create a real PEP.
I made a patch that implements thunks as described here. It is available
at:
http://staff.washington.edu/sabbey/py_do
Good background on thunks can be fo
28 matches
Mail list logo