From stefanv at berkeley.edu Thu Jan 4 16:22:23 2018 From: stefanv at berkeley.edu (Stefan van der Walt) Date: Thu, 04 Jan 2018 13:22:23 -0800 Subject: [AstroPy] Position at BIDS (UC Berkeley) to work on NumPy Message-ID: <1515100943.2963817.1224591776.2E95028D@webmail.messagingengine.com> Hi everyone, The Berkeley Institute for Data Science (BIDS) is hiring scientific Python Developers to contribute to NumPy. You can read more about the new positions here: https://bids.berkeley.edu/news/bids-receives-sloan-foundation-grant-contribute-numpy-development If you enjoy collaborative work as well as the technical challenges posed by numerical computing, this is an excellent opportunity to play a fundamental role in the development of one of the most impactful libraries in the entire Python ecosystem. Best regards St?fan Job link: https://jobsprod.is.berkeley.edu/psc/jobsprod/EMPLOYEE/HRMS/c/HRS_HRAM.HRS_CE.GBL?Page=HRS_CE_JOB_DTL&Action=A&JobOpeningId=24142&SiteId=1&PostingSeq=1 From eric at depagne.org Mon Jan 8 07:21:28 2018 From: eric at depagne.org (=?ISO-8859-1?Q?=C9ric?= Depagne) Date: Mon, 08 Jan 2018 14:21:28 +0200 Subject: [AstroPy] Ap.modeling.fitting.SLSQPLSQFitter() argument fails. Message-ID: <14590519.FjzZTDofv9@notebook> Hi all. I have a problem with SLSQPLSQFitter that seems to be related to the astropy/scipy version I'm using, but I can't find out why it's failing, so any help will be appreciated. I have the following code: def _gaussian_fit(self, a, k): from astropy.modeling import fitting, models fitter = fitting.SLSQPLSQFitter() gaus = models.Gaussian1D(amplitude=1., mean=a, stddev=5.) try: gfit = fitter(gaus, y, self.hrs.data[y, 50 * (k + 1)] / self.hrs.data[y, 50 * (k + 1)].max(), verblevel=0) except IndexError: return def find_orders(self, op): vgf = np.vectorize(self._gaussian_fit) for i in range(op.shape[1]): tt = vgf(op[:, i], i) fit[:, i] = tt positions[:, :, 0], positions[:, :, 1], positions[:, :, 2] = vadd(fit) I have a virtual environnment where I'm using astropy v 2.0.1 and scipy v 0.19.1 and the code works as expected: it fits the data. I am also running this code on the default version installed on my Ubuntu box, which are : astropy v 1.3 and scipy v 0.18.1 and in this case, I have the following error message: /home/eric/stability/stability.py in find_orders(self, op) 349 positions = np.zeros((op.shape[0], op.shape[1], 3)) 350 for i in range(op.shape[1]): --> 351 tt = vgf(op[:, i], i) 352 fit[:, i] = tt /usr/lib/python3/dist-packages/numpy/lib/function_base.py in __call__(self, *args, **kwargs) 2574 vargs.extend([kwargs[_n] for _n in names]) 2575 -> 2576 return self._vectorize_call(func=func, args=vargs) 2577 2578 def _get_ufunc_and_otypes(self, func, args): /usr/lib/python3/dist-packages/numpy/lib/function_base.py in _vectorize_call(self, func, args) 2644 res = func() 2645 else: -> 2646 ufunc, otypes = self._get_ufunc_and_otypes(func=func, args=args) 2647 2648 # Convert args to object arrays first /usr/lib/python3/dist-packages/numpy/lib/function_base.py in _get_ufunc_and_otypes(self, func, args) 2604 2605 inputs = [arg.flat[0] for arg in args] -> 2606 outputs = func(*inputs) 2607 2608 # Performance note: profiling indicates that -- for simple /home/eric/stability/stability.py in _gaussian_fit(self, a, k) 325 y = np.arange(y1, y2) 326 try: --> 327 gfit = fitter(gaus, y, self.hrs.data[y, 50 * (k + 1)] / self.hrs.data[y, 50 * (k + 1)].max(), verblevel=0) 328 except IndexError: 329 return /usr/lib/python3/dist-packages/astropy/modeling/fitting.py in __call__(self, model, x, y, z, weights, **kwargs) 682 p0, _ = _model_to_fit_params(model_copy) 683 fitparams, self.fit_info = self._opt_method( --> 684 self.objective_function, p0, farg, **kwargs) 685 _fitter_to_model_params(model_copy, fitparams) 686 /usr/lib/python3/dist-packages/astropy/modeling/optimizers.py in __call__(self, objfunc, initval, fargs, **kwargs) 160 objfunc, initval, args=fargs, full_output=True, 161 bounds=bounds, eqcons=eqcons, ieqcons=ineqcons, --> 162 **kwargs) 163 164 self.fit_info['final_func_val'] = final_func_val TypeError: fmin_slsqp() got an unexpected keyword argument 'verblevel' I have had a look on the astropy and scipy github to check whether the verblevel keyword had been added in between the versions (1.3 and 2.0) and/or (0.18.1 and 0.19.1), but it's not the case. I know that 1.3 and 0.18 are old and not stable version anymore, so I can simply do a version check and have my code exit if they are too old, but I'd be interested in understanding where I am doing something wrong. Thanks. ?ric. -- Un clavier azerty en vaut deux ---------------------------------------------------------- ?ric Depagne -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at depagne.org Mon Jan 8 10:57:28 2018 From: eric at depagne.org (=?ISO-8859-1?Q?=C9ric?= Depagne) Date: Mon, 08 Jan 2018 17:57:28 +0200 Subject: [AstroPy] Ap.modeling.fitting.SLSQPLSQFitter() argument fails. In-Reply-To: <5a56f3be20d14039b13078ef6f93daeb@stsci.edu> References: <14590519.FjzZTDofv9@notebook> <5a56f3be20d14039b13078ef6f93daeb@stsci.edu> Message-ID: <1571436.amhFMTk3kR@notebook> Le lundi 8 janvier 2018, 15:54:20 SAST Nadia Dencheva a ?crit : Hi Nadia, Thanks a lot for the explanation. I tried to find if that might have been a case like this, but could not. Cheers, ?ric > Hi Eric, > > > This was a bug in modeling - it didn't pass some of the keywords correctly > to scipy's fmin_slsqp. > > > It has been fixed since astropy 1.3.1 > > > https://github.com/astropy/astropy/pull/5815 > > > Cheers, > Nadia > > > ________________________________ > From: AstroPy on behalf of > ?ric Depagne Sent: Monday, January 8, 2018 7:21 AM > To: astropy at python.org > Subject: [AstroPy] Ap.modeling.fitting.SLSQPLSQFitter() argument fails. > > > Hi all. > > > > I have a problem with SLSQPLSQFitter that seems to be related to the > astropy/scipy version I'm using, but I can't find out why it's failing, so > any help will be appreciated. > > > > I have the following code: > > > > def _gaussian_fit(self, a, k): > > from astropy.modeling import fitting, models > > fitter = fitting.SLSQPLSQFitter() > > gaus = models.Gaussian1D(amplitude=1., mean=a, stddev=5.) > > try: > > gfit = fitter(gaus, y, self.hrs.data[y, 50 * (k + 1)] / self.hrs.data[y, 50 > * (k + 1)].max(), verblevel=0) > > except IndexError: > > return > > > > def find_orders(self, op): > > vgf = np.vectorize(self._gaussian_fit) > > for i in range(op.shape[1]): > > tt = vgf(op[:, i], i) > > fit[:, i] = tt > > positions[:, :, 0], positions[:, :, 1], positions[:, :, 2] = vadd(fit) > > I have a virtual environnment where I'm using astropy v 2.0.1 and scipy v > 0.19.1 and the code works as expected: it fits the data. > > > > I am also running this code on the default version installed on my Ubuntu > box, which are : astropy v 1.3 and scipy v 0.18.1 and in this case, I have > the following error message: > > > > /home/eric/stability/stability.py in find_orders(self, op) > > 349 positions = np.zeros((op.shape[0], op.shape[1], 3)) > > 350 for i in range(op.shape[1]): > > --> 351 tt = vgf(op[:, i], i) > > 352 fit[:, i] = tt > > > > /usr/lib/python3/dist-packages/numpy/lib/function_base.py in __call__(self, > *args, **kwargs) > > 2574 vargs.extend([kwargs[_n] for _n in names]) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dencheva at stsci.edu Mon Jan 8 10:54:20 2018 From: dencheva at stsci.edu (Nadia Dencheva) Date: Mon, 8 Jan 2018 15:54:20 +0000 Subject: [AstroPy] Ap.modeling.fitting.SLSQPLSQFitter() argument fails. In-Reply-To: <14590519.FjzZTDofv9@notebook> References: <14590519.FjzZTDofv9@notebook> Message-ID: <5a56f3be20d14039b13078ef6f93daeb@stsci.edu> Hi Eric, This was a bug in modeling - it didn't pass some of the keywords correctly to scipy's fmin_slsqp. It has been fixed since astropy 1.3.1 https://github.com/astropy/astropy/pull/5815 Cheers, Nadia ________________________________ From: AstroPy on behalf of ?ric Depagne Sent: Monday, January 8, 2018 7:21 AM To: astropy at python.org Subject: [AstroPy] Ap.modeling.fitting.SLSQPLSQFitter() argument fails. Hi all. I have a problem with SLSQPLSQFitter that seems to be related to the astropy/scipy version I'm using, but I can't find out why it's failing, so any help will be appreciated. I have the following code: def _gaussian_fit(self, a, k): from astropy.modeling import fitting, models fitter = fitting.SLSQPLSQFitter() gaus = models.Gaussian1D(amplitude=1., mean=a, stddev=5.) try: gfit = fitter(gaus, y, self.hrs.data[y, 50 * (k + 1)] / self.hrs.data[y, 50 * (k + 1)].max(), verblevel=0) except IndexError: return def find_orders(self, op): vgf = np.vectorize(self._gaussian_fit) for i in range(op.shape[1]): tt = vgf(op[:, i], i) fit[:, i] = tt positions[:, :, 0], positions[:, :, 1], positions[:, :, 2] = vadd(fit) I have a virtual environnment where I'm using astropy v 2.0.1 and scipy v 0.19.1 and the code works as expected: it fits the data. I am also running this code on the default version installed on my Ubuntu box, which are : astropy v 1.3 and scipy v 0.18.1 and in this case, I have the following error message: /home/eric/stability/stability.py in find_orders(self, op) 349 positions = np.zeros((op.shape[0], op.shape[1], 3)) 350 for i in range(op.shape[1]): --> 351 tt = vgf(op[:, i], i) 352 fit[:, i] = tt /usr/lib/python3/dist-packages/numpy/lib/function_base.py in __call__(self, *args, **kwargs) 2574 vargs.extend([kwargs[_n] for _n in names]) 2575 -> 2576 return self._vectorize_call(func=func, args=vargs) 2577 2578 def _get_ufunc_and_otypes(self, func, args): /usr/lib/python3/dist-packages/numpy/lib/function_base.py in _vectorize_call(self, func, args) 2644 res = func() 2645 else: -> 2646 ufunc, otypes = self._get_ufunc_and_otypes(func=func, args=args) 2647 2648 # Convert args to object arrays first /usr/lib/python3/dist-packages/numpy/lib/function_base.py in _get_ufunc_and_otypes(self, func, args) 2604 2605 inputs = [arg.flat[0] for arg in args] -> 2606 outputs = func(*inputs) 2607 2608 # Performance note: profiling indicates that -- for simple /home/eric/stability/stability.py in _gaussian_fit(self, a, k) 325 y = np.arange(y1, y2) 326 try: --> 327 gfit = fitter(gaus, y, self.hrs.data[y, 50 * (k + 1)] / self.hrs.data[y, 50 * (k + 1)].max(), verblevel=0) 328 except IndexError: 329 return /usr/lib/python3/dist-packages/astropy/modeling/fitting.py in __call__(self, model, x, y, z, weights, **kwargs) 682 p0, _ = _model_to_fit_params(model_copy) 683 fitparams, self.fit_info = self._opt_method( --> 684 self.objective_function, p0, farg, **kwargs) 685 _fitter_to_model_params(model_copy, fitparams) 686 /usr/lib/python3/dist-packages/astropy/modeling/optimizers.py in __call__(self, objfunc, initval, fargs, **kwargs) 160 objfunc, initval, args=fargs, full_output=True, 161 bounds=bounds, eqcons=eqcons, ieqcons=ineqcons, --> 162 **kwargs) 163 164 self.fit_info['final_func_val'] = final_func_val TypeError: fmin_slsqp() got an unexpected keyword argument 'verblevel' I have had a look on the astropy and scipy github to check whether the verblevel keyword had been added in between the versions (1.3 and 2.0) and/or (0.18.1 and 0.19.1), but it's not the case. I know that 1.3 and 0.18 are old and not stable version anymore, so I can simply do a version check and have my code exit if they are too old, but I'd be interested in understanding where I am doing something wrong. Thanks. ?ric. -- Un clavier azerty en vaut deux ---------------------------------------------------------- ?ric Depagne -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnfarias at uc.cl Thu Jan 11 17:39:41 2018 From: dnfarias at uc.cl (Diego Farias) Date: Thu, 11 Jan 2018 19:39:41 -0300 Subject: [AstroPy] astropy.io Message-ID: Hi Pythoners, I have posted this as an issue on github also, but I think it could be forgotten because it is a reply to another open issue. While using astropy.io on images with several HIERARCH cards (e.g., HIERARCH ESO INS RETA2 ROT = 0.0), which are Not-STANDARD FITS format, I encounter with a possible bug: if I do for example hdulist = fits.open(IMAGE,mode='update') hdulist[0].header.set('DISPAXIS', '1') hdulist.close(output_verify = 'ignore') It should prevent to print any warning message, but instead I get warning and ALSO fixes: WARNING: VerifyWarning: Verification reported errors: [astropy.io.fits.verify] WARNING: VerifyWarning: Card 'ESO INS IMAGE DISTOR1' is not FITS standard (invalid value string: '7.771690e-06 / distortion coefficient'). Fixed 'ESO INS IMAGE DISTOR1' card to meet the FITS standard. [astropy.io.fits.verify] WARNING: VerifyWarning: Note: astropy.io.fits uses zero-based indexing. [astropy.io.fits.verify] .... etc. The same strange behavior happened to someone else, so I think it could be a bug. I'm trying to trace where this happens, and the 'ignore' option it is used correctly once to verify in hdulist.py (astropy/io/fits/hdu) at def flush (self, output_verify='fix', verbose=False): self.verify(option=output_verify) ( def close uses flush so ..) and this is good, it does not print a thing. The bug appears in the last line of the same method . . . elif self._file.mode == 'update': self._flush_update() in self._flush_update(). If I search in this method, I could trace the 'bug' to def _flush_update(self): """Implements flushing changes to a file in update mode.""" for hdu in self: hdu._prewriteto(checksum=hdu._output_checksum, inplace=True) the hdu._prewriteto line. In this method, the warning appears after the return def _prewriteto(self, checksum=False, inplace=False): if self._scale_back: self._scale_internal(BITPIX2DTYPE[self._orig_bitpix], blank=self._orig_blank) self.update_header() if not inplace and self._data_needs_rescale: # Go ahead and load the scaled image data and update the header # with the correct post-rescaling headers _ = self.data return super(_ImageBaseHDU, self)._prewriteto(checksum, inplace) but my python knowledge is too short to fix this by myself (yet). So if you have any idea please share. Sorry for the long message and thanks in advance, Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From pweilbacher at aip.de Fri Jan 12 04:21:40 2018 From: pweilbacher at aip.de (Peter Weilbacher) Date: Fri, 12 Jan 2018 10:21:40 +0100 (CET) Subject: [AstroPy] astropy.io In-Reply-To: References: Message-ID: Hi Diego, On Thu, 11 Jan 2018, Diego Farias wrote: > I have posted this as an issue on github also, but I think it could be > forgotten because it is a reply to another open issue. You might have better success to get someone to look at this, if you also posted the FITS file in question. And also mentioning the issue ID (which seems to be https://github.com/astropy/astropy/issues/7043). > While using astropy.io on images with several HIERARCH cards (e.g., > HIERARCH ESO INS RETA2 ROT = 0.0), which are Not-STANDARD FITS format, I > encounter with a possible bug: if I do for example > > hdulist = fits.open(IMAGE,mode='update') > hdulist[0].header.set('DISPAXIS', '1') > hdulist.close(output_verify = 'ignore') > > It should prevent to print any warning message, but instead I get warning > and ALSO fixes: > > WARNING: VerifyWarning: Verification reported errors: > [astropy.io.fits.verify] > WARNING: VerifyWarning: Card 'ESO INS IMAGE DISTOR1' is not FITS standard > (invalid value string: '7.771690e-06 / distortion coefficient'). Fixed > 'ESO INS IMAGE DISTOR1' card to meet the FITS standard. > [astropy.io.fits.verify] > WARNING: VerifyWarning: Note: astropy.io.fits uses zero-based indexing. > [astropy.io.fits.verify] I don't know any of the internals, but it seems to me that it is not complaining about the ESO-style keyword naming but about the value of the keyword, probably the lower-case 'e' of the floating-point exponent. Maybe something to take up with ESO, if their software has written this file. Peter. -- Dr. Peter M. Weilbacher http://www.aip.de/People/PWeilbacher Phone +49 331 74 99-667 encryption key ID 7D6B4AA0 ------------------------------------------------------------------------ Leibniz-Institut f?r Astrophysik Potsdam (AIP) An der Sternwarte 16, D-14482 Potsdam Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker Stiftung b?rgerlichen Rechts, Stiftungsverz. Brandenburg: 26 742-00/7026 From d.f.evans at keele.ac.uk Fri Jan 12 05:14:36 2018 From: d.f.evans at keele.ac.uk (Daniel Evans) Date: Fri, 12 Jan 2018 10:14:36 +0000 Subject: [AstroPy] astropy.io In-Reply-To: References: Message-ID: Diego, It turns out a useful trick here is to get Python to point out a traceback for the warnings, to show where they originate from - I've only just learnt this myself, trying to follow your problem. See https://stackoverflow.com/questions/22373927/get-traceback-of-warnings for instructions on how to do this. I can indeed reproduce your issue - i.e. that verification is performed despite explicitly setting verify='ignore'. Having got the traceback out, the issue originates when the checksum of the HDUList is calculated. This involves converting each card in the header to a string, and when such an action is performed on a card, the card will self-verify if this has not already been done - line 506 of astropy/io/fits/card.py: if self._image and not self._verified: self.verify('fix+warn') I've added this info to the relevant github issue ( https://github.com/astropy/astropy/issues/7043), though I'll have to leave it up to others to work out the solution. Regards, Daniel On 11 January 2018 at 22:39, Diego Farias wrote: > Hi Pythoners, > > I have posted this as an issue on github also, but I think it could be > forgotten because it is a reply to another open issue. > > While using astropy.io on images with several HIERARCH cards (e.g., > HIERARCH ESO INS RETA2 ROT = 0.0), which are Not-STANDARD FITS format, I > encounter with a possible bug: if I do for example > > hdulist = fits.open(IMAGE,mode='update') > hdulist[0].header.set('DISPAXIS', '1') > hdulist.close(output_verify = 'ignore') > > It should prevent to print any warning message, but instead I get warning > and ALSO fixes: > > WARNING: VerifyWarning: Verification reported errors: > [astropy.io.fits.verify] > WARNING: VerifyWarning: Card 'ESO INS IMAGE DISTOR1' is not FITS standard > (invalid value string: '7.771690e-06 / distortion coefficient'). Fixed > 'ESO INS IMAGE DISTOR1' card to meet the FITS standard. > [astropy.io.fits.verify] > WARNING: VerifyWarning: Note: astropy.io.fits uses zero-based indexing. > [astropy.io.fits.verify] > .... > > etc. The same strange behavior happened to someone else, so I think it > could be a bug. I'm trying to trace where this happens, and the 'ignore' > option it is used correctly once to verify in hdulist.py > (astropy/io/fits/hdu) at > > def flush (self, output_verify='fix', verbose=False): > self.verify(option=output_verify) > > ( def close uses flush so ..) and this is good, it does not print a thing. > The bug appears in the last line of the same method > . > . > . > elif self._file.mode == 'update': > self._flush_update() > > in self._flush_update(). If I search in this method, I could trace the > 'bug' to > > def _flush_update(self): > """Implements flushing changes to a file in update mode.""" > > for hdu in self: > hdu._prewriteto(checksum=hdu._output_checksum, inplace=True) > > > the hdu._prewriteto line. In this method, the warning appears after the > return > > def _prewriteto(self, checksum=False, inplace=False): > if self._scale_back: > self._scale_internal(BITPIX2DTYPE[self._orig_bitpix], > blank=self._orig_blank) > self.update_header() > if not inplace and self._data_needs_rescale: > # Go ahead and load the scaled image data and update the header > # with the correct post-rescaling headers > _ = self.data > > return super(_ImageBaseHDU, self)._prewriteto(checksum, inplace) > > but my python knowledge is too short to fix this by myself (yet). So if > you have any idea please share. > > Sorry for the long message and thanks in advance, > > Diego > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From indrajit at iiap.res.in Fri Jan 12 05:33:53 2018 From: indrajit at iiap.res.in (Indrajit Vittal Barve) Date: Fri, 12 Jan 2018 16:03:53 +0530 Subject: [AstroPy] bintable with two different length entries. Message-ID: <6623de4fc8503fd70da2307886dc64b5@iiap.res.in> Hello astropy list, I am new to the "from astropy.io import fits". I do have a dynamic spectrum of 2D array data x-axis - time and y-axis freq. 2000 X 401 array size, Where if I use the following lines col1=fits.Column(name='TIME',format='E',array=tt) col2=fits.Column(name='FREQ',format='E',array=freq) cols = fits.ColDefs([col1, col2]) its generate the 2000 X 2 columns. On the second column filled with zeros after 401. I need to generate a bintable with two axis values. Thanks Indrajit From thomas.robitaille at gmail.com Sun Jan 28 05:16:25 2018 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Sun, 28 Jan 2018 10:16:25 +0000 Subject: [AstroPy] Revert to astropy 1.3 constants (for testing) in astropy 2.0 In-Reply-To: References: <0C479C10-D032-48E9-AE65-16DD361F1316@astro.physik.uni-goettingen.de> Message-ID: Hi Duncan, Just to close the loop on this (and in case anyone finds this thread), this will be much simpler in the upcoming 3.0 release, as there will be a context manager to do this: http://docs.astropy.org/en/latest/api/astropy.constants.set_enabled_constants.html#astropy.constants.set_enabled_constants Cheers, Tom On 10 July 2017 at 15:01, Duncan Macleod wrote: > Hi Derek, > > Unfortunately, I don't want to change the imports in my module, but only in > the test suite. Essentially I want to mock the constants module back to > astropy-1.3 values. > > In the end I ended up with the following in my test module: > > from astropy import __version__ as astropy_version > if astropy_version >= '2.0': > from astropy import constants > from astropy.constants import (si, astropyconst13) > units.M_sun._represents = units.Unit(astropyconst13.M_sun) > constants.M_sun = si.M_sun = astropyconst13.M_sun > constants.G = si.G = astropyconst13.G > constants.c = si.c = astropyconst13.c > constants.pc = si.pc = astropyconst13.pc > > to just fix the constants I need without editing the module code that > actually uses them. This is after the module import, but before any function > calls. A bit messy, but does the job. > > > D > > On 10 July 2017 at 14:56, Derek Homeier > wrote: >> >> On 10 Jul 2017, at 2:34 pm, Duncan Macleod >> wrote: >> > >> > Is there a way to tell astropy.constants to use the version 1.3 >> > constants (from astropy.constants.astropyconst13) when using the v2.0 >> > package? i.e. have astropy.constants.M_sun come from iau2012 and not >> > iau2015? >> > >> > I have a bunch of unit tests are now failing because of the relatively >> > large changes in some constants.* >> > >> Depends on how you currently import them, but replacing e.g. >> >> from astropy import constants as const >> >> with >> >> from astropy.constants import astropyconst13 as const >> >> should have the desired effect. >> >> HTH >> Derek >> >> _______________________________________________ >> AstroPy mailing list >> AstroPy at python.org >> https://mail.python.org/mailman/listinfo/astropy > > > > > -- > Duncan Macleod > duncan.macleod at ligo.org > S?r Cymru Cofund Fellow > School of Physics and Astronomy > Cardiff University > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy > From tthieme at gapp.nthu.edu.tw Wed Jan 31 23:25:01 2018 From: tthieme at gapp.nthu.edu.tw (Travis Thieme) Date: Thu, 1 Feb 2018 13:25:01 +0900 Subject: [AstroPy] Can't import astropy subpackages Message-ID: Hello everyone, I?m not really a new astropy user, but for some reason I have this problem with astropy after I installed via conda. I tried uninstalling and installing again, but no luck. Below are the steps I took to get this error. 1) open ipython in terminal 2) import astropy 3) print (astropy.constants.c) I get the following error: module ?astropy? has no attribute ?constants? Which is very odd because it?s always worked for me before in my previous installations. When I type astropy. in ipython, it only lists the following options when hitting tab: conf, config, cython_version, extern, find_api_page(), log, logger, online_docs_root, online_help(), test(), tests, utils, version. And what?s more odd, is when I type: from astropy.constants import c It works just fine? I?m running Python 3.6.4, ipython 6.2.1, conda 4.4.8, and astropy 2.0.3 on macOS High Sierra. Any insight why this is happening? Thank you all. Best Regards, Travis Thieme Graduate Student Institute of Astronomy National Tsing Hua University -------------- next part -------------- An HTML attachment was scrubbed... URL: From evert.rol at gmail.com Wed Jan 31 23:40:37 2018 From: evert.rol at gmail.com (Evert Rol) Date: Thu, 1 Feb 2018 15:40:37 +1100 Subject: [AstroPy] Can't import astropy subpackages In-Reply-To: References: Message-ID: <0F7380C2-AE35-487E-A73D-5697F25BBD7E@gmail.com> Travis, you probably just need an extra import astropy.constants line. Looks like the constants subpackage isn't automatically imported (anymore) when astropy is imported. I think this is largely the default for most Python packages (os.path an exception to the rule): subpackages don't get imported automatically. > Hello everyone, > > I?m not really a new astropy user, but for some reason I have this problem with astropy after I installed via conda. I tried uninstalling and installing again, but no luck. Below are the steps I took to get this error. > > 1) open ipython in terminal > 2) import astropy > 3) print (astropy.constants.c) > > I get the following error: module ?astropy? has no attribute ?constants? > > Which is very odd because it?s always worked for me before in my previous installations. > > When I type astropy. in ipython, it only lists the following options when hitting tab: conf, config, cython_version, extern, find_api_page(), log, logger, online_docs_root, online_help(), test(), tests, utils, version. > > And what?s more odd, is when I type: > from astropy.constants import c > > It works just fine? I?m running Python 3.6.4, ipython 6.2.1, conda 4.4.8, and astropy 2.0.3 on macOS High Sierra. Any insight why this is happening? Thank you all. > > Best Regards, > > Travis Thieme > Graduate Student > Institute of Astronomy > National Tsing Hua University > > _______________________________________________ > AstroPy mailing list > AstroPy at python.org > https://mail.python.org/mailman/listinfo/astropy