On Mon, 6 Feb 2006 09:05:01 +0100, Thomas Wouters [EMAIL PROTECTED] wrote:
On Mon, Feb 06, 2006 at 05:33:57AM +, Bengt Richter wrote:
Perhaps I missed a py3k assumption in this thread (where I see in the PEP
that Remove distinction between int and long types is core item number
one)?
On 2/6/06, Bengt Richter [EMAIL PROTECTED] wrote:
Is PEP 237 phase C to be implemented sooner than py3k,
making isinstance(something, int) a transparently distinction-hiding alias
for
isinstance(something, integer), or outright illegal? IOW, will
isinstance(something, int)
be _guaranteed_
On 2/6/06, Guido van Rossum [EMAIL PROTECTED] wrote:
...
What we should do in 3.0 is not entirely clear to me. It would be nice
if there was only a single type (named 'int', of course) with two
run-time representations, one similar to the current int and one
similar to the current long. But
On Sat, 04 Feb 2006 11:11:08 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED] (Bengt Richter) wrote:
Martin v. Lowis [EMAIL PROTECTED] wrote:
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).
On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bengt Richter) wrote:
Martin v. Lowis [EMAIL PROTECTED] wrote:
Bengt Richter wrote:
The typical way of processing incoming ints in C is through
PyArg_ParseTuple, which already has the code to
On 2/5/06, Bengt Richter [EMAIL PROTECTED] wrote:
On Sun, 05 Feb 2006 09:38:35 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
1. If your Python code distinguishes between ints and longs, it has a
bug.
Are you just lecturing me personally (in which case off list would be more
appropriate),
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
On Thu, 2 Feb 2006 20:39:01 -0500, James Y Knight [EMAIL PROTECTED] wrote:
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
on 03.02.2006 00:16 Delaney, Timothy (Tim) said the following:
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
Bengt Richter wrote:
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
On Feb 3, 2006, at 2:07 AM, Nick Coghlan wrote:
Bengt Richter wrote:
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
On Wed, 2006-02-01 at 19:09 +, M J Fleming wrote:
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
Bengt Richter wrote:
If you are looking at them in C code receiving them as args in a call,
treat them the same would have to mean provide code to coerce long-int
or reject it with an exception, IWT.
The typical way of processing incoming ints in C is through
PyArg_ParseTuple, which already
On Fri, 03 Feb 2006 19:56:20 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Bengt Richter wrote:
If you are looking at them in C code receiving them as args in a call,
treat them the same would have to mean provide code to coerce long-int
or reject it with an
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
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
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 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
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,
On Tue, 2006-01-31 at 17:17 -0500, Andrew Koenig wrote:
Apart from making 0640 a syntax error (which I think is wrong too),
could this be solved by *requiring* the argument to be a string? (Or
some other data type, but that's probably overkill.)
That solves the problem only in that
On 2/1/06, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote:
On Tue, 2006-01-31 at 17:17 -0500, Andrew Koenig wrote:
I am personally partial to allowing an optional radix (in decimal) followed
by the letter r at the beginning of a literal, so 19, 8r23, and 16r13 would
all represent the
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the
casual observer; perhaps a suffix letter is more readable, since we
don't need arbitrary radix support anyway.
/me thinks of some
On Feb 1, 2006, at 7:33 AM, Gustavo J. A. M. Carneiro wrote:
Another possility is to extend the 0x syntax to non-hex,
0xff # hex
0o644 # octal
0b1101 # binary
+1
James
___
Python-Dev mailing list
Python-Dev@python.org
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the
casual observer; perhaps a suffix letter is more readable, since we
don't need
On Wed, 01 Feb 2006 09:47:34 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think 13r16 or 16r13 look too cryptic to the
casual
On Wed, 2006-02-01 at 09:47 -0800, Josiah Carlson wrote:
I hope I'm not the only one who thinks that simple is better than
complex, at least when it comes to numeric constants. Certainly it
would be _convenient_ to express constants in a radix other than decimal,
hexidecimal, or octal, but
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 09:47:34 -0800, Josiah Carlson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Bengt Richter) wrote:
On Wed, 01 Feb 2006 12:33:36 +, Gustavo J. A. M. Carneiro [EMAIL
PROTECTED] wrote:
[...]
Hmm.. I'm beginning to think
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
On Wed, 2006-02-01 at 11:07 -0800, Josiah Carlson wrote:
In my experience, I've rarely had the opportunity (or misfortune?) to
deal with negative constants, whose exact bit representation I needed to
get just right. For my uses, I find that specifying -0x... or -...
to be sufficient.
I
Guido van Rossum [EMAIL PROTECTED] wrote:
Right. And this is not a hypothetical issue either -- in Perl, hex and
oct *do* work the other way I believe. More reasons to get rid of
these in Python 3000. Perhaps we should also get rid of hex/oct
lterals?
I would like to argue for removing octal
Possibly os.chmod and os.umask could be extended to take a string
argument so we could write chmod(path, 0640).
-1.
Would you really want chmod(path, 0640) and chmod(path, 0640) to have
different meanings?
___
Python-Dev mailing list
Andrew Koenig [EMAIL PROTECTED] wrote:
Possibly os.chmod and os.umask could be extended to take a string
argument so we could write chmod(path, 0640).
-1.
Would you really want chmod(path, 0640) and chmod(path, 0640) to have
different meanings?
I want the former to be a syntax error, as I
On Tuesday 31 January 2006 14:55, Andrew Koenig wrote:
Would you really want chmod(path, 0640) and chmod(path, 0640) to have
different meanings?
Actually, the proposal that suggested this also proposed that 0640 would raise
a SyntaxError, since it was all about getting rid of octal literals.
On 1/31/06, Andrew Koenig [EMAIL PROTECTED] wrote:
Possibly os.chmod and os.umask could be extended to take a string
argument so we could write chmod(path, 0640).
-1.
Would you really want chmod(path, 0640) and chmod(path, 0640) to have
different meanings?
Apart from making 0640 a syntax
Apart from making 0640 a syntax error (which I think is wrong too),
could this be solved by *requiring* the argument to be a string? (Or
some other data type, but that's probably overkill.)
That solves the problem only in that particular context.
I would think that if it is deemed undesirable
On Tue, 31 Jan 2006 17:17:22 -0500, Andrew Koenig [EMAIL PROTECTED] wrote:
Apart from making 0640 a syntax error (which I think is wrong too),
could this be solved by *requiring* the argument to be a string? (Or
some other data type, but that's probably overkill.)
That solves the problem only
2006/1/31, Bengt Richter [EMAIL PROTECTED]:
In that case, could I also make a pitch for the letter c which would similarly
follow a radix (in decimal) but would introduce the rest of the number as
a radix-complement signed number, e.g., -2, 16cfe, 8c76, 2c110, 10c98 would
all have the same
44 matches
Mail list logo
