Andrew Koenig wrote:
>>Function arguments are not covered by this trick, but
>>
>>def bar(z):
>>(x,y) = z
>>
>>probably isn't too much overhead...
>
>
> It's not the machine overhead, it's the intellectual overhead. I know there
> are some who will disagree with me, but I would find
On 2/27/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Neal plugged another hole later, but-- alas --I have seen the same shy
> failure since then on WinXP. One of the most recent buildbot test
> runs saw it too, on a non-Windows box:
>
> http://www.python.org/dev/buildbot/trunk/g5%20osx.3%20trunk/
On 3/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> Who 'owns' Modules/_bsddb.c, if anyone?It's a fork of pybsddb, originally contributed by Gregory Smith (*).For all practical purposes, he also "owns" it, but hasn't objected
to others making changes in the past.At the ti
Greg Ewing wrote:
> Jeremy Hylton wrote:
> > Perhaps the solution
> > is to require parens around all expressions, a simple
> consistent rule.
>
> I actually designed a language with that feature once.
> It was an exercise in minimality, with hardly anything
> built-in -- all the arithmetic opera
Alex Martelli wrote:
> On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote:
>>with expr as f:
>>do something with f
I expect the "with" example here is a red herring,
not intended to have anything to do with the new
"with" statement that's just been added.
> I think the best use cases for 'assign
Paul Moore wrote:
> +0 for mentioning parens around conditional expressions in PEP 8. But
> it's aready covered by the general "code should be readable" in my
> view.
Indeed. Writing readable code is ultimately the
responsibility of the person doing the writing.
It's enough that you *can* put par
Jeremy Hylton wrote:
> Perhaps the solution
> is to require parens around all expressions, a simple consistent rule.
I actually designed a language with that feature once.
It was an exercise in minimality, with hardly anything
built-in -- all the arithmetic operators, etc. were
defined in the lang
Ian reproposed:
class Quitter(object):
def __init__(self, name):
self.name = name
def __repr__(self):
return 'Use %s() to exit' % self.name
def __call__(self):
raise SystemExit()
The one change I would suggest is the string use
On 3/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/7/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote:
> >
> > > IMO it shouldn't be fixed. Classic classes define their str to print
> > > the module name and class name with a dot i
On 3/8/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
On 3/7/06, Ian Bicking <[EMAIL PROTECTED]> wrote:> class Quitter(object):> def __init__(self, name):> self.name
= name> def __repr__(self):> return 'Use %s() to exit' % self.name> def __call__(self):> rais
On 3/7/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Frederick suggested a change to quit/exit a while ago, so it wasn't just
> a string with slight instructional purpose, but actually useful. The
> discussion was surprisingly involved, despite the change really trully
> not being that big. And ev
BJörn Lindqvist wrote:
> do {
> cmd = readline()
> do_stuff_with_cmd(cmd);
> } while (!strcmp(cmd, "quit"));
> printf("Bye!");
> exit(0);
>
> KISS?
I believe there were concerns that rebinding quit would cause strange
behavior. E.g.:
>>> quit = False
>>> while not quit: ...
>>
I am probably the biggest proponent of magic variables, but this just
won't work.
First, commands and lines are not the same thing, so:
print \
exit
breaks your propossal.
Second, quit and exit are bindable variables, and you need to be sure
that they still mean _quit_, and not something else.
do {
cmd = readline()
do_stuff_with_cmd(cmd);
} while (!strcmp(cmd, "quit"));
printf("Bye!");
exit(0);
KISS?
--
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
Ian Bicking wrote:
> class Quitter(object):
> def __init__(self, name):
> self.name = name
> def __repr__(self):
> return 'Use %s() to exit' % self.name
> def __call__(self):
> raise SystemExit()
> quit = Quitter('quit')
> exit = Quitter('exit')
>
> This i
On 3/7/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote:
>
> > IMO it shouldn't be fixed. Classic classes define their str to print
> > the module name and class name with a dot in between; new-style
> > classes use the same format as their rep
On Tue, 2006-03-07 at 13:35 -0800, Guido van Rossum wrote:
> IMO it shouldn't be fixed. Classic classes define their str to print
> the module name and class name with a dot in between; new-style
> classes use the same format as their repr. Making exceptions new-style
> classes is going to break a
Works for me.
On 3/7/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Frederick suggested a change to quit/exit a while ago, so it wasn't just
> a string with slight instructional purpose, but actually useful. The
> discussion was surprisingly involved, despite the change really trully
> not being th
Frederick suggested a change to quit/exit a while ago, so it wasn't just
a string with slight instructional purpose, but actually useful. The
discussion was surprisingly involved, despite the change really trully
not being that big. And everyone drifted off, too tired from the
discussion to m
Brett Cannon wrote:
> On 3/7/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I know that my unittests should not rely on this, but is this change
>> intended?
>>
>> c:\sf\ctypes_head>py24
>> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
>> win32
>> Type "help", "copyrigh
On 3/7/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/7/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> > I know that my unittests should not rely on this, but is this change
> > intended?
> >
> > c:\sf\ctypes_head>py24
> > Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
Oleg Broytmann wrote:
> On Tue, Mar 07, 2006 at 10:19:03PM +0100, Thomas Heller wrote:
>> Too bad that ctypes whill be an optional module, so I'm
>> not sure if it could be used in the Python library itself.
>
> try:
>import ctypes
> except ImportError:
>def fallback():
> ...
> else:
On Tue, Mar 07, 2006 at 10:19:03PM +0100, Thomas Heller wrote:
> Too bad that ctypes whill be an optional module, so I'm
> not sure if it could be used in the Python library itself.
try:
import ctypes
except ImportError:
def fallback():
...
else:
def real_thing():
...
Oleg.
-
Paul Moore wrote:
> On 3/7/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote:
>>> see subject and http://python.org/sf/1368955
>>>
>>> comments ?
>> would be nice if you could just call UUID() to create a generic UUID in a
>> platform-appropriate way.
On 3/7/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> I know that my unittests should not rely on this, but is this change
> intended?
>
> c:\sf\ctypes_head>py24
> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for m
I know that my unittests should not rely on this, but is this change
intended?
c:\sf\ctypes_head>py24
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> str(Exception)
'exceptions.Exception'
>>>
> Function arguments are not covered by this trick, but
>
> def bar(z):
> (x,y) = z
>
> probably isn't too much overhead...
It's not the machine overhead, it's the intellectual overhead. I know there
are some who will disagree with me, but I would find it easier to read
de
On 3/7/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> As it turns out, Python has similar ways of decomposing data structures:
>
> (x, y) = foo
>
> or
>
> def bar((x, y)):
> # etc.
>
> and I have sometimes wished I could write
>
> z as (x, y) = foo
>
> or
>
>
Thomas Wouters wrote:
> Who 'owns' Modules/_bsddb.c, if anyone?
It's a fork of pybsddb, originally contributed by Gregory Smith (*).
For all practical purposes, he also "owns" it, but hasn't objected
to others making changes in the past.
At the time it was imported, I recall the plan was to out-p
> Thinking over it, this is too much a difference between the with-"as" and
> my "as", so I'm abandoning this idea. My "as" would just have been a
> shortcut to avoid writing longish expressions that have to be checked for
> true-ness and then tinkered with.
ML has a similar feature, which you may
Guido van Rossum wrote:
> On 3/7/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> > Have you even tried to define precise semantics for any of those, like
>> > the expansion of "with E as V: B" in PEP 343?
>>
>> Easily.
>>
>> if expr as name:
>> BLOCK
>>
>> would be equivalent to
>>
>> name = exp
Georg Brandl <[EMAIL PROTECTED]> wrote:
> or something like
>
> m = re.match(...)
> if m.group(1) as filename:
> do something with filename
Except that m could be None, which would raise an exception during the
.group(1) call. Perhaps you meant...
m = re.match(...)
if m and m.group(1) as f
Alex Martelli wrote:
> I think the best use cases for 'assignment inside an if or while'
> condition, as far as they go, require `capturing' a SUB-expression of
> the condition, rather than the whole condition. E.g., in C,
>
> while ( (x=next_x()) < threshold ) ...
>
> being able to capture
On 3/7/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Have you even tried to define precise semantics for any of those, like
> > the expansion of "with E as V: B" in PEP 343?
>
> Easily.
>
> if expr as name:
> BLOCK
>
> would be equivalent to
>
> name = expr
> if name:
> BLOCK
> del name
[HPH the BDFL]
> I suggest you file those as products of an overactive imagination. :-)
At least not only mine. ;)
> Have you even tried to define precise semantics for any of those, like
> the expansion of "with E as V: B" in PEP 343?
Easily.
if expr as name:
BLOCK
would be equivalent to
> Philip Eby writes:
> ...
> I completely agree with Philip.
Sorry, I mean of course "Phillip".
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
Having UUID in the stdlib would be very helpful.
Philip Eby writes:
> I like the idea of having RFC-compliant UUIDs in the stdlib, but I really
> want immutable ones, preferably without {} in their standard string
> representation. And efficient use of platform-local UUID generation APIs
> wou
Who 'owns' Modules/_bsddb.c, if anyone? The file doesn't mention whether it's a fork of pybsddb maintained separately or not. I ask because it seems to contain a number of refleaks, and I wanted to fix some of the style issues while I'm at it (and maybe even Py_ssize_t it,) but I'll happily send th
On 3/7/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote:
> >see subject and http://python.org/sf/1368955
> >
> >comments ?
>
> would be nice if you could just call UUID() to create a generic UUID in a
> platform-appropriate way. PEAK's uuid module doe
At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote:
>see subject and http://python.org/sf/1368955
>
>comments ?
Why can't the UUIDs be immutable, so they can be dictionary keys? Also, it
would be nice if you could just call UUID() to create a generic UUID in a
platform-appropriate way. PEAK's uui
We like to invite you to a survey about the working conditions in
Free/Open-Source Software development. This survey is conducted by the
Open-Source Research Group of the University of Würzburg (Germany).
We will compare work design in open source and proprietary software
development. Our findi
On Mar 7, 2006, at 7:29 AM, Steve Holden wrote:
...
>> In fact, I think the below examples are reasonable uses
>> that do a better job of expressing intent than the if
>> statement would. I just don't like the mental backtrack
>> they require, and would like some sort of advance
>> warning.
Jim Jewett wrote:
> On 3/7/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>
>
>>The parentheses around genexps were (AFAICT)
>>different - without them, the grammar was ambiguous,
>>so some way of disambiguating was needed.
>
>
> The out-of-order evaluation is a very large change,
> because now we h
On 3/7/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> The parentheses around genexps were (AFAICT)
> different - without them, the grammar was ambiguous,
> so some way of disambiguating was needed.
The out-of-order evaluation is a very large change,
because now we have a situation where normal
parsi
On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote:
> Hi,
>
> while "as" is being made a keyword, I remembered parallels between
> "with"
> and a proposal made some time ago:
>
> with expr as f:
> do something with f
>
> while expr as f:
> do something with f
>
> if expr as f:
> do some
I suggest you file those as products of an overactive imagination. :-)
Have you even tried to define precise semantics for any of those, like
the expansion of "with E as V: B" in PEP 343?
--Guido
On 3/7/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> while "as" is being made a keyword, I r
Hi,
while "as" is being made a keyword, I remembered parallels between "with"
and a proposal made some time ago:
with expr as f:
do something with f
while expr as f:
do something with f
if expr as f:
do something with f
elif expr as f:
do something else with f
What do you think
Paul Moore wrote:
> On 3/7/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
>> On 3/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>> On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
>>> ...
I think that adding parentheses would help, by at least signalling
that the logic is longer than jus
On 3/7/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 3/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> >
> > On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
> > ...
> > > I think that adding parentheses would help, by at least signalling
> > > that the logic is longer than just the next (sin
On 3/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
> ...
> > I think that adding parentheses would help, by at least signalling
> > that the logic is longer than just the next (single) expression.
> >
> > level = (0 if "absolute_import" in
Fredrik Lundh wrote:
> see subject and http://python.org/sf/1368955
>
> comments ?
Fine with me.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
Joe Smith wrote:
> "Steve Holden" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Jim Jewett wrote:
>>
>>>I think that adding parentheses would help, by at least signalling that
>>>the logic is longer than just the next (single) expression.
>>>
>>>level = (0 if "absolute_imp
52 matches
Mail list logo
