Question: should the CPython source compile cleanly and work
correctly on (mostly ancient or hypothetical) machines that use
ones' complement or sign-and-magnitude to represent signed integers?
I'd like to explicitly document and make use of the following assumptions
about the underlying C implem
Mark Dickinson wrote:
> Question: should the CPython source compile cleanly and work
> correctly on (mostly ancient or hypothetical) machines that use
> ones' complement or sign-and-magnitude to represent signed integers?
I think that's the wrong question to ask. What you really meant to ask
(IIU
On Tue, Dec 1, 2009 at 1:46 PM, "Martin v. Löwis" wrote:
> Mark Dickinson wrote:
>> Question: should the CPython source compile cleanly and work
>> correctly on (mostly ancient or hypothetical) machines that use
>> ones' complement or sign-and-magnitude to represent signed integers?
>
> I think t
> No, the original question really was the question that I meant to ask. :)
Ok. Then the reference to issue 7406 is really confusing, as this is
about undefined behavior - why does the answer to your question affect
the resolution of this issue?
> I absolutely agree that CPython shouldn't invoke
On Tue, Dec 1, 2009 at 3:32 PM, "Martin v. Löwis" wrote:
>> No, the original question really was the question that I meant to ask. :)
>
> Ok. Then the reference to issue 7406 is really confusing, as this is
> about undefined behavior - why does the answer to your question affect
> the resolution
>> I'd rather prefer to explicitly list what CPython assumes about the
>> outcome of specific operations. If this is just about &, |, ^, and ~,
>> then its fine with me.
>
> I'm not even interested in going this far:
I still am: with your list of assumptions, it is unclear (to me, at
least) what
On Dec 1, 2009, at 11:08 AM, Martin v. Löwis wrote:
>>> I'd rather prefer to explicitly list what CPython assumes about the
>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>> then its fine with me.
>>
>> I'm not even interested in going this far:
>
> I still am: with
On Tue, Dec 1, 2009 at 4:08 PM, "Martin v. Löwis" wrote:
>>> I'd rather prefer to explicitly list what CPython assumes about the
>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>> then its fine with me.
>>
>> I'm not even interested in going this far:
>
> I still am: wit
On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight wrote:
> I think all that needs to be defined is that conversion from unsigned to
> signed, and (negative) signed to unsigned integers have 2's complement
> wrapping semantics, and does not affect the bit pattern in memory.
Yes, I think everything
On Tue, Dec 1, 2009 at 11:24 AM, Mark Dickinson wrote:
> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight wrote:
>> I think all that needs to be defined is that conversion from unsigned to
>> signed, and (negative) signed to
>> unsigned integers have 2's complement wrapping semantics, and does no
Hi,
I have some code that exhibits behavior that might be a python import bug.
The code is part of a set of unit tests. One test in passes when no .pyc files
exist, but fails when the pyc file is present on disk. My code is not doing any
thing special with import or pickle or anything "fancy". I
On Tue, Dec 1, 2009 at 4:47 PM, Alexander Belopolsky
wrote:
>> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight wrote:
>>> I think all that needs to be defined is that conversion from unsigned to
>>> signed, and (negative) signed to
>>> unsigned integers have 2's complement wrapping semantics, an
On Tue, Dec 1, 2009 at 5:22 PM, Mark Dickinson wrote:
> or a workaround. E.g., for an unsigned long x,
>
> ((x) >= 0 ? (long)(x) : ~(long)~(x))
>
> always gives the appropriate wraparound semantics (I think), assuming
Sorry; should have tested. Try:
((x) <= LONG_MAX ? (long)(x) : ~(long)~(x)
I'd rather prefer to explicitly list what CPython assumes about the
outcome of specific operations. If this is just about &, |, ^, and ~,
then its fine with me.
>>> I'm not even interested in going this far:
>> I still am: with your list of assumptions, it is unclear (to me, at
>> le
What kind of failure do you get? A a failed test, a Python exception,
or a core dump?
Are you sure there is no code in your app or in your tests that looks
at __file__ and trips up over if it ends in '.pyc' instead of '.py' ?
Are you importing from zipfiles (e.g. eggs you've downloaded)?
Can you
> The code that shows this problem is owned by my company, I'm not sure
> if I would be able to produce it to create a bug report. But I do have some
> time
> to help debug the problem.
>
> What steps should I take to try to isolate the problem?
Try isolating the precise instruction that behaves
Please ignore my earlier message. The problem turned out to
be having a file "test1.py" in the current directory that somehow
was interfering with unit testing.
-Ram
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
[Mark]
> I'm not sure how to decide which particular consequences
> should be listed, but those for &, |, ^ and ~ could certainly
> be included.
[Martin]
> It should give the CPython contributors an indication what kind
> of code would be ok, and which would not. Perhaps it should include
> both a
18 matches
Mail list logo
