Coordinates test failures in 1.2rc1 on Ubuntu 14.04 and py3.4

[bsipocz]

There are 24 of these failures, full log (including fails due to #5076) is in this gist: https://gist.github.com/bsipocz/f42af5e837a7f270e0a27a1003dda427

platform linux -- Python 3.4.3, pytest-2.8.3, py-1.4.30, pluggy-0.3.1

Running tests with Astropy version 1.2rc1.
Running tests in /home/gkovacs/.local/lib/python3.4/site-packages/astropy.

Date: 2016-06-12T15:28:54

Platform: Linux-3.16.0-71-generic-x86_64-with-Ubuntu-14.04-trusty

Executable: /usr/bin/python3

Full Python Version: 
3.4.3 (default, Oct 14 2015, 20:28:29) 
[GCC 4.8.4]

encodings: sys: utf-8, locale: UTF-8, filesystem: utf-8
byteorder: little
float info: dig: 15, mant_dig: 15

Numpy: 1.11.0
Scipy: 0.16.1
Matplotlib: 1.5.0
h5py: not available
Pandas: 0.18.0                                                                                                                                                                                                                              
Using Astropy options: remote_data

================================================================================================================= FAILURES =================================================================================================================
__________________________________________________________________________________________________________ test_spherical_offsets __________________________________________________________________________________________________________

    def test_spherical_offsets():
        i00 = SkyCoord(0*u.arcmin, 0*u.arcmin, frame='icrs')
        i01 = SkyCoord(0*u.arcmin, 1*u.arcmin, frame='icrs')
        i10 = SkyCoord(1*u.arcmin, 0*u.arcmin, frame='icrs')
        i11 = SkyCoord(1*u.arcmin, 1*u.arcmin, frame='icrs')
        i22 = SkyCoord(2*u.arcmin, 2*u.arcmin, frame='icrs')

>       dra, ddec = i00.spherical_offsets_to(i01)

/home/gkovacs/.local/lib/python3.4/site-packages/astropy/coordinates/tests/test_sky_coord.py:1193: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/home/gkovacs/.local/lib/python3.4/site-packages/astropy/coordinates/sky_coordinate.py:746: in spherical_offsets_to
    aframe = self.skyoffset_frame()
/home/gkovacs/.local/lib/python3.4/site-packages/astropy/coordinates/sky_coordinate.py:1056: in skyoffset_frame
    return SkyOffsetFrame(origin=self, rotation=rotation)
/home/gkovacs/.local/lib/python3.4/site-packages/astropy/coordinates/builtin_frames/skyoffset.py:199: in __new__
    newcls = make_skyoffset_cls(origin_frame.__class__)
/home/gkovacs/.local/lib/python3.4/site-packages/astropy/coordinates/builtin_frames/skyoffset.py:110: in make_skyoffset_cls
    {'__doc__': SkyOffsetFrame.__doc__})
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

cls = <class 'astropy.coordinates.builtin_frames.skyoffset.make_skyoffset_cls.<locals>.SkyOffsetMeta'>, name = 'SkyOffsetFrame'
bases = (<class 'astropy.coordinates.builtin_frames.skyoffset.SkyOffsetFrame'>, <class 'astropy.coordinates.builtin_frames.icrs.ICRS'>)
members = {'__doc__': '\n    A frame which is relative to some specific position and oriented to match\n    its frame.\n\n    Sk...at', framename='dec', defaultunit='recommended')]}, 'default_representation': <property object at 0x7f02cd6f0958>, ...}

    def __new__(cls, name, bases, members):
        # Only 'origin' is needed here, to set the origin frame properly.
        members['origin'] = CoordinateAttribute(frame=framecls, default=None)

        # This has to be done because FrameMeta will set these attributes
        # to the defaults from BaseCoordinateFrame when it creates the base
        # SkyOffsetFrame class initially.
        members['_frame_specific_representation_info'] = framecls._frame_specific_representation_info
        members['_default_representation'] = framecls._default_representation

        newname = name[:-5] if name.endswith('Frame') else name
        newname += framecls.__name__

        res = super(SkyOffsetMeta, cls).__new__(cls, newname, bases, members)

        # now go through all the component names and make any spherical names be "lon" and "lat"
        # instead of e.g. "ra" and "dec"

        lists_done = []
        for nm, component_list in res._frame_specific_representation_info.items():
            if nm in ('spherical', 'unitspherical'):
                gotlatlon = []
                for i, comp in enumerate(component_list):
                    if component_list in lists_done:
                        # we need this because sometimes the component_
                        # list's are the exact *same* object for both
                        # spherical and unitspherical.  So looping then makes
                        # the change *twice*.  This hack bypasses that.
                        continue

                    if comp.reprname in ('lon', 'lat'):
                        dct = namedtuple_asdict(comp)
                        # this forces the component names to be 'lat' and
                        # 'lon' regardless of what the actual base frame
                        # might use
                        dct['framename'] = comp.reprname
>                       component_list[i] = type(comp)(**dct)
E                       TypeError: __new__() missing 1 required positional argument: 'reprname'

/home/gkovacs/.local/lib/python3.4/site-packages/astropy/coordinates/builtin_frames/skyoffset.py:95: TypeError

[astrofrog]

This is the same as what @matthew-brett reported on the mailing list. Intriguing!

[bsipocz]

Indeed! I wonder why our CI failed to notice this.

[astrofrog]

@bsipocz - is this a Python 3.4 and not 3.5 problem? Are you using conda?

[bsipocz]

I don't have a working py3.5 on this box (as I'm actually hijacking Gabor's desktop, and trying not to mess up his reference environments).
I'll run the tests from a py3.5 conda from RHEL.

[matthew-brett]

Py 3.4 and not Py 2.7 or 3.5 for me:

https://travis-ci.org/MacPython/astropy-wheels/builds/136980569

[astrofrog]

Just to add a datapoint, I don't see the error on MacOS X with:

Full Python Version: 
3.4.4 |Continuum Analytics, Inc.| (default, Jan  9 2016, 17:30:09) 
[GCC 4.2.1 (Apple Inc. build 5577)]

encodings: sys: utf-8, locale: UTF-8, filesystem: utf-8
byteorder: little
float info: dig: 15, mant_dig: 15

Numpy: 1.11.0
Scipy: 0.17.1
Matplotlib: 1.5.1
h5py: not available
Pandas: not available

[bsipocz]

Probably it's not sensitive to it but my failing setup uses the system default python and not a conda one.

[astrofrog]

I think I found it - it's an issue with 3.4.3 but not 3.4.4, so maybe a Python bug that was fixed? (i.e. I can reproduce it on my mac laptop with conda if I explicitly ask for 3.4.3). The question is, should we then add a workaround since 3.4.3 seems to be the default in a number of places?

[bsipocz]

Ohh, that would make sense. @matthew-brett's version was also 3.4.3

[eteq]

Ohh, this is a sneaky one: turns out namedtuple._asdict has a bug in python vs 3.4.x (except 3.4.4) that makes it not work right with subclasses like RepresentationMapping. There's already a work around because there's a different bug in 3.3.x, so I'll just update the workaround to include the 3.4.x's with the problem. PR coming shortly.

(Also, I labeled this affects-dev, because it's part of the offset frames)