On Thu, Sep 7, 2017 at 11:46 AM, Erik Bray wrote:
> On Thu, Sep 7, 2017 at 11:06 AM, Jeroen Demeyer
> wrote:
>> On 2017-09-06 17:24, Erik Bray wrote:
>>>
>>> Interpreting
>>> "str" as "bytes" is the only way it can be if language_level=2.
>>
>>
>> I think you are misunderstanding. You didn't pos
On Thu, Sep 7, 2017 at 11:06 AM, Jeroen Demeyer wrote:
> On 2017-09-06 17:24, Erik Bray wrote:
>>
>> Interpreting
>> "str" as "bytes" is the only way it can be if language_level=2.
>
>
> I think you are misunderstanding. You didn't post the complete C code
> generated by Cython:
>
> __pyx_t_4 =
On 2017-09-06 17:24, Erik Bray wrote:
Interpreting
"str" as "bytes" is the only way it can be if language_level=2.
I think you are misunderstanding. You didn't post the complete C code
generated by Cython:
__pyx_t_4 = __Pyx_PyBytes_FromString(__pyx_v_s); if
(unlikely(!__pyx_t_4)) __PYX_ER
On Wed, Sep 6, 2017 at 5:13 PM, Jeroen Demeyer wrote:
> On 2017-09-06 17:05, Erik Bray wrote:
>>
>> "language level 2" [...], where "str" means "bytes".
>
>
> [citation needed]
>
> Where did you get the idea that Cython interprets "str" as "bytes" with
> Python 3?
>
> In https://trac.sagemath.org/
On Wed, Sep 6, 2017 at 5:05 PM, Erik Bray wrote:
> On Wed, Sep 6, 2017 at 3:35 PM, Frédéric Chapoton
> wrote:
>> This [b'1', b'1'] is the next problem, once the hash issue is corrected. I
>> only have a branch with the added hash on my own computer at home, so I can
>> not push it to trac immedi
On 2017-09-06 17:05, Erik Bray wrote:
"language level 2" [...], where "str" means "bytes".
[citation needed]
Where did you get the idea that Cython interprets "str" as "bytes" with
Python 3?
In https://trac.sagemath.org/ticket/23089 I argued *against* changing
the Cython language_level.
On Wed, Sep 6, 2017 at 3:35 PM, Frédéric Chapoton wrote:
> This [b'1', b'1'] is the next problem, once the hash issue is corrected. I
> only have a branch with the added hash on my own computer at home, so I can
> not push it to trac immediatly.
This error (and many others like it) comes from the
This [b'1', b'1'] is the next problem, once the hash issue is corrected. I
only have a branch with the added hash on my own computer at home, so I can
not push it to trac immediatly.
Le mercredi 6 septembre 2017 15:29:01 UTC+2, Erik Bray a écrit :
>
> On Mon, Aug 28, 2017 at 8:45 PM, Frédéric C
On Mon, Aug 28, 2017 at 8:45 PM, Frédéric Chapoton wrote:
> Indeed, adding __hash__ to the CDF class seems to fix this specific issue. I
> wonder how many hash we are going to be forced to add..
I've finally gotten my python3 build to a point where I'm able to
reproduce this problem. Have you co
Indeed, adding __hash__ to the CDF class seems to fix this specific issue.
I wonder how many hash we are going to be forced to add..
The next problem is very strange. During the initialisation of the damn I
symbol (that seems to be responsible for a non-negligible part of our
startup time), the
I'm guessing it might be this from
https://docs.python.org/3.6/reference/datamodel.html#object.__hash__
A class that overrides __eq__() and does not define __hash__() will have
its __hash__() implicitly set to None.
Python2:
>>> class X(tuple):
... def __eq__(self, other): return False
Hello,
during my experiments with python3, I am now stopped on a crash involving
hash of Complex interval fields.
The full log is attached. It ends with
TypeError: key = (Complex Interval Field with 53 bits of precision, ('x',),
False, None)
unhashable type: 'ComplexIntervalField_class_with_c
12 matches
Mail list logo
