On Fri, Jun 19, 2015 at 4:15 PM, Chris Barker wrote:
> On Wed, Jun 17, 2015 at 11:13 PM, Nathaniel Smith wrote:
>
>> there's some
>> argument that in Python, doing explicit type checks like this is
>> usually a sign that one is doing something awkward,
>
>
> I tend to agree with that.
>
> On th
On Wed, Jun 17, 2015 at 11:13 PM, Nathaniel Smith wrote:
> there's some
> argument that in Python, doing explicit type checks like this is
> usually a sign that one is doing something awkward,
I tend to agree with that.
On the other hand, numpy itself is kind-of sort-of statically typed. But
Nathaniel Smith wrote:
> In py3,
> 'int' is an arbitrary width integer bignum, like py2 'long', which is
> fundamentally different from int32 and int64 in both semantics and
> implementation.
Only when stored in an ndarray.
An array scalar object does not need to care about the exact number of
In some cases calling operator.index(n) may yield the desired result. I
like operator.index, but maybe it is just me :). That uses duck typing
instead of instance checking to ask if it represents an integer.
But it also has some awkward corner cases in numpy, since arrays with a
single element (dep
On Wed, Jun 17, 2015 at 10:53 PM, Jens Jørgen Mortensen
wrote:
> >>> type(n)
>
> >>> isinstance(n, int)
> True
>
> With Python 3.4 you get False. I think I understand why (np.int64 is no
> longer a subclass of int).
Yep, that's correct.
> So, I did this instead:
>
> import numbers
> isinstan
Hi!
I just finished porting a large code-base to Python 3 (making it work on
2.6, 2.7 and 3.4). It wasn't that difficult, but one thing gave me a
hard time and it was this:
Python 2.7.9 (default, Apr 2 2015, 15:33:21)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for
