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
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Note that this is the opposite of normal Python policy: Python does not
> attempt to create cross-platform abstractions, but instead chooses to
> expose platform differences.
I had the opposite impression about Python
"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 expressi
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
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
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"
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 cross-plat
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 funda
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
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
http://mail.python.org/mailman/li
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. :)
> http://www.python.org/p
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 signif
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
___
P
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 c
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, th
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
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)
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,
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
19 matches
Mail list logo
