From tracker at bugs.pypy.org  Thu May  3 14:32:47 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Thu, 03 May 2012 12:32:47 +0000
Subject: [pypy-issue] [issue1098] sys.stdout.close() from interactive
	session crashes pypy	and messes up terminal
In-Reply-To: <1332636682.08.0.8292785494.issue1098@bugs.pypy.org>
Message-ID: <1336048367.33.0.954898695441.issue1098@bugs.pypy.org>


Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

fixed in pyrepl, will sync after a soon to be release

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1098>
________________________________________

From tracker at bugs.pypy.org  Sat May  5 10:25:47 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Sat, 05 May 2012 08:25:47 +0000
Subject: [pypy-issue] [issue1137] "TypeError: 'int32' has no length"
In-Reply-To: <1335045027.45.0.646991371551.issue1137@bugs.pypy.org>
Message-ID: <1336206347.7.0.126198297763.issue1137@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Review - please use PEP8 (no except: pass in one line). Also, is it really smart 
to catch all the exceptions? I bet we want to catch only OperationError and even 
so, not all of them. For example this:

class A(object):
    def __index__(self):
        1/0

[1, 2, 3][A()]

raises ZeroDivisionError as expected

----------
nosy: +fijal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1137>
________________________________________

From tracker at bugs.pypy.org  Sat May  5 15:09:38 2012
From: tracker at bugs.pypy.org (timo)
Date: Sat, 05 May 2012 13:09:38 +0000
Subject: [pypy-issue] [issue1137] "TypeError: 'int32' has no length"
In-Reply-To: <1335045027.45.0.646991371551.issue1137@bugs.pypy.org>
Message-ID: <1336223378.06.0.397897662607.issue1137@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

it seems numpy disagrees with regular python behavior:

           __int__      __index__
python    TypeError      propagate
numpy     IndexError     IndexError
numpypy       ?              ?

I would suggest emulating numpy here, because that's what we want in the end:
compatibility with numpy.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1137>
________________________________________

From tracker at bugs.pypy.org  Sun May  6 18:02:47 2012
From: tracker at bugs.pypy.org (mgibsonbr)
Date: Sun, 06 May 2012 16:02:47 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>


New submission from mgibsonbr <mgibsonbr at gmail.com>:

If an unicode string is entered via command line (pypy-1.8.0 on Windows XP), say:

>>>> u'???'
u'\xa0\u20ac\xa4'

An incorrect string is created. If the same is typed either in PyPy on Linux or
CPython on all platforms or read from a file using codecs.open and the right
encoding, the result is:

u'\xe1\xc7\xf1'

Which is the correct interpretation of that input. A related issue (might be
already covered by Issue402 I don't know) is that PyPy don't seem to recogize
coding headers:

# -*- coding:utf-8 -*-

So the same problem above manifests if there are unescaped unicode strings in
the source files (or doctests for that matter). For a quick way to replicate
that, try running doctest on this file
[difnet.com.br/opensource/unicode_hack.py] (relevant part in the end or it),
should work fine on CPython or PyPy on Linux, but not on PyPy on Windows.

----------
messages: 4303
nosy: mgibsonbr, pypy-issue
priority: bug
status: unread
title: Wrong encoding on Windows command line (and source loading)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1139>
________________________________________

From tracker at bugs.pypy.org  Sun May  6 22:34:09 2012
From: tracker at bugs.pypy.org (mattip)
Date: Sun, 06 May 2012 20:34:09 +0000
Subject: [pypy-issue] [issue1139] Wrong encoding on Windows command line
	(and source	loading)
In-Reply-To: <1336320167.47.0.0948539155377.issue1139@bugs.pypy.org>
Message-ID: <1336336449.25.0.86575014338.issue1139@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

confirmed, can be tested untranslated by "python pypy/translator/goal/app_main.py"
probable suspect is set_io_encoding
This is not connected to Issue402

----------
nosy: +mattip
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1139>
________________________________________

From tracker at bugs.pypy.org  Tue May  8 14:22:21 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Tue, 08 May 2012 12:22:21 +0000
Subject: [pypy-issue] [issue1140] numpypy: slower than CPython NumPy on the
	vectorized code
In-Reply-To: <1336479741.43.0.520723870573.issue1140@bugs.pypy.org>
Message-ID: <1336479741.43.0.520723870573.issue1140@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

for some vectorized functions PyPy is about 5 times slower, see
http://pastebin.com/W2xy0cwE . DerApproximator.py and this test file can be
downloaded from https://www.box.com/s/5034296ac9cf838db382.
Setting 
from _numpypy.pypy import set_invalidation
set_invalidation(False)
decreases PyPy time from 2.4 sec to 1.5 sec, but it's still too far from CPython
NumPy result (0.5 sec).

----------
messages: 4305
nosy: Dmitrey, pypy-issue
priority: performance bug
status: unread
title: numpypy: slower than CPython NumPy on the vectorized code

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1140>
________________________________________

From tracker at bugs.pypy.org  Tue May  8 20:14:33 2012
From: tracker at bugs.pypy.org (Hakan Ardo)
Date: Tue, 08 May 2012 18:14:33 +0000
Subject: [pypy-issue] [issue1080] jit errors (infinite loop and str instead
	of token object)
In-Reply-To: <1331246976.69.0.646014776853.issue1080@bugs.pypy.org>
Message-ID: <1336500873.23.0.250529202241.issue1080@bugs.pypy.org>


Hakan Ardo <hakan at debian.org> added the comment:

I now believe this is working as expected. I still see issues with disabling 
OptRewrite (and there might be others), but fully supporting disabling any set of optimizations seems to big a task I'm afarid.

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1080>
________________________________________

From tracker at bugs.pypy.org  Sun May 13 15:24:28 2012
From: tracker at bugs.pypy.org (Zaar Hai)
Date: Sun, 13 May 2012 13:24:28 +0000
Subject: [pypy-issue] [issue1141] MySQLdb-1.2.3 does not work with latest
	PyPy 1.8
In-Reply-To: <1336915468.06.0.906286060358.issue1141@bugs.pypy.org>
Message-ID: <1336915468.06.0.906286060358.issue1141@bugs.pypy.org>


New submission from Zaar Hai <haizaar at gmail.com>:

The following wiki page https://bitbucket.org/pypy/compatibility/wiki/mysql-
python states that MySQLdb-python should work out of the box with PyPy.

However its not the case - I get AssertionError while trying to execute the 
query.

Details:
Python 2.7.2 (0e28b379d8b3, Feb 09 2012, 19:41:03)
[PyPy 1.8.0 with GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``why there is no "PyPy 1.4
released" in topic any more?''
>>>> import MySQLdb
>>>> db = MySQLdb.connect(host='localhost', user='xxx', passwd='xxx')
>>>> cur = db.cursor()
>>>> cur.execute("show databses")
RPython traceback:
  File "module_cpyext_api.c", line 14137, in PyErr_SetObject
  File "module_cpyext_pyobject.c", line 148, in from_ref
Fatal RPython error: AssertionError
Aborted

----------
messages: 4307
nosy: haizaar, pypy-issue
priority: bug
status: unread
title: MySQLdb-1.2.3 does not work with latest PyPy 1.8

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1141>
________________________________________

From tracker at bugs.pypy.org  Sun May 13 15:59:55 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sun, 13 May 2012 13:59:55 +0000
Subject: [pypy-issue] [issue1141] MySQLdb-1.2.3 does not work with latest
	PyPy 1.8
In-Reply-To: <1336915468.06.0.906286060358.issue1141@bugs.pypy.org>
Message-ID: <1336917595.11.0.458968010107.issue1141@bugs.pypy.org>


Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

the page states that you need to apply a patch, did you?

----------
nosy: +ronny
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1141>
________________________________________

From tracker at bugs.pypy.org  Sun May 13 17:14:55 2012
From: tracker at bugs.pypy.org (Zaar Hai)
Date: Sun, 13 May 2012 15:14:55 +0000
Subject: [pypy-issue] [issue1141] MySQLdb-1.2.3 does not work with latest
	PyPy 1.8
In-Reply-To: <1336915468.06.0.906286060358.issue1141@bugs.pypy.org>
Message-ID: <1336922095.35.0.0725521294204.issue1141@bugs.pypy.org>


Zaar Hai <haizaar at gmail.com> added the comment:

For some reason I've understood that patch is only required for the test suite.

Copying the patch from the wiki did not work - I've had to adjust it manually. 
But after patching everything is working just wonders! Many thanks for that!

I've attached the working patch for convenience. Can you please add it as an attachment to the wiki page?

Thanks.

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1141>
________________________________________

From tracker at bugs.pypy.org  Sun May 13 17:19:22 2012
From: tracker at bugs.pypy.org (Ronny Pfannschmidt)
Date: Sun, 13 May 2012 15:19:22 +0000
Subject: [pypy-issue] [issue1141] MySQLdb-1.2.3 does not work with latest
	PyPy 1.8
In-Reply-To: <1336915468.06.0.906286060358.issue1141@bugs.pypy.org>
Message-ID: <1336922362.16.0.0249912403009.issue1141@bugs.pypy.org>


Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> added the comment:

i updated the wiki page,
thanks for the patch update

please check if the wording is better now

----------
status: chatting -> testing

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1141>
________________________________________

From tracker at bugs.pypy.org  Sun May 13 17:30:57 2012
From: tracker at bugs.pypy.org (Zaar Hai)
Date: Sun, 13 May 2012 15:30:57 +0000
Subject: [pypy-issue] [issue1141] MySQLdb-1.2.3 does not work with latest
	PyPy 1.8
In-Reply-To: <1336915468.06.0.906286060358.issue1141@bugs.pypy.org>
Message-ID: <1336923057.34.0.638276518856.issue1141@bugs.pypy.org>


Zaar Hai <haizaar at gmail.com> added the comment:

Yes, the wording is much better.

If you can just attached the patch to the wiki (or upload it elsewhere in the 
raw form) it would somewhat simplify things for other users.

Thanks,
Zaar

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1141>
________________________________________

From tracker at bugs.pypy.org  Tue May 15 14:16:39 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 15 May 2012 12:16:39 +0000
Subject: [pypy-issue] [issue1103] NumPyPy using broadcasting gives
	numerically incorrect	results
In-Reply-To: <1333314274.07.0.640158434268.issue1103@bugs.pypy.org>
Message-ID: <1337084199.85.0.702856286296.issue1103@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This seems to be fixed by now, I cannot reproduce it with recent PyPy. At least 
asserts work. Please reopen it in case it's not true.

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1103>
________________________________________

From tracker at bugs.pypy.org  Tue May 15 16:59:44 2012
From: tracker at bugs.pypy.org (Senyai)
Date: Tue, 15 May 2012 14:59:44 +0000
Subject: [pypy-issue] [issue1142] Maximum recursion depth exceeded VS Stack
	overflow
In-Reply-To: <1337093984.14.0.387583862777.issue1142@bugs.pypy.org>
Message-ID: <1337093984.14.0.387583862777.issue1142@bugs.pypy.org>


New submission from Senyai <senyai at gmail.com>:

# Hi! I just want to mention difference between CPython 2.7.2 and pypy-1.8
# CPython outputs 784799 MemoryError: Stack overflow
# and pypy 51691 RuntimeError: maximum recursion depth exceeded

from itertools import count, ifilter
def sieve():
    seq = count(2)
    while True:
        p = seq.next()
        seq = ifilter(p.__rmod__, seq)
        yield p

for n in sieve():
    print n

# Thx

----------
messages: 4313
nosy: pypy-issue, senyai
priority: bug
status: unread
title: Maximum recursion depth exceeded VS Stack overflow

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1142>
________________________________________

From tracker at bugs.pypy.org  Tue May 15 17:18:21 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 15 May 2012 15:18:21 +0000
Subject: [pypy-issue] [issue1142] Maximum recursion depth exceeded VS Stack
	overflow
In-Reply-To: <1337093984.14.0.387583862777.issue1142@bugs.pypy.org>
Message-ID: <1337095101.61.0.155282071706.issue1142@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Bah, CPython might raise randomly MemoryError or RuntimeError when the stack is
full.  PyPy consistently raises RuntimeError.  I'm sure there are cases where
users expect and catch MemoryError, and other cases where they expect and catch
RuntimeError, making it a mess to support...

----------
nosy: +arigo
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1142>
________________________________________

From tracker at bugs.pypy.org  Tue May 15 17:46:39 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Tue, 15 May 2012 15:46:39 +0000
Subject: [pypy-issue] [issue1142] Maximum recursion depth exceeded VS Stack
	overflow
In-Reply-To: <1337093984.14.0.387583862777.issue1142@bugs.pypy.org>
Message-ID: <1337096799.84.0.398735027945.issue1142@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Re-bah.  Trying Python 2.6 ends up with a segmentation fault.  I suppose that
detection was added in Python 2.7, but I have no clue why MemoryError was picked
rather than RuntimeError again...

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1142>
________________________________________

From tracker at bugs.pypy.org  Wed May 16 21:09:18 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 16 May 2012 19:09:18 +0000
Subject: [pypy-issue] [issue1143] numpypy: bug in array_equal
In-Reply-To: <1337195357.97.0.624497287196.issue1143@bugs.pypy.org>
Message-ID: <1337195357.97.0.624497287196.issue1143@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

np.array_equal(4,4)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File
"/home/dmitrey/Install/pypy-c-jit-55112-18e6d6d81497-linux/lib_pypy/numpypy/core/numeric.py",
line 348, in array_equal
    return bool((a1 == a2).all())
AttributeError: 'bool_' object has no attribute 'all'

in CPython numpy it's just True

----------
messages: 4317
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: bug in array_equal

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1143>
________________________________________

From tracker at bugs.pypy.org  Thu May 17 13:20:56 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 17 May 2012 11:20:56 +0000
Subject: [pypy-issue] [issue1144] numpypy: bug with np.all(True) and
	np.any(True)
In-Reply-To: <1337253656.73.0.97210490097.issue1144@bugs.pypy.org>
Message-ID: <1337253656.73.0.97210490097.issue1144@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>>> import numpypy as np
>>>> np.all(True)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File
"/home/dmitrey/Install/pypy-c-jit-55112-18e6d6d81497-linux/lib_pypy/numpypy/core/fromnumeric.py",
line 1546, in all
    return a.all()
TypeError: cannot reduce on a scalar

>>>> np.any(True)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File
"/home/dmitrey/Install/pypy-c-jit-55112-18e6d6d81497-linux/lib_pypy/numpypy/core/fromnumeric.py",
line 1482, in any
    return a.any()
TypeError: cannot reduce on a scalar

in cpython numpy it's just True

----------
messages: 4318
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: bug with np.all(True) and np.any(True)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1144>
________________________________________

From tracker at bugs.pypy.org  Fri May 18 14:51:15 2012
From: tracker at bugs.pypy.org (Chris Emerson)
Date: Fri, 18 May 2012 12:51:15 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>


New submission from Chris Emerson <pypy-bug at mail.nosreme.org>:

I've found a case where in PyPy with numpypy, a relatively simple function takes 
exponential time in the input (attached).  It's a reduced version of the CPython 
numpy.i0.

The test runs _chbevl(x, l) with increasing values of l, which each take ~2x the 
previous time (it should be linear), until it runs out of memory.  All the time 
seems to be taken when accessing the result array; it's very quick if you eg 
only look at the shape of the result but don't access any entries.

Some of the output (l, time in seconds) on PyPy on Win32 (similar with 1.8 or 
the last Win32 nightly build):

...
19 0.495367886011
20 1.02301351871
21 2.02426845859
22 3.96347008585
23 8.85665853394
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "test.py", line 26, in <module>
    t = timer.timeit(number=1)
  File "C:\cme\software\pypy-1.8\lib-python\2.7\timeit.py", line 194, in timeit
    timing = self.inner(it, self.timer)
  File "<timeit-src>", line 20, in inner
  File "<timeit-src>", line 16, in test
MemoryError

and the same with Python 2.7:
...
19 7.35256188663e-05
20 0.000114715363467
21 0.000160139567793
22 8.27644400851e-05
23 9.00785068833e-05
24 8.8923654231e-05
25 9.12333595357e-05
26 9.46979174927e-05
27 9.85474263339e-05
28 0.000101627033407
29 0.000106246444016

Regards,

Chris

----------
files: test.py
messages: 4319
nosy: pypy-issue
priority: performance bug
status: unread
title: Exponential time on iterative numpy function

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1145>
________________________________________
-------------- next part --------------

import sys
try:
    from numpypy import arange
except ImportError:
    from numpy import arange

try:
    from timeit import Timer
    for i in range(2, 30):
        timer = Timer(setup="""
from numpy import arange
results = []

def _chbevl(x, l):
    b0 = 0

    for i in range(1,l):
        b0 = x*b0 - b0

    return b0

def test(x, y):
    results.append(_chbevl(x, len(y))[0])
""", stmt='test(arange(1), arange(%d))' % i)
        t = timer.timeit(number=1)
        print i, t
except KeyboardInterrupt:
    pass

From tracker at bugs.pypy.org  Sun May 20 22:38:14 2012
From: tracker at bugs.pypy.org (Justin Peel)
Date: Sun, 20 May 2012 20:38:14 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1337546294.57.0.793128865048.issue1145@bugs.pypy.org>


Justin Peel <peelpy at gmail.com> added the comment:

If you add in the line 'print b0' after 'b0 = x*b0 - b0' (and keeping it in the 
loop) then it behaves fine in pypy. This suggests to me that this is a JIT-
related problem.

----------
nosy: +justinpeel
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1145>
________________________________________

From tracker at bugs.pypy.org  Sun May 20 22:39:24 2012
From: tracker at bugs.pypy.org (Alex Gaynor)
Date: Sun, 20 May 2012 20:39:24 +0000
Subject: [pypy-issue] [issue1145] Exponential time on iterative numpy
	function
In-Reply-To: <1337345475.98.0.600929945005.issue1145@bugs.pypy.org>
Message-ID: <1337546364.17.0.988254992264.issue1145@bugs.pypy.org>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

It's not JIT-related.  It's because of the lazy evaluation.

----------
nosy: +agaynor

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1145>
________________________________________

From tracker at bugs.pypy.org  Tue May 22 13:25:31 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Tue, 22 May 2012 11:25:31 +0000
Subject: [pypy-issue] [issue1146] numpypy: bug with 1-d array of length 1
	.item()
In-Reply-To: <1337685931.94.0.807308630748.issue1146@bugs.pypy.org>
Message-ID: <1337685931.94.0.807308630748.issue1146@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

NumPy:
>>> from numpy import array
>>> array([1]).item()
1
NumPyPy:
>>>> from numpypy import array
>>>> array([1]).item()
Traceback (most recent call last):
  File "<console>", line 1, in <module>
ValueError: index out of bounds

----------
messages: 4322
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: bug with 1-d array of length 1 .item()

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1146>
________________________________________

From tracker at bugs.pypy.org  Tue May 22 13:46:26 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Tue, 22 May 2012 11:46:26 +0000
Subject: [pypy-issue] [issue1147] numpypy: sum(scalar) doesn't work
In-Reply-To: <1337687186.21.0.202013070826.issue1147@bugs.pypy.org>
Message-ID: <1337687186.21.0.202013070826.issue1147@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> from numpy import sum
>>> sum(0.1)
0.10000000000000001

>>>> from numpypy import sum
>>>> sum(0.1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File
"/home/dmitrey/Install/pypy-c-jit-55112-18e6d6d81497-linux/lib_pypy/numpypy/core/fromnumeric.py",
line 1366, in sum
    return a.sum(axis=axis)
TypeError: cannot reduce on a scalar

----------
messages: 4323
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: sum(scalar) doesn't work

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1147>
________________________________________

From tracker at bugs.pypy.org  Tue May 22 15:44:24 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Tue, 22 May 2012 13:44:24 +0000
Subject: [pypy-issue] [issue1148] numpypy: int32 is unhashable
In-Reply-To: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>
Message-ID: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>> from numpy import int32
>>> {int32(2):4}
{2: 4}

>>>> from numpypy import int32
>>>> {int32(2):4}
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: unsupported operand type for hash: 'int32'

----------
messages: 4324
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: int32 is unhashable

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1148>
________________________________________

From tracker at bugs.pypy.org  Tue May 22 22:17:37 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Tue, 22 May 2012 20:17:37 +0000
Subject: [pypy-issue] [issue1147] numpypy: sum(scalar) doesn't work
In-Reply-To: <1337687186.21.0.202013070826.issue1147@bugs.pypy.org>
Message-ID: <1337717857.01.0.0849212493011.issue1147@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

This is a dupe of: https://bugs.pypy.org/issue1129

----------
nosy: +mikefc
status: unread -> duplicate

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1147>
________________________________________

From tracker at bugs.pypy.org  Wed May 23 00:19:51 2012
From: tracker at bugs.pypy.org (chrysn)
Date: Tue, 22 May 2012 22:19:51 +0000
Subject: [pypy-issue] [issue1149] BeautifulSoup aborts parsing on quotation
	errors
In-Reply-To: <1337725191.44.0.276673746674.issue1149@bugs.pypy.org>
Message-ID: <1337725191.44.0.276673746674.issue1149@bugs.pypy.org>


New submission from chrysn <chrysn at fsfe.org>:

the BeautifulSoup module behaves differently when run under pypy than when run 
in cpython.

when quotes within quoted attributes (think javascript) occur under cpython, the 
respective attribute gets split up, but the effect is local. with pypy, the 
element and all elements after it are just dropped.

complete examples:

$ python -c 'from bs4 import BeautifulSoup; s = """<div><em>a</em><a 
onClick="a("b")">b</a><em>c</em></div>"""; print BeautifulSoup(s)'
<html><body><div><em>a</em><a b="" onclick="a(">b</a><em>c</em></div></body>
</html>
$ PYTHONPATH='/usr/lib/python2.7/dist-packages/' pypy -c 'from bs4 import 
BeautifulSoup; s = """<div><em>a</em><a onClick="a("b")">b</a><em>c</em>
</div>"""; print BeautifulSoup(s)'
<div><em>a</em></div>

no further investigation into the internals of bs4 were conducted on my part so 
far; reporting this issue to the pypy bug tracker as suggested on irc.

versions and other details:

$ pypy --version
Python 2.7.2 (1.8+dfsg-2, Feb 18 2012, 07:30:46)
[PyPy 1.8.0 with GCC 4.6.2]
$ python --version
Python 2.7.3rc2

beautiful soup version: 4.0.5-1

running on linux 3.1.0-1-amd64, the rest of the system is debian sid. all 
involved software runs native 64bit.

----------
messages: 4326
nosy: chrysn, pypy-issue
priority: bug
status: unread
title: BeautifulSoup aborts parsing on quotation errors

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1149>
________________________________________

From tracker at bugs.pypy.org  Wed May 23 00:45:19 2012
From: tracker at bugs.pypy.org (chrysn)
Date: Tue, 22 May 2012 22:45:19 +0000
Subject: [pypy-issue] [issue1149] BeautifulSoup aborts parsing on quotation
	errors
In-Reply-To: <1337725191.44.0.276673746674.issue1149@bugs.pypy.org>
Message-ID: <1337726719.55.0.464977864966.issue1149@bugs.pypy.org>


chrysn <chrysn at fsfe.org> added the comment:

drilling down into BeautifulSoup made the cause of this issue obvious: bs4 uses 
lxml for parsing *if it is available* and falls back to another parser that 
handles said html code worse. lxml is not compatible with pypy due to cython 
code according to [1].

[1]  https://bitbucket.org/pypy/compatibility/wiki/lxml

please close or reassign this bug report as it is customary here.

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1149>
________________________________________

From tracker at bugs.pypy.org  Wed May 23 19:37:28 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Wed, 23 May 2012 17:37:28 +0000
Subject: [pypy-issue] [issue1150] numpypy: critical bug in array indexation
	even for 1-d	arrays
In-Reply-To: <1337794648.2.0.464627060343.issue1150@bugs.pypy.org>
Message-ID: <1337794648.2.0.464627060343.issue1150@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>>> from numpypy import *
>>>> a=array([1.0,-1.0])
>>>> a[a<0] = -a[a<0]
>>>> a
array([  1.00000000e+000,  -1.29890872e-197])

>>>> a=array([1.0,-1.0])
>>>> ind = a<0
>>>> a[ind] = -a[ind]
>>>> a
array([  1.00000000e+000,  -1.82077607e+223])

>>>> b = array([1.0, -1.0])
>>>> a = array([1.0, -1.0])
>>>> a[a<0] = b[b<0]
>>>> a
array([  1.00000000e+000,   2.36379232e+232])

Also, is there any milestone for fancy indexing with int arrays?

----------
messages: 4328
nosy: Dmitrey, pypy-issue
priority: critical
status: unread
title: numpypy: critical bug in array indexation even for 1-d arrays

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1150>
________________________________________

From tracker at bugs.pypy.org  Fri May 25 13:36:15 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Fri, 25 May 2012 11:36:15 +0000
Subject: [pypy-issue] [issue1151] numpypy: bug with array.dtype != object
In-Reply-To: <1337945774.95.0.713160069656.issue1151@bugs.pypy.org>
Message-ID: <1337945774.95.0.713160069656.issue1151@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

array(1.0).dtype != object
in numpy: True
in numpypy:
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: data type not understood

----------
messages: 4329
nosy: Dmitrey, pypy-issue
priority: bug
status: unread
title: numpypy: bug with array.dtype != object

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1151>
________________________________________

From tracker at bugs.pypy.org  Sat May 26 12:48:18 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 26 May 2012 10:48:18 +0000
Subject: [pypy-issue] [issue1142] Maximum recursion depth exceeded VS Stack
	overflow
In-Reply-To: <1337093984.14.0.387583862777.issue1142@bugs.pypy.org>
Message-ID: <1338029298.56.0.55605529796.issue1142@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Closing this as Won't Fix.  RuntimeError is the exception that was historically
used for stack overflows, and the only one raised by PyPy.

----------
status: chatting -> wontfix

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1142>
________________________________________

From tracker at bugs.pypy.org  Sat May 26 12:56:19 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 26 May 2012 10:56:19 +0000
Subject: [pypy-issue] [issue1132] Bugs in Unicode data
In-Reply-To: <1334673236.4.0.147004791222.issue1132@bugs.pypy.org>
Message-ID: <1338029779.29.0.218093832533.issue1132@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

pypy/module/unicodedata/generate_unicode.py line 404.  I have no clue what the
value of cjk_end should be on Unicode 5.2.0.

----------
nosy: +arigo

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1132>
________________________________________

From tracker at bugs.pypy.org  Sat May 26 13:07:19 2012
From: tracker at bugs.pypy.org (Armin Rigo)
Date: Sat, 26 May 2012 11:07:19 +0000
Subject: [pypy-issue] [issue1132] Bugs in Unicode data
In-Reply-To: <1334673236.4.0.147004791222.issue1132@bugs.pypy.org>
Message-ID: <1338030439.91.0.10809838715.issue1132@bugs.pypy.org>


Armin Rigo <armin.rigo at gmail.com> added the comment:

Found it in CPython.  There is even a 4th interval of cjk data now.  Fixed in
fe62c8288434.

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1132>
________________________________________

From tracker at bugs.pypy.org  Sun May 27 00:51:21 2012
From: tracker at bugs.pypy.org (timo)
Date: Sat, 26 May 2012 22:51:21 +0000
Subject: [pypy-issue] [issue1148] numpypy: int64 is unhashable
In-Reply-To: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>
Message-ID: <1338072681.7.0.882938688582.issue1148@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

this seems to work for me on my nightly pypy from today, but i can't see any
code that might have fixed that in pypy/module/micronumpy/ since you reported
this bug.

I do however have the same proleb with int64, so I've changed the title to
reflect this.

----------
nosy: +timo
status: unread -> chatting
title: numpypy: int32 is unhashable -> numpypy: int64 is unhashable

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1148>
________________________________________

From tracker at bugs.pypy.org  Sun May 27 00:58:55 2012
From: tracker at bugs.pypy.org (timo)
Date: Sat, 26 May 2012 22:58:55 +0000
Subject: [pypy-issue] [issue1148] numpypy: int64 is unhashable
In-Reply-To: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>
Message-ID: <1338073135.69.0.692879062287.issue1148@bugs.pypy.org>


timo <timonator at perpetuum-immobile.de> added the comment:

I created test cases for hashability of int8 through int64 (int128 doesn't
exist, it seems)

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1148>
________________________________________

From tracker at bugs.pypy.org  Sun May 27 01:28:27 2012
From: tracker at bugs.pypy.org (timo)
Date: Sat, 26 May 2012 23:28:27 +0000
Subject: [pypy-issue] [issue1152] numpy: int and int32 give different keys
	to dictionary
In-Reply-To: <1338074907.85.0.324002251477.issue1152@bugs.pypy.org>
Message-ID: <1338074907.85.0.324002251477.issue1152@bugs.pypy.org>


New submission from timo <timonator at perpetuum-immobile.de>:

try this:

>>> import numpy as np
>>> d = {0: "success"}
>>> print d[0]
success
>>> print d[np.int32(0)]
success

but on pypy:
>>>> import numpypy as np
>>>> d = {0: "success"}
>>>> print d[np.int32(0)]
KeyError: 0

----------
messages: 4335
nosy: pypy-issue, timo
priority: bug
status: unread
title: numpy: int and int32 give different keys to dictionary

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1152>
________________________________________

From tracker at bugs.pypy.org  Sun May 27 10:09:35 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Sun, 27 May 2012 08:09:35 +0000
Subject: [pypy-issue] [issue1153] numpypy: critical bug with array.size
In-Reply-To: <1338106175.95.0.776500262156.issue1153@bugs.pypy.org>
Message-ID: <1338106175.95.0.776500262156.issue1153@bugs.pypy.org>


New submission from Dmitrey <dmitrey15 at ukr.net>:

>>>> from numpypy import arange,cos
>>>> x = cos(1+arange(10))
>>>> x.shape
(10,)
>>>> len(x)
10
>>>> x
array([ 0.54030231, -0.41614684, -0.9899925 , -0.65364362,  0.28366219,
        0.96017029,  0.75390225, -0.14550003, -0.91113026, -0.83907153])
>>>> x.size
5
what's the deuce - why 5, not 10??

tried with today's nightly build as well; linux ubuntu 32-bit Intel Atom

----------
messages: 4336
nosy: Dmitrey, pypy-issue
priority: critical
status: unread
title: numpypy: critical bug with array.size

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1153>
________________________________________

From tracker at bugs.pypy.org  Mon May 28 19:46:19 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Mon, 28 May 2012 17:46:19 +0000
Subject: [pypy-issue] [issue1154] IndexError in jitviewer
In-Reply-To: <1338227179.23.0.410269267737.issue1154@bugs.pypy.org>
Message-ID: <1338227179.23.0.410269267737.issue1154@bugs.pypy.org>


New submission from kostia.lopuhin <kostia.lopuhin at gmail.com>:

I get an exception when trying to load jitviewer webpage:

127.0.0.1 - - [28/May/2012 20:56:02] "GET / HTTP/1.1" 500 -
Traceback (most recent call last):
  File ".../pypy-env/site-packages/flask/app.py", line 1518, in __call__
    return self.wsgi_app(environ, start_response)
  File ".../pypy-env/site-packages/flask/app.py", line 1506, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File ".../pypy-env/site-packages/flask/app.py", line 1504, in wsgi_app
    response = self.full_dispatch_request()
  File ".../pypy-env/site-packages/flask/app.py", line 1264, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File ".../pypy-env/site-packages/flask/app.py", line 1262, in full_dispatch_request
    rv = self.dispatch_request()
  File ".../pypy-env/site-packages/flask/app.py", line 1248, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/kostia/programming/python/jitviewer/_jitviewer/app.py", line 95, in index
    loopname=name)
  File "/home/kostia/programming/python/pypy/pypy/tool/jitlogparser/parser.py", line 265, in 
from_operations
    if so_far:
  File "/home/kostia/programming/python/pypy/pypy/tool/jitlogparser/parser.py", line 162, in 
__init__
    self.parse_code_data(op.args[2][1:-1]
IndexError: list index out of range

I get the same error both on log.pypylog, supplied with jitviewer, and on log from my 
application. If I change op.args[2] to op.args[1] everything seems to work fine (op.args is a 
two element list).

Steps to reproduce:

1) Install 1.8 build locally (tried a nighly build, got same results)
2) hg clone pypy repository
3) add it to PYTHONPATH
4) make a virtualenv with pypy from step 1, activate it
5) hg clone jitviewer repo
6) run python setup.py develop in jitviewer dir
7) run jitviewer log.pypylog
8) Go to localhost:5000
9) Observe traceback

Using Ubuntu 12.04 64 bit.

I understand this is highly unlikely that this is a bug in pypy or jitviewer, just wired...

----------
messages: 4337
nosy: kostia.lopuhin, pypy-issue
priority: bug
status: unread
title: IndexError in jitviewer

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1154>
________________________________________

From tracker at bugs.pypy.org  Mon May 28 22:06:00 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Mon, 28 May 2012 20:06:00 +0000
Subject: [pypy-issue] [issue1154] IndexError in jitviewer
In-Reply-To: <1338227179.23.0.410269267737.issue1154@bugs.pypy.org>
Message-ID: <1338235560.74.0.837564183503.issue1154@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

JitViewer trunk works with pypy trunk, pypy-1.8 works with jitviewer 1.0. Where 
can we put it so it's nicely documented? Maybe a nice error would help?

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1154>
________________________________________

From tracker at bugs.pypy.org  Tue May 29 07:03:33 2012
From: tracker at bugs.pypy.org (kostia.lopuhin)
Date: Tue, 29 May 2012 05:03:33 +0000
Subject: [pypy-issue] [issue1154] IndexError in jitviewer
In-Reply-To: <1338227179.23.0.410269267737.issue1154@bugs.pypy.org>
Message-ID: <1338267813.32.0.863405335919.issue1154@bugs.pypy.org>


kostia.lopuhin <kostia.lopuhin at gmail.com> added the comment:

I think it is enough to mention it in the README - which is small and already has 
a similar note on Mac problems. 
I think I tried it with trunk too, will try again. Fell free to close the issue, 
thank you!

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1154>
________________________________________

From tracker at bugs.pypy.org  Tue May 29 18:50:27 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 29 May 2012 16:50:27 +0000
Subject: [pypy-issue] [issue1150] numpypy: critical bug in array indexation
	even for 1-d	arrays
In-Reply-To: <1337794648.2.0.464627060343.issue1150@bugs.pypy.org>
Message-ID: <1338310226.97.0.285451233628.issue1150@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Ok, found the reason for this one. I'll think about a solution, but that probably 
is for tomorrow.

----------
nosy: +fijal
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1150>
________________________________________

From tracker at bugs.pypy.org  Tue May 29 18:58:27 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 29 May 2012 16:58:27 +0000
Subject: [pypy-issue] [issue1150] numpypy: critical bug in array indexation
	even for 1-d	arrays
In-Reply-To: <1337794648.2.0.464627060343.issue1150@bugs.pypy.org>
Message-ID: <1338310707.35.0.538903724166.issue1150@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

Should be resolved as of c6d48bfb9d2f

----------
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1150>
________________________________________

From tracker at bugs.pypy.org  Tue May 29 18:59:51 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 29 May 2012 16:59:51 +0000
Subject: [pypy-issue] [issue1063] numpypy Segmentation fault
In-Reply-To: <1329745396.57.0.717360098013.issue1063@bugs.pypy.org>
Message-ID: <1338310791.79.0.00248102173144.issue1063@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

I think it's fixed as of c6d48bfb9d2f, at least I fixed a very similar issue. 
Let's see after the nightly completes (it takes too long on py.py), marking as 
resolved, feel free to reopen if still valid.

----------
nosy: +fijal
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1063>
________________________________________

From tracker at bugs.pypy.org  Tue May 29 19:00:58 2012
From: tracker at bugs.pypy.org (Fijal)
Date: Tue, 29 May 2012 17:00:58 +0000
Subject: [pypy-issue] [issue1016] RPython AssertionError while running async
	io greenlet	test
In-Reply-To: <1327215596.15.0.365402615674.issue1016@bugs.pypy.org>
Message-ID: <1338310858.96.0.298171578883.issue1016@bugs.pypy.org>


Fijal <fijall at gmail.com> added the comment:

This is a release blocker for 1.9, armin can you think about looking into it?

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1016>
________________________________________

From tracker at bugs.pypy.org  Tue May 29 22:35:56 2012
From: tracker at bugs.pypy.org (mattip)
Date: Tue, 29 May 2012 20:35:56 +0000
Subject: [pypy-issue] [issue1155] windows creates 2 bytes unicode dtype
	numpy arrays, not 4 byte
In-Reply-To: <1338323756.89.0.35734871804.issue1155@bugs.pypy.org>
Message-ID: <1338323756.89.0.35734871804.issue1155@bugs.pypy.org>


New submission from mattip <matti.picus at gmail.com>:

The test AppTestStrUnicodeDtypes.().test_unicode_dtype on windows fails. 
Am I correct in that unicode strings are 2 byte per character on windows? 
cpython numpy has a comment in the code /* Numpy Unicode is always 4-byte */ so 
the test is correct, windows somehow needs to create 4 byte dtypes.
I'm willing to fix but need a push in the right direction

----------
messages: 4344
nosy: mattip, pypy-issue
priority: bug
status: unread
title: windows creates 2 bytes unicode dtype numpy arrays, not 4 byte

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1155>
________________________________________

From tracker at bugs.pypy.org  Wed May 30 08:37:41 2012
From: tracker at bugs.pypy.org (Mark Roberts)
Date: Wed, 30 May 2012 06:37:41 +0000
Subject: [pypy-issue] [issue1156] Factory method behavior different from
	CPython
In-Reply-To: <1338359861.08.0.00686924963715.issue1156@bugs.pypy.org>
Message-ID: <1338359861.08.0.00686924963715.issue1156@bugs.pypy.org>


New submission from Mark Roberts <wizzat at gmail.com>:

Originates from Stack Overflow question

$ python3.2 te.py
<__main__.Test object at 0xb6fa740c>
<__main__.Test object at 0xb6fa748c>
<__main__.Test object at 0xb6fa748c>

$ python2.7 te.py
<__main__.Test instance at 0xb72be28c>
<__main__.Test instance at 0xb72be40c>
<__main__.Test instance at 0xb72be40c>

$ pypy te.py
<__main__.Test instance at 0xb6dd71dc>
<__main__.Test instance at 0xb6dd71f0>
<__main__.Test instance at 0xb6dd7204>

----------
messages: 4345
nosy: pypy-issue, wizzat
priority: bug
status: unread
title: Factory method behavior different from CPython

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1156>
________________________________________

From tracker at bugs.pypy.org  Wed May 30 08:38:03 2012
From: tracker at bugs.pypy.org (Mark Roberts)
Date: Wed, 30 May 2012 06:38:03 +0000
Subject: [pypy-issue] [issue1156] Factory method behavior different from
	CPython
In-Reply-To: <1338359861.08.0.00686924963715.issue1156@bugs.pypy.org>
Message-ID: <1338359883.34.0.0805644652905.issue1156@bugs.pypy.org>


Mark Roberts <wizzat at gmail.com> added the comment:

Attaching test file

----------
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1156>
________________________________________

From tracker at bugs.pypy.org  Wed May 30 08:44:43 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Wed, 30 May 2012 06:44:43 +0000
Subject: [pypy-issue] [issue1156] Factory method behavior different from
	CPython
In-Reply-To: <1338359861.08.0.00686924963715.issue1156@bugs.pypy.org>
Message-ID: <1338360283.7.0.994325875425.issue1156@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Stack Overflow Question: 
http://stackoverflow.com/questions/10810926/can-a-python-class-return-a-new-
instance-of-its-class

------------------
te.py
-------------------
class Test:
  def __init__(self):
    self.number = 5

  def returnTest(self):
    return Test()


t = Test()
print(t)
print(t.returnTest())
print(t.returnTest())

----------
nosy: +mikefc

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1156>
________________________________________

From tracker at bugs.pypy.org  Wed May 30 09:01:31 2012
From: tracker at bugs.pypy.org (Mark Roberts)
Date: Wed, 30 May 2012 07:01:31 +0000
Subject: [pypy-issue] [issue1156] Factory method behavior different from
	CPython
In-Reply-To: <1338359861.08.0.00686924963715.issue1156@bugs.pypy.org>
Message-ID: <1338361291.12.0.421659610432.issue1156@bugs.pypy.org>


Mark Roberts <wizzat at gmail.com> added the comment:

This is a difference in garbage collection:

class Test:
  def __init__(self):
    self.number = 5

  def returnTest(self):
    return Test()

t = Test()
tests = [ t.returnTest() for x in range(3) ]
print(tests)



mroberts at eternity8$ python2.7 te.py
[<__main__.Test instance at 0xb725b40c>, <__main__.Test instance at 0xb725b42c>, 
<__main__.Test instance at 0xb725b44c>]
mroberts at eternity8$ python3.2 te.py
[<__main__.Test object at 0xb6f8f40c>, <__main__.Test object at 0xb6f8f42c>, 
<__main__.Test object at 0xb6f8f44c>]
mroberts at eternity8$ pypy te.py
[<__main__.Test instance at 0xb6dac18c>, <__main__.Test instance at 0xb6dac1a0>, 
<__main__.Test instance at 0xb6dac1b4>]

----------
status: chatting -> invalid

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1156>
________________________________________

From tracker at bugs.pypy.org  Thu May 31 07:45:49 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 31 May 2012 05:45:49 +0000
Subject: [pypy-issue] [issue1153] numpypy: critical bug with array.size
In-Reply-To: <1338106175.95.0.776500262156.issue1153@bugs.pypy.org>
Message-ID: <1338443149.09.0.875302207606.issue1153@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

I don't see this on latest osx64 nightly.  Could you try again?  Might be related 
to 32bit vs 64bit perhaps...

==========================================================
Python 2.7.2 (c6d48bfb9d2f, May 30 2012, 03:00:21)
[PyPy 1.9.1-dev0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy 1.3 awaiting release''
>>>> from numpypy import arange, cos
>>>> x = cos(1+arange(10)
.... )
>>>> x
array([ 0.54030231, -0.41614684, -0.9899925 , -0.65364362,  0.28366219,
        0.96017029,  0.75390225, -0.14550003, -0.91113026, -0.83907153])
>>>> x.shape
(10,)
>>>> len(x)
10
>>>> x.size
10

----------
nosy: +mikefc
priority: critical -> bug
status: unread -> chatting

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1153>
________________________________________

From tracker at bugs.pypy.org  Thu May 31 07:48:35 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 31 May 2012 05:48:35 +0000
Subject: [pypy-issue] [issue1148] numpypy: int64 is unhashable
In-Reply-To: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>
Message-ID: <1338443315.04.0.768504788931.issue1148@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

This works fine for me on latest nightly for osx64.  

Dmitrey, can you see if this is fixed for you?

===============================================
Python 2.7.2 (c6d48bfb9d2f, May 30 2012, 03:00:21)
[PyPy 1.9.1-dev0 with GCC 4.2.1] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``PyPy 1.3 awaiting release''
>>>> from numpypy import int32
>>>> {int32(2):4}
{2: 4}

----------
nosy: +mikefc

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1148>
________________________________________

From tracker at bugs.pypy.org  Thu May 31 07:56:10 2012
From: tracker at bugs.pypy.org (mikefc)
Date: Thu, 31 May 2012 05:56:10 +0000
Subject: [pypy-issue] [issue1148] numpypy: int64 is unhashable
In-Reply-To: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>
Message-ID: <1338443770.75.0.430813769078.issue1148@bugs.pypy.org>


mikefc <coolbutuseless at gmail.com> added the comment:

Well, int64 is unhashable on OSX64 latest nightly.

I think dmitrey is on a 32bit machine and this issue with int32 being unhashable, 
so maybe this is a problem where the numpypy datatype matches the native type?

=========================================
>>>> from numpypy import int64
>>>> {int64(2):4}
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: unsupported operand type for hash: 'int64'

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1148>
________________________________________

From tracker at bugs.pypy.org  Thu May 31 08:09:00 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 31 May 2012 06:09:00 +0000
Subject: [pypy-issue] [issue1148] numpypy: int64 is unhashable
In-Reply-To: <1337694264.89.0.117224593429.issue1148@bugs.pypy.org>
Message-ID: <1338444540.12.0.703480507266.issue1148@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

my results with latest build (32 bit Intel Atom):

>>>> from numpypy import *
>>>> {int16(1):2}
{1: 2}
>>>> {int8(1):2}
{1: 2}
>>>> {int32(1):2}
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: unsupported operand type for hash: 'int32'
>>>> {int64(1):2}
{1: 2}
>>>> {float32(1):2}
{1.0: 2}
>>>> {float64(1):2}
Traceback (most recent call last):
  File "<console>", line 1, in <module>
TypeError: unsupported operand type for hash: 'float64'

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1148>
________________________________________

From tracker at bugs.pypy.org  Thu May 31 09:24:05 2012
From: tracker at bugs.pypy.org (Dmitrey)
Date: Thu, 31 May 2012 07:24:05 +0000
Subject: [pypy-issue] [issue1153] numpypy: critical bug with array.size
In-Reply-To: <1338106175.95.0.776500262156.issue1153@bugs.pypy.org>
Message-ID: <1338449045.19.0.159857897786.issue1153@bugs.pypy.org>


Dmitrey <dmitrey15 at ukr.net> added the comment:

I still have x.size = 5 with latst nightly build

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1153>
________________________________________

From tracker at bugs.pypy.org  Thu May 31 17:17:52 2012
From: tracker at bugs.pypy.org (mattip)
Date: Thu, 31 May 2012 15:17:52 +0000
Subject: [pypy-issue] [issue1153] numpypy: critical bug with array.size
In-Reply-To: <1338106175.95.0.776500262156.issue1153@bugs.pypy.org>
Message-ID: <1338477472.39.0.53446315215.issue1153@bugs.pypy.org>


mattip <matti.picus at gmail.com> added the comment:

Fixed with changeset ffd032c196fb

----------
nosy: +mattip
status: chatting -> resolved

________________________________________
PyPy bug tracker <tracker at bugs.pypy.org>
<https://bugs.pypy.org/issue1153>
________________________________________