Nick Coghlan wrote:
That's like saying it's not the same because '(x*x def (x)' creates a
function while '(x*x for x in seq)' creates a generator-iterator.
Well,
naturally - if the expression didn't do something different, what
would be the
point in having it?
;-)
Naturally. I just wanted
Bengt Richter wrote:
The typical way of processing incoming ints in C is through
PyArg_ParseTuple, which already has the code to coerce long-int
(which in turn may raise an exception for a range violation).
So for typical C code, 0x8004 is a perfect bit mask in Python 2.4.
Ok, I'll take
Eric Nieuwland wrote:
Then how about nameless function/method definition:
def (x):
... usual body ...
Hell no. If I want to write a real function, I already have perfectly good
syntax for that in the form of a def statement. I want to *increase* the
conceptual (and pedagogical)
Nick Coghlan wrote:
Hell no. If I want to write a real function, I already have perfectly good
syntax for that in the form of a def statement. I want to *increase* the
conceptual (and pedagogical) difference between deferred expressions and real
functions, not reduce it. There's a reason I
Martin v. Löwis wrote:
Hmm. A function also defines *here* and *now* an operation to be carried
out *elsewhere* and *later*.
Agreed, but when I use a lambda, I almost always have a *specific* elsewhere
in mind (such as a sorting operation or a callback registration). With named
functions,
I won't even look at the PEP as long as it uses / or // (or any other
operator) for concatenation.
On 2/3/06, Nick Coghlan [EMAIL PROTECTED] wrote:
I was tinkering with something today, and wondered whether it would cause
fewer objections if the PEP used the floor division operator (//) to
On 2/4/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I won't even look at the PEP as long as it uses / or // (or any other
operator) for concatenation.
That's good, because it doesn't. :) http://www.python.org/peps/pep-0355.html
--
mvh Björn
___
BJörn Lindqvist wrote:
On 2/4/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I won't even look at the PEP as long as it uses / or // (or any other
operator) for concatenation.
That's good, because it doesn't. :) http://www.python.org/peps/pep-0355.html
My mistake - that's been significantly
BJörn Lindqvist [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
On 2/4/06, Guido van Rossum [EMAIL PROTECTED] wrote:
I won't even look at the PEP as long as it uses / or // (or any other
operator) for concatenation.
That's good, because it doesn't. :)
Martin v. Löwis wrote:
I believe that usage of a keyword with the name of a Greek letter also
contributes to people considering something broken.
QOTW! ;-)
--eric
___
Python-Dev mailing list
Python-Dev@python.org
Nick Coghlan wrote:
I believe that usage of a keyword with the name of a Greek letter also
contributes to people considering something broken.
Aye, I agree there are serious problems with the current syntax. All
I'm
trying to say above is that I don't believe the functionality itself
is
Hello,
my comments on the Path PEP:
- Many methods contain the word 'path' in them. I suppose this is to help
transition from the old library to the new library. But in the context of a
new Python user, I don't think that Path.abspath() is optimal. Path.abs()
looks better. Maybe it's not so
At 08:35 PM 2/4/2006 +0100, Giovanni Bajo wrote:
- ctime() is documented to be unportable: it has different semantics on UNIX
and Windows. I believe the class should abstract from these details.
Note that this is the opposite of normal Python policy: Python does not
attempt to create
Here are a couple of simple-minded fixes for the PEP.
Near the bottom of Replacing older functions with the Path class:
fname = Path(Python2.4.tar.gz)
base, ext = fname.namebase, fname.extx
Surely this should be:
base, ext = fname.namebase, fname.ext
lib_dir = /lib
Phillip J. Eby [EMAIL PROTECTED] wrote:
- ctime() is documented to be unportable: it has different semantics
on UNIX and Windows. I believe the class should abstract from these
details.
Note that this is the opposite of normal Python policy: Python does
not attempt to create cross-platform
Duncan Booth wrote:
I'm not convinced by the rationale given why atime,ctime,mtime and size are
methods rather than properties but I do find this PEP much more agreeable
than the last time I looked at it.
A better rationale for doing it is that all of them may raise IOException.
It's rude
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hell no. If I want to write a real function, I already have perfectly
good
syntax for that in the form of a def statement. I want to *increase* the
conceptual (and pedagogical) difference between deferred expressions and
Terry Reedy wrote:
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hell no. If I want to write a real function, I already have perfectly
good
syntax for that in the form of a def statement. I want to *increase* the
conceptual (and pedagogical) difference between
18 matches
Mail list logo
