I wrote:
> You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
> (and the constant 4) are unsigned.
Sorry, the constant '4' is signed, but sizeof(errTxt) - 4 can nevertheless
wrap around unless sizeof(errTxt) >= 4.
--
David Hop
ade an error
> in analyzing what must be true at this point.
You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
(and the constant 4) are unsigned. Also bytes_left must initially be nonnegative
so that the subexpression 'sizeof(errTxt) - bytes_left' cannot ov
the program is run despite the diagnostic, its behaviour
is undefined.
Several C compilers I've used in the past have needed the idempotence guard
on typedefs, in any case.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev m
Martin v. Löwis wrote:
> David Hopwood schrieb:
>
>>On Windows, file system pathnames can contain arbitrary Unicode characters
>>(well, almost). Despite the existence of "ANSI" filesystem APIs, and
>>regardless of what 'sys.getfilesystemencoding()' re
Nick Coghlan wrote:
> David Hopwood wrote:
>> Martin v. Löwis wrote:
>>> Nick Coghlan schrieb:
>>>
>>>> So this is taking something that *already works properly on POSIX
>>>> systems* and making it work on Windows as well.
>>>
>>&
ldn't work on Windows,
because they haven't worked in the past."
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
obably need something else.
+1 for (upto, sep, rest) -- and I think it should be in that order for
both partition and rpartition.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
Jean-Paul Calderone wrote:
> On Mon, 04 Sep 2006 17:24:56 +0100, David Hopwood <[EMAIL PROTECTED]> wrote:
>
>>Jean-Paul Calderone wrote:
>>
>>>PyGTK would presumably implement its pending call callback by writing a
>>>byte to a pipe which it is also p
Jean-Paul Calderone wrote:
> PyGTK would presumably implement its pending call callback by writing a
> byte to a pipe which it is also passing to poll().
But doing that in a signal handler context invokes undefined behaviour
according to POSIX.
--
David Hopwood <[EMAIL
cularly badly. I don't
know how to implement what you want here, but I'd endorse the comments of
Nick Maclaren and Antony Baxter against making precipitate changes.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
to read:
>
>seq[rslice(start, stop, step)]
Or slice.reversed().
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
rameworks, and compile at low optimization levels when
it doesn't hurt performance.)
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Thomas Wouters wrote:
> On 8/26/06, David Hopwood <[EMAIL PROTECTED]> wrote:
>
>> CPython should be fixed anyway. The correct fix is
>> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
>
> Why not just "... &&
t of a microoptimization that is unlikely to significantly
help performance.
CPython should be fixed anyway. The correct fix is
"if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
--
David Hopwood <[EMAIL PROTECTED]>
on. it's a question of semantics -- i asked whether the object
> (a list, in this case) is contained in the dict. i didn't ask whether
> it's hashable or not.
However, if it isn't hashable, asking whether it is in a di
Martin v. Löwis wrote:
> David Hopwood schrieb:
>>Michael Foord wrote:
>>>David Hopwood wrote:[snip..]
>>>
>>>>>>we should, of course, continue to use the one we always used (for
>>>>>>"ascii", there is no difference betwee
Michael Foord wrote:
> David Hopwood wrote:[snip..]
>
>>>> we should, of course, continue to use the one we always used (for
>>>> "ascii", there is no difference between the two).
>>>
>>> +1
>>>
>>> This seems the most (
; +1
>
> This seems the most (only ?) logical solution.
No; always considering Unicode and non-ASCII byte strings to be distinct
is just as logical.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.
am not especially fond of the current miniconf name either; I didn't
>>find something more suitable, yet evocative of what it does; I would be
>>glad to hear any suggestion you or the rest of the developers would have.
>
> pyson :)
Following the pattern of JSON,
ode cannot know
> whether this meant as overflow or underflow (in a signed sense).
Why not use IndexError for an underflow, and OverflowError for an overflow?
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.or
good idea. What was
the rationale for that? It should throw an exception.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Richard Jones wrote:
> On 27/07/2006, at 12:19 PM, David Hopwood wrote:
>
>> A restricted interpreter refuses access to any object attribute or
>> method with a name beginning with '_' (by throwing a new exception type
>> 'InternalAccessException&#x
Greg Ewing wrote:
> David Hopwood wrote:
>
>> Inheritance should be defined as though the code of inherited methods and
>> attributes were copied into the subclass (with global accesses updated to
>> point to the original module).
>
> You'll have to propose
Greg Ewing wrote:
> David Hopwood wrote:
>
>> A restricted interpreter refuses access to any object attribute or
>> method with a name beginning with '_' (by throwing a new exception type
>> 'InternalAccessException'), unless the access is from
David Hopwood wrote:
> The intention was not to require the restrictions to be compiler-enforced;
> only to *allow* them to be compiler-enforced.
>
> Code like this, for example:
>
> def someMethod(self, x):
> if self == x:
"if self is x:", I mean
ecure(object):
> _hidden = [1,2,3]
>
> class MetaAttack(type):
> def read(self):
> return self._hidden # seen as an instance attribute
>
> class Attack(SupposedlySecure):
> __metaclass__ = MetaAttack
>
> print Attack
__ and __str__ are internal under these rules, and probably shouldn't be.
Existing classes may expose private state in the strings returned by __repr__
or __str__, but in principle, there is nothing unsafe about being able to
convert the public state of an object to a string. OTOH, this functio
be fixed before the module is added to the standard
library, IMHO.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
eg Ewing was making. A pure capability system incurs
the complexity and performance costs of wrappers or membranes only in cases
where they are needed, not for every object, and the complexity is only in
user code, not in the system's security kernel.
--
David Hopwood <[EMAIL PROTECTED]&g
Phillip J. Eby wrote:
> At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:
>> Phillip J. Eby wrote:
>> > At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
>> >
>> >> I obviously don't want to change the feel of Python, but if I have to
>> >>
Brett Cannon wrote:
> On 7/23/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
>
>> Hi David, hi Brett,
>>
>> On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote:
>> > If I understand correctly, the proposal is that any incompatible
>> > change
orrect.
... if Zope's sandboxing is secure. I haven't done a security review of it,
but your argument assumes that it is.
In any case, Zope's sandboxing is not capability-based.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev
to make them work in a sandboxed interpreter, but
not at the expense of security. Some incompatible changes will be necessary.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
33 matches
Mail list logo
