(I'm shedding load; cleaning up my inbox in preparation for moving on
to Py3K. I'll try to respond to some old mail in the process.)
On 2/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Essentially, you need to decide: does type(x) mostly refer to the
> protocol that x respects ("interface" plus
On 2/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Now consider how nice it would be, on occasion, to be able to operate
> on an integer that's guaranteed to be 8, 16, 32, or 64 bits, to
> ensured the desired shifting/masking behavior for certain kinds of
> low-level programming; and also on one
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
On 2/6/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Is PEP 237 phase C to be implemented sooner than py3k,
> making isinstance(, int) a transparently distinction-hiding alias
> for
> isinstance(, integer), or outright illegal? IOW, will
> isinstance(, int)
> be _guaranteed_ to be a bug, thus r
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
>>
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)?
http://www.python.org/peps/pep-0237.html -- an ungoing process, not a
Py3K-
On Sun, 05 Feb 2006 18:47:13 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] (Bengt Richter) wrote:
>> Are you just lecturing me personally (in which case off list would be more
>> appropriate),
>> or do you include the authors of the 17 files I count under > prefix>/Lib tha
On Sun, 5 Feb 2006 18:08:58 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>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.
>>
[EMAIL PROTECTED] (Bengt Richter) wrote:
> Are you just lecturing me personally (in which case off list would be more
> appropriate),
> or do you include the authors of the 17 files I count under /Lib
> that have
> isinstance(, int) in them?
> Or would you like to rephrase that with suitable qua
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
> approp
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 h
[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 rang
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 excepti
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,
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 wi
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 alrea
Bob Ippolito wrote:
>
> On Feb 3, 2006, at 2:07 AM, Nick Coghlan wrote:
>> Currently, there is no syntax for binary literals, and the syntax for
>> octal
>> literals is both magical (where else in integer mathematics does a
>> leading
>> zero matter?) and somewhat error prone (int and eval will
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? (rem
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 st
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 g
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) immed
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
>> function
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
>
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
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
>>
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
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
http://mail.python.org/mailman/listinfo/
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?|
>>
>>
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
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
http://mail.python.org/mailma
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 the
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?
> 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:
http://mail.python.org/mailman/o
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 definatel
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
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 bin
[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 be
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,
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
[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
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
http://ma
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
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
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
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 sa
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 p
> 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 undesirab
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
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 litera
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
> 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
Python-
51 matches
Mail list logo
