Josiah Carlson wrote:
See the previous two discussions on thunks here on python-dev, and
notice how the only problem that seem bettered via blocks/thunks /in
Python/ are those which are of the form...
#setup
try:
block
finally:
#finalization
... and depending on the syntax, properties. I
Shane Hathaway wrote:
Brian's suggestion makes the code read more like an outline. In Brian's
example, the high-level intent stands out from the details
that assumes that when you call a library function, the high-level intent of
*your* code is obvious from the function name in the library, and
PS. a side effect of the for-in pattern is that I'm beginning to feel that
Python
might need a nice switch statement based on dictionary lookups, so I can
replace multiple callbacks with a single loop body, without writing too many
if/elif clauses.
That's funny. I keep wondering if match
On 4/19/05, Brian Sabbey [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
@acquire(myLock):
code
code
code
It would certainly solve the problem of which keyword to use! :-) And
I think the syntax isn't even ambiguous -- the trailing colon
distinguishes this from the
I guess I should begin by introducing myself: My name is Rüdiger Flaig, I live
in Heidelberg/Germany (yes indeed, there are not only tourists there) and am a
JOAT by profession (Jack Of All Trades). Among other weird things, I am
currently teaching immunology and bioinformatics at the
On Apr 20, 2005, at 5:43 AM, Paul Moore wrote:
and the substitution of
@EXPR:
CODE
would become something like
def __block():
CODE
EXPR(__block)
The question of whether assignments within CODE are executed within a
new namespace, as this implies, or in the surrounding namespace,
remains
On Wed, Apr 20, 2005, [EMAIL PROTECTED] wrote:
As students keep on asking me about the differences between languages
and the pros and cons, I think I may claim some familiarity with
other languages too, especially Python's self-declared antithesis,
Ruby.
That seems a little odd to me. To
On Wed, Apr 20, 2005 at 08:18:11AM -0700, Aahz wrote:
antithesis, it would be either C++ or Perl. Ruby is antithetical to some
of Python's core ideology because it borrows from Perl, but Ruby is much
more similar to Python than Perl is.
I'm not that familiar with the Ruby community; might it
Aahz wrote:
On Tue, Apr 19, 2005, Shane Holloway (IEEE) wrote:
However, my opinion is that it does not read smoothly. This form
requires that I say what I'm doing with something before I know the
context of what that something is. For me, blocks are not about
shortening the code, but rather
Seeing three seemingly related test failures today, on CVS HEAD:
test_csv
test test_csv failed -- errors occurred; run in verbose mode for details
test_descr
test test_descr crashed -- exceptions.AttributeError: attribute
'__dict__' of 'type' objects is not writable
test_file
test test_file
[Shane Holloway]
When I
write classes, I tend to put the public methods at the top. Utility
methods used by those entry points are placed toward the bottom. In
this way, I read the context of what I'm doing first, and then the
details of the internal methods as I need to understand them.
Martin v. Lwis wrote:
Brett C. wrote:
I am currently adding some code for a Py_COMPILER_DEBUG build for use on the
AST branch. I thought that OPT was the proper variable to put stuff like this
into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall
-Wstrict-prototypes``.
Brett C. wrote:
The other option is to not make configure.in skip injecting arguments when a
pydebug build is done based on whether OPT is defined in the environment. So
configure.in:670 could change to ``OPT=$OPT -g -Wall -Wstrict-prototypes``.
That's a procedural question: do we want to
Martin v. Lwis wrote:
Brett C. wrote:
The other option is to not make configure.in skip injecting arguments when a
pydebug build is done based on whether OPT is defined in the environment. So
configure.in:670 could change to ``OPT=$OPT -g -Wall -Wstrict-prototypes``.
That's a procedural
Fredrik Lundh wrote:
PS. a side effect of the for-in pattern is that I'm beginning to feel
that Python
might need a nice switch statement based on dictionary lookups, so I can
replace multiple callbacks with a single loop body, without writing too
many
if/elif clauses.
PEP 275 anyone ?
On 4/20/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
PS. a side effect of the for-in pattern is that I'm beginning to feel
that Python
might need a nice switch statement based on dictionary lookups, so I can
replace multiple callbacks with a single loop body, without
Matthew F. Barnes wrote:
Someone on python-help suggested that I forward this question to
python-dev.
I've been studying Python's core compiler and bytecode interpreter as a
model for my own interpreted language,
Might want to take a peek at the AST branch in CVS; that is what the compiler
Alex Martelli wrote:
def withfile(filename, mode='r'):
openfile = open(filename, mode)
try:
block(thefile=openfile)
finally:
openfile.close()
i.e., let the block take keyword arguments to tweak its namespace
I don't think I like that idea, because it means that from
the
Josiah Carlson wrote:
I once asked Any other
use cases for one of the most powerful features of Ruby, in Python? I
have yet to hear any sort of reasonable response.
Why am I getting no response to my question? Either it is because I am
being ignored, or no one has taken the time to translate one
Steven Bethard wrote:
Of course, even with the unpack list, you still have to know what kind
of arguments the function calls your block with. And because these
only appear within the code, e.g.
block(openfile)
you can't rely on easily accessible things like the function's
signature.
You can't
Shane Holloway (IEEE) wrote:
class After:
def readIt(self, filename):
withFile(filename):
self.readPartA(aFile)
self.readPartB(aFile)
self.readPartC(aFile)
In my opinion, this is much smoother to read. This particular example
Brett C. wrote:
Hmm. OK, that is an interesting idea. Would make rebuilding a lot easier if
it was just an environment variable that was part of the default OPT value;
``OPT=$BUILDFLAGS -g -Wall -Wstrict-prototyping.
I say we go with that. What is a good name, though? PY_OPT?
I think
Greg Ewing wrote:
Steven Bethard wrote:
Of course, even with the unpack list, you still have to know what kind
of arguments the function calls your block with. And because these
only appear within the code, e.g.
block(openfile)
you can't rely on easily accessible things like the
23 matches
Mail list logo
