On 1 feb 2006, at 19:14, BJörn Lindqvist wrote:
I've submitted an updated version of the PEP. The only major change is
that instead of the method atime and property getatime() there is now
only one method named atime(). Also some information about the string
inheritance problem in Open
On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Hye-Shik Chang wrote:
I did some work to make ctypes+libffi compacter and liberal.
http://openlook.org/svnpublic/ctypes-compactffi/ (svn)
I removed sources/gcc and put sources/libffi copied from gcc 4.0.2.
And removed all
On Wed, Feb 01, 2006 at 01:35:14PM -0500, Barry Warsaw wrote:
The proposal for something like 0xff, 0o664, and 0b1001001 seems like
the right direction, although 'o' for octal literal looks kind of funky.
Maybe 'c' for oCtal? (remember it's 'x' for heXadecimal).
-Barry
+1
I definately
Generator expressions make syntactic support irrelevant:
Not when you're teaching the language to undergraduates: I haven't
actually done the study yet (though I may this summer), but I'm willing to
bet that allowing math notation for sets will more than double their
use. (Imagine having to
The PEP records that Tim argued for leaving the extra parentheses. What
would you do with {'title'} -- create a four element set consisting of
letters or a single element set consisting of a string?
This is a moderately-fertile source of bugs for newcomers: judging from
the number of students
Like many things in Python where people pre-emptively believe one thing
or another, the interpreter's corrective feedback is immediate:
Yup, that's the theory; it's a shame practice is different.
Once the students have progressed beyond academic finger drills and have
started writing real
Hye-Shik Chang [EMAIL PROTECTED] writes:
On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Hye-Shik Chang wrote:
I did some work to make ctypes+libffi compacter and liberal.
http://openlook.org/svnpublic/ctypes-compactffi/ (svn)
I removed sources/gcc and put sources/libffi copied
I definately agree with the 0c664 octal literal. Seems rather more
intuitive.
I still prefer 8r664.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Wed, 1 Feb 2006 13:54:49 -0500 (EST), Paul Svensson [EMAIL PROTECTED]
wrote:
On Wed, 1 Feb 2006, Barry Warsaw wrote:
The proposal for something like 0xff, 0o664, and 0b1001001 seems like
the right direction, although 'o' for octal literal looks kind of funky.
Maybe 'c' for oCtal?
On Feb 2, 2006, at 7:11 PM, Bengt Richter wrote:
[1] To reduce all this eye-glazing discussion to a simple example,
how do people now
use hex notation to define an integer bit-mask constant with bits
31 and 2 set?
That's easy:
0x8004
That was broken in python 2.4, though, so there
On Wed, 1 Feb 2006, Greg Wilson wrote:
Like many things in Python where people pre-emptively believe one thing
or another, the interpreter's corrective feedback is immediate:
Yup, that's the theory; it's a shame practice is different.
So what mistake(s) *do* your students make? As people
On Wed, 1 Feb 2006, Greg Wilson wrote:
[...]
(Imagine having to write list(1, 2, 3, 4, 5)...)
[...]
I believe that was actually proposed on this list for Python 3.
John
___
Python-Dev mailing list
Python-Dev@python.org
Andrew Koenig wrote:
I definately agree with the 0c664 octal literal. Seems rather more
intuitive.
I still prefer 8r664.
664[8] looks better and allows any radix
___
Python-Dev mailing list
Python-Dev@python.org
On 2/1/06, Greg Wilson [EMAIL PROTECTED] wrote:
Generator expressions make syntactic support irrelevant:
Not when you're teaching the language to undergraduates: I haven't
actually done the study yet (though I may this summer), but I'm willing to
bet that allowing math notation for sets will
On Thu, 2 Feb 2006 15:26:24 -0500, James Y Knight [EMAIL PROTECTED] wrote:
On Feb 2, 2006, at 7:11 PM, Bengt Richter wrote:
[1] To reduce all this eye-glazing discussion to a simple example,
how do people now
use hex notation to define an integer bit-mask constant with bits
I was recently reviewing a lot of the Python 2.4 code I have written,
and I've noticed one thing: thanks to the attrgetter and itemgetter
functions in module operator, I've been using (or been tempted to use)
far fewer lambdas, particularly but not exclusively in key= arguments
to sort and sorted.
Bengt Richter wrote:
[1] To reduce all this eye-glazing discussion to a simple example,
how do people now
use hex notation to define an integer bit-mask constant with bits
^^^
31 and 2 set?|
|
M J Fleming wrote:
+1
I definately agree with the 0c664 octal literal. Seems rather more
intuitive.
And importantly, sounds like Oc 664 ;)
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
Andrew Koenig wrote:
I definately agree with the 0c664 octal literal. Seems rather more
intuitive.
I still prefer 8r664.
The more I look at this, the worse it gets. Something beginning with
zero (like 0xFF, 0c664) immediately stands out as unusual. Something
beginning with any other digit
On Thu, 02 Feb 2006 23:46:00 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Bengt Richter wrote:
[1] To reduce all this eye-glazing discussion to a simple example,
how do people now
use hex notation to define an integer bit-mask constant with bits
On Fri, 3 Feb 2006 10:16:17 +1100, Delaney, Timothy (Tim) [EMAIL PROTECTED]
wrote:
Andrew Koenig wrote:
I definately agree with the 0c664 octal literal. Seems rather more
intuitive.
I still prefer 8r664.
The more I look at this, the worse it gets. Something beginning with
zero (like 0xFF,
21 matches
Mail list logo
