Brett C. wrote:
> Works for me. If no one objects I will check in the change for CFLAGS to make
> it ``$(BASECFLAGS) $(OPT) "$EXTRA_CFLAGS"`` soon (is quoting it enough to make
> sure that it isn't evaluated by configure but left as a string to be evaluated
> by the shell when the Makefile is runn
Martin v. LÃwis wrote:
> 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
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 l
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 th
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
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
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 on
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
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 compi
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
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, and I've come across what appears
to be a reference counting problem in the `symtable_exit_scope' function
in
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 ? (http://
Martin v. LÃwis 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
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. LÃwis 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
[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
On Wed, 2005-04-20 at 14:32, Fredrik Lundh wrote:
> > File "C:\Code\python\lib\test\test_csv.py", line 58, in _test_default_attrs
> >self.assertRaises(TypeError, delattr, obj.dialect, 'quoting')
> > File "C:\Code\python\lib\unittest.py", line 320, in failUnlessRaises
> >callableObj(*args,
File "C:\Code\python\lib\test\test_csv.py", line 58, in _test_default_attrs
self.assertRaises(TypeError, delattr, obj.dialect, 'quoting')
File "C:\Code\python\lib\unittest.py", line 320, in failUnlessRaises
callableObj(*args, **kwargs)
AttributeError: attribute 'quoting' of '_csv.Dialect' o
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 crashe
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>
> 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:
> > b
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
>
>
> >
> >
> >def do():
> >print "setup"
> >try:
> >yield None
> >finally:
> >print "tear down"
> >
> > doesn't quite work (if it did, all you would need is syntactic sugar
> > for "for
> > dummy in"
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 c
def do():
print "setup"
try:
yield None
finally:
print "tear down"
doesn't quite work (if it did, all you would need is syntactic sugar
for "for
dummy in").
PEP325 is about that
___
Python-Dev mailing list
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 i
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.
On Tue, Apr 19, 2005, Shane Holloway (IEEE) wrote:
>
> I heartily agree! Especially when you have very similar try/finally
> code you use in many places, and wish to refactor it into a common area.
> If this is done, you are forced into a callback form like follows::
>
>
> def withFile(fi
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 open.
On Tuesday 19 Apr 2005 20:24, Guido van Rossum wrote:
..
> *If* we're going to create syntax for anonymous blocks, I think the
> primary use case ought to be cleanup operations to replace try/finally
> blocks for locking and similar things. I'd love to have syntactical
> support so I can write
>
>
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 once-famou
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
> > distingu
> 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 "
31 matches
Mail list logo
