Brett C. wrote:
OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and
distutils.sysconfig . Martin, please double-check I tweaked sysconfig the way
you wanted.
It is the way I wanted it, but it doesn't work. Just try and use it for
some extension modules to see for yourself, I
Guido van Rossum wrote:
At the same time, having to use it as follows:
for f in with_file(filename):
for line in f:
print process(line)
is really ugly, so we need new syntax, which also helps with keeping
'for' semantically backwards compatible. So let's use
Shannon -jj Behrens wrote:
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
[ Simon Percivall ]:
[ Terry Reedy ]:
with target as value:
would parallel the for-statement header and read smoother to me.
for target as value:
would not need new keyword, but would require close reading to
distinguish
'as' from 'in'.
But it also moves the value to the
Skip Montanaro [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Guido with VAR = EXPR:
Guido BODY
What about a multi-variable case? Will you have to introduce a new level
of
indentation for each 'with' var?
I would expect to see the same structure unpacking as
Brett C. [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
And before anyone decries the fact that this might confuse a newbie
(which
seems to happen with every advanced feature ever dreamed up), remember
this
will not be meant for a newbie but for someone who has experience in
Jim Jewett writes:
As best I can tell, the anonymous blocks are used to take
care of boilerplate code without changing the scope -- exactly
what macros are used for.
Folks, I think that Jim is onto something here.
I've been following this conversation, and it sounds to me as if we
are
On 4/22/05, Fredrik Lundh [EMAIL PROTECTED] wrote:
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
why do you think you need to know?
I was in my second class of the Python workshop I'm giving here in one
I was in my second class of the Python workshop I'm giving here in one
Argentine University, and I was explaining how to think using
name/object and not variable/value.
Using id() for being pedagogic about the objects, the kids saw that
id(3) was always the same, but id([]) not. I explained
Michael Chermside wrote:
Jim Jewett writes:
As best I can tell, the anonymous blocks are used to take
care of boilerplate code without changing the scope -- exactly
what macros are used for.
Folks, I think that Jim is onto something here.
I've been following this conversation, and it sounds to me
On Mon, Apr 25, 2005, Shane Holloway (IEEE) wrote:
Interfaces::
def interface(interfaceName, *bases, ***aBlockSuite):
blockGlobals = aBlockSuite.globals().copy()
blockGlobals.update(aBlockSuite.locals())
blockLocals = {}
exec aBlock in blockGlobals,
Guido:
My problem with macros is actually more practical: Python's compiler
is too dumb. I am assuming that we want to be able to import macros
from other modules, and I am assuming that macros are expanded by the
compiler, not at run time; but the compiler doesn't follow imports ...
Guido writes:
My problem with macros is actually more practical: Python's compiler
is too dumb. I am assuming that we want to be able to import macros
from other modules, and I am assuming that macros are expanded by the
compiler, not at run time; but the compiler doesn't follow imports
(that
Guido:
But for *immutable* objects (like numbers, strings and tuples) the
implementation is free to use caching. In practice, I believe ints
between -5 and 100 are cached, and 1-character strings are often
cached (but not always).
Hope this helps! I would think this is in the docs somewhere but
Robert Brewer wrote:
So currently, all subclasses just override __set__, which leads to a
*lot* of duplication of code. If I could write the base class' __set__
to call macros like this:
def __set__(self, unit, value):
self.begin()
if self.coerce:
value =
Shane Hathaway wrote:
Robert Brewer wrote:
So currently, all subclasses just override __set__, which leads to a
*lot* of duplication of code. If I could write the base
class' __set__
to call macros like this:
def __set__(self, unit, value):
self.begin()
if
On 4/25/05, Guido van Rossum [EMAIL PROTECTED] wrote:
It could also be done (though not as cleanly) by making macros act as
import hooks.
Brrr. What about imports that aren't at the top level (e.g. inside a
function)?
Bad style already. :D
If you want to use the macro, you have to ensure
Paul Moore wrote:
Hmm, it took me a while to get this, but what you're ssaying is that
if you modify Guido's what I really want solution to use
VAR = next(it, exc)
then this builtin next makes API v2 stuff using __next__ work while
remaining backward compatible with old-style API v1 stuff using
It seems that what you call macros is really an unlimited
preprocessor. I'm even less interested in that topic than in macros,
and I haven't seen anything here to change my mind.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
M.-A. Lemburg wrote:
Having a simple switch statement
would enable writing very fast parsers in Python -
...
Instead of having one function call per token, you'd
only have a single dict lookup.
BTW, has anyone in this thread actually read the PEP 275 ?
I haven't actually seen any use cases
Robert Brewer wrote:
I still prefer more methods, because my actual use-cases are more
complicated. Your solution would work for the specific case I gave, but
try factoring in:
* A subclass which needs to share locals between begin and post, instead
of pre and post.
or
* A set of 10
Robert Brewer wrote:
Shane Hathaway wrote:
Robert Brewer wrote:
So currently, all subclasses just override __set__, which leads to a
*lot* of duplication of code. If I could write the base
class' __set__
to call macros like this:
def __set__(self, unit, value):
self.begin()
if
On Mon, 2005-04-25 at 18:20 -0400, Jim Jewett wrote:
[...]
If speed for a limited number of cases is the only advantage,
then I would say it belongs in (at most) the implementation,
rather than the language spec.
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
On Mon, 2005-04-25 at 21:21 -0400, Brian Beck wrote:
Donovan Baarda wrote:
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
benefits belong in implementation optimisations, not new bad syntax.
I posted this 'switch' recipe to the Cookbook this morning, it saves
Tim Delaney wrote:
There aren't many builtins that have magic names, and I don't think this
should be one of them - it has obvious uses other than as an
implementation detail.
I think there's some confusion here. As I understood the
suggestion, __next__ would be the Python name of the method
Guido van Rossum wrote:
with VAR = EXPR:
BODY
This would translate to the following code:
it = EXPR
err = None
while True:
try:
if err is None:
VAR = it.next()
else:
VAR = it.next_ex(err)
except
Patch / Bug Summary
___
Patches : 316 open ( +2) / 2831 closed ( +7) / 3147 total ( +9)
Bugs: 908 open (+10) / 4941 closed (+20) / 5849 total (+30)
RFE : 178 open ( +1) / 153 closed ( +2) / 331 total ( +3)
New / Reopened Patches
__
Brett C. wrote:
And before anyone decries the fact that this might confuse a newbie (which
seems to happen with every advanced feature ever dreamed up), remember this
will not be meant for a newbie but for someone who has experience in Python and
iterators at the minimum, and hopefully with
Terry Reedy wrote:
Not supporting iterables makes it harder to write a class which is
inherently usable in a with block, though. The natural way to make
iterable classes is to use 'yield' in the definition of __iter__ - if
iter() is not called, then that trick can't be used.
If you're defining
Donovan Baarda wrote:
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
benefits belong in implementation optimisations, not new bad syntax.
Two things are mildly annoying about if-elif chains as a
substitute for a switch statement:
1) Repeating the name of the thing being
30 matches
Mail list logo
