Re: [Python-Dev] The path module PEP
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 Issues. I still have no idea what to do > about it though. The current PEP still contains some redundancy between properties and methods under Specifications: basename() <-> name basename(), stripext() <-> namebase splitpath() <-> parent, name (documented) I would like to suggest to use only properties and use splitall() to obtain a tuple with the complete breakdown of the path. And may be splitall() could then be renamed to split(). The directory methods mkdir()/makedirs() and rmdir()/removedirs() could be unified. To me it seems they only exist because of Un*x details. my $0.005 --eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ctypes patch (was: (libffi) Re: Copyright issue)
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 automake-related build processes and integrated > > them into setup.py. There's still aclocal.m4 in sources/libffi. But > > it is just identical to libffi's acinclude.m4 which looks liberal. > > Well done! Would you like to derive a Python patch from that? > Don't worry about MSVC, yet, I will do that once the sources > are in the subversion. > Here goes patches for the integration: [1] http://people.freebsd.org/~perky/ctypesinteg-f1.diff.bz2 [2] http://people.freebsd.org/~perky/ctypesinteg-f2.diff.bz2 I implemented it in two flavors. [1] runs libffi's configure along with Python's and setup.py just builds it. And [2] has no change to Python's configure and setup.py runs libffi configure and builds it. And both patches don't have things for documentations yet. > (Of course, for due process, it would be better if this code gets > integrated into the official ctypes first, and then we incorporate > some named/versioned snapshot into /external, and svn cp it into > python/trunk from there). Thomas and I collaborated on integration into the ctypes repository and testing on various platforms yesterday. My patches for Python are derived from ctypes CVS with a change of only one line. Hye-Shik ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 agree with the 0c664 octal literal. Seems rather more intuitive. Matt ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
> 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 write "list(1, 2, 3, 4, 5)"...) > Accordingly,Guido rejected the braced notation for set comprehensions. > See: http://www.python.org/peps/pep-0218.html "...however, the issue could be revisited for Python 3000 (see PEP 3000)." So I'm only 1994 years early ;-) Thanks, Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
> 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 who come into my office with code that they think
ought to work, but doesn't, most people believe that:
set(1, 2, 3)
is "right". I believe curly-brace notation would eliminate this problem.
Thanks,
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
> 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 code, have you observed a shift in emphasis away > from hard-coded literals and towards something like s=set(data) where > the data is either read-in from outside the script or generated by > another part of the program? The problem is that once people classify something as "hard" or "fragile", they (consciously or unconsciously) avoid it thereafter, which of course means that it doesn't get any easier or more robust, since they're not practicing it. This has been observed in many arenas, not just programming. I agree it's not a compelling reason to add set notation to the language, but I'd rather eliminate the sand traps than reuqire people to learn to recognize and avoid them. Thanks, Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes patch
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 from gcc 4.0.2. >> > And removed all automake-related build processes and integrated >> > them into setup.py. There's still aclocal.m4 in sources/libffi. But >> > it is just identical to libffi's acinclude.m4 which looks liberal. >> >> Well done! Would you like to derive a Python patch from that? >> Don't worry about MSVC, yet, I will do that once the sources >> are in the subversion. >> > > Here goes patches for the integration: > > [1] http://people.freebsd.org/~perky/ctypesinteg-f1.diff.bz2 > [2] http://people.freebsd.org/~perky/ctypesinteg-f2.diff.bz2 > > I implemented it in two flavors. [1] runs libffi's configure along with > Python's and setup.py just builds it. And [2] has no change to > Python's configure and setup.py runs libffi configure and builds it. > And both patches don't have things for documentations yet. My plan is to make separate ctypes releases for 2.3 and 2.4, even after it is integrated into Python 2.5, so it seems [2] would be better - it must be possible to build ctypes without Python. As I said before, docs need still to be written. I think content is more important than markup, so I'm writing in rest, it can be converted to latex later. I expect that writing the docs will show quite some edges that need to be cleaned up - that should certainly be done before the first 2.5 release. Also I want to make a few releases before declaring the 1.0 version. This does not mean that I'm against integrating it right now. >> (Of course, for due process, it would be better if this code gets >> integrated into the official ctypes first, and then we incorporate >> some named/versioned snapshot into /external, and svn cp it into >> python/trunk from there). > > Thomas and I collaborated on integration into the ctypes repository > and testing on various platforms yesterday. My patches for Python > are derived from ctypes CVS with a change of only one line. > Hye-Shik has done a great job! Many thanks to him for that. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
> I definately agree with the 0c664 octal literal. Seems rather more > intuitive. I still prefer 8r664. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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? (remember it's 'x' for heXadecimal).
>
>Shouldn't it be 0t644 then, and 0n1001001 for binary ?
>That would sidestep the issue of 'b' and 'c' being valid
>hexadecimal digits as well.
>
>Regarding negative numbers, I think they're a red herring.
>If there is any need for a new literal format,
>it would be to express ~0x0f, not -0x10.
>1xf0 has been proposed before, but I think YAGNI.
>
YMMV re YAGNI, but you have an excellent point re negative numbers vs ~.
If you look at examples, the representation digits _are_ actually "~" ;-)
I.e., I first proposed 'c' in place of 'r' for 16cf0, where "c" stands for
radix _complement_, and 0 and 1 are complements wrt 2, as are
hex 0 and f wrt radix 16.
So the actual notation has digits that are radix-complement, and
are evaluated as such to get the integer value.
So ~0x0f is represented r16-f0, which does produce a negative number
(but whose integer value BTW is -0x10, not 0x0f. I.e., -16r-f0 == 16r+10,
and the sign after the 'r' is a complement-notation indicator, not
an algebraic sign. (Perhaps or '^' would be a better indicator, as -16r^f0 ==
0x10)
Thank you for making the point that the negative value per se is a red herring.
Still, that is where the problem shows up: e.g. when we want to define a hex
bit mask
as an int and the sign bit happens to be set. IMO it's a wart that if you want
to define bit masks as integer data, you have to invoke computation for the
sign bit,
e.g.,
BIT_0 = 0x1
BIT_1 = 0x02
...
BIT_30 = 0x4000
BIT_31 = int(-0x8000)
instead of defining true literals all the way, e.g.,
BIT_0 = 16r1
BIT_1 = 16r2 # or 16r0002 obviously
...
BIT_30 = 16r+4000
BIT_31 = 16r-8000)
and if you wanted to define the bit-wise complement masks as literals,
you could, though radix-2 is certainly easier to see (introducing '_' as
transparent elision)
CBIT_0 = 16r-f # or 16r-fffe or 2r-0 or
2r-___1110
CBIT_1 = 16r-d # or 16r-fffd or 2r-01 or
2r-___1101
...
CBIT_30 = 16r-b000 or 2r-1011___
CBIT_31 = 16r+7fff or 2r+0111___
With constant-folding optimization and some kind of inference-guiding for
expressions like
-sys.maxint-1, perhaps computation vs true literals will become moot. And
practically
it already is, since a one-time computation is normally insignificant in time
or space.
But aren't we also targeting platforms also where space is at a premium, and
being able to
define constants as literal data without resorting to workaround pre-processing
would be nice?
BTW, base-complement decoding works by generalized analogy to twos complement
decoding, by assuming
that the most significant digit is a signed coefficient value for
base**digitpos in radix-complement form,
where the upper half of the range of digits represents negative values as
digit-radix, and the rest positive as digit.
The rest of the digits are all positive coefficients for base powers.
E.g., to decode our simple example[1] represented as a literal in
base-complement form (very little tested):
>>> def bclitval(s, digits='0123456789abcdefghijklmnopqrstuvwxyz'):
... """
... decode base complement literal of form r
... where
... is in range(2,37) or more if digits supplied
... is a mnemonic + for digits[0] and - for digits[-1] or
absent
... are decoded as base-complement notation after if
... present is changed to appropriate digit.
... The first digit is taken as a signed coefficient with value
... digit- (negative) if the digit*2>=B and digit (positive)
otherwise.
... """
... B, s = s.split('r', 1)
... B = int(B)
... if s[0] =='+': s = digits[0]+s[1:]
... elif s[0] =='-': s = digits[B-1]+s[1:]
... ds = digits.index(s[0])
... if ds*2 >= B: acc = ds-B
... else: acc = ds
... for c in s[1:]: acc = acc*B + digits.index(c)
... return acc
...
>>> bclitval('16r8004')
-2147483644
>>> bclitval('2r1100')
-2147483644
BTW, because of the decoding method, extended "sign" bits
don't force promotion to a long value:
>>> bclitval('16r8004')
-2147483644
[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?
(assume 32-bit int for target platform, counting bit 0 as LSB and bit 31 as
sign).
Regards,
Bengt Richter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
Re: [Python-Dev] Octal literals
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 you need to do: MASK = 2**32 - 1 0x8004 & MASK > (assume 32-bit int for target platform, counting bit 0 as LSB and > bit 31 as sign). The 31st bit _isn't_ the sign bit in python and the bit-ness of the target platform doesn't matter. Python's integers are arbitrarily long. I'm not sure why you're trying to pretend as if python was C. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
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 have pointed out,
the mistake you complain about *does* usually result in an immediate
traceback:
>>> set(1, 2, 3)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: set expected at most 1 arguments, got 3
>>> set(1)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: iteration over non-sequence
>>>
Perhaps this?
>>> set("argh")
set(['a', 'h', 'r', 'g'])
>>>
[...]
> the language, but I'd rather eliminate the sand traps than reuqire people
> to learn to recognize and avoid them.
I'm sure nobody would disagree with you, but of course the devil is in
the detail.
John
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
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 more than double their > use. (Imagine having to write "list(1, 2, 3, 4, 5)"...) Actually, as far as I'm concerned, I'd just love to remove the [ ... ] notation for building lists if good ways could be found to distinguish "a list with this one item" from "a list with the same items as this iterable". list(1, 2, 3) is perfectly easy to explain, more readable, and just as likely to be used, if not more, than cryptic shorthand [1,2,3]. "If you want APL, you know where to find it" (==on IBM's online store, called APL2!-). > > Accordingly,Guido rejected the braced notation for set comprehensions. > > See: http://www.python.org/peps/pep-0218.html > > "...however, the issue could be revisited for Python 3000 (see PEP 3000)." > So I'm only 1994 years early ;-) Don't be such a pessimist, it's ONLY 994 years to go! Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 ^^^ >> 31 and 2 set?| > | >That's easy: | >0x8004 | >>> 0x8004 | 2147483652L| ^' That didn't meet specs ;-) > >That was broken in python < 2.4, though, so there you need to do: I agree it was broken, but >MASK = 2**32 - 1 >0x8004 & MASK does not solve the problem of doing correctly what it was doing (creating a mask in a signed type int variable, which happened to have the sign bit set). So long as there is a fixed-width int different from long, the problem will reappear. >> (assume 32-bit int for target platform, counting bit 0 as LSB and ^ >> bit 31 as sign). ^^ > >The 31st bit _isn't_ the sign bit in python and the bit-ness of the >target platform doesn't matter. Python's integers are arbitrarily >long. I'm not sure why you're trying to pretend as if python was C. Evidently I haven't made myself clear to you, and your mind reading wrt what I am trying to pretend is definitely flawed (and further speculations along that line are likely to be OT ;-) So long as we have a distinction between int and long, IWT int will be fixed width for any given implementation, and for interfacing with foreign functions it will continue to be useful at times to limit the type of arguments being passed. To do this arms-length C argument type control, it may be important to have constants of int type, knowing what that means on a given platform, and therefore _nice_ to be able to define them directly, understanding full well all the issues, and that there are workarounds ;-) Whatever the fixed width of int, ISTM we'll have predictable type promotion effects such as >>> width=32 >>> -1*2**(width-2)*2 -2147483648 vs >>> -1*2**(width-1) -2147483648L and >>> hex(-sys.maxint-1) '-0x8000' >>> (-int(hex(-sys.maxint-1)[1:],16)) == (-sys.maxint-1) True >>> (-int(hex(-sys.maxint-1)[1:],16)) , (-sys.maxint-1) (-2147483648L, -2147483648) >>> type(-int(hex(-sys.maxint-1)[1:],16)) == type(-sys.maxint-1) False >>> type(-int(hex(-sys.maxint-1)[1:],16)) , type(-sys.maxint-1) (, ) [1] Even though BTW you could well define a sign bit position abstractly for any integer value. E.g., the LSB of the arbitrarily repeated sign bits to the left of any integer in a twos complement representation (which can be well defined abstractly too). Code left as exercise ;-) Bottom line: You haven't shown me an existing way to do "16r8004" and produce the int ;-) Regards, Bengt Richter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] any support for a methodcaller HOF?
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. Most of those "lambda temptations" will be removed by PEP 309 (functional.partial), and most remaining ones are of the form: lambda x: x.amethod(zip, zop) So I was thinking -- wouldn't it be nice to have (possibly in module functional, like partial; possibly in module operator, like itemgetter and attrgetter -- I'm partial to functional;-) a methodcaller entry akin to (...possibly with a better name...): def methodcaller(methodname, *a, **k): def caller(self): getattr(self, methodname)(*a, **k) caller.__name__ = methodname return caller ...? This would allow removal of even more lambdas. I'll be glad to write a PEP, but I first want to check whether the Python-Dev crowd would just blast it out of the waters, in which case I may save writing it... Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 | > > >>> 0x8004 | > 2147483652L| >^' > > That didn't meet specs ;-) It sure does: 2147483652L is an integer (a long one); it isn't an int. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 doesn't. This just looks like noise to me. I found the suffix version even worse, but they're blown out of the water anyway by the fact that FFr16 is a valid identifier. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 >> >> ^^^ >> 31 and 2 set?| >>> >>> | >>>That's easy: | >>>0x8004 | >> >> >>> 0x8004 | >> 2147483652L| >>^' >> >> That didn't meet specs ;-) > >It sure does: 2147483652L is an integer (a long one); it isn't an >int. Aw, shux, dang. I didn't say what I meant ;-/ Apologies to James & all 'round. s/integer/int/ in the above. Regards, Bengt Richter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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, 0c664) immediately stands out as "unusual". Something >beginning with any other digit doesn't. This just looks like noise to >me. > >I found the suffix version even worse, but they're blown out of the >water anyway by the fact that FFr16 is a valid identifier. > Are you sure you aren't just used to the x in 0xff? I.e., if the leading 0 were just an alias for 16, we could use 8x664 instead of 8r664. BTW Ada uses radix prefix, but with # separating the prefix, so we can't use that. How about apostrophe as separator? 8'664 # or the suffix version could work also, although you'd have to back out of some names: 664'8 bee'16 Regards, Bengt Richter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
On Feb 2, 2006, at 10:36 PM, Bengt Richter wrote: > So long as we have a distinction between int and long, IWT int will > be fixed width > for any given implementation, and for interfacing with foreign > functions it will > continue to be useful at times to limit the type of arguments being > passed. We _don't_ have a distinction in any meaningful way, anymore. ints and longs are almost always treated exactly the same, other than the "L" suffix. I expect that suffix will soon go away as well. If there is code that _doesn't_ treat them the same, there is the bug. We don't need strange new syntax to work around buggy code. Note that 10**14/10**13 is also a long, yet any interface that did not accept that as an argument but did accept "10" is simply buggy. Same goes for code that says it takes a 32-bit bitfield argument but won't accept 0x8000. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
