From mdroe at stsci.edu Mon Aug 1 11:52:33 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Mon, 1 Aug 2011 11:52:33 -0400 Subject: [AstroPy] Coding Guidelines draft (comments encouraged) In-Reply-To: <4E2DD5E0.5070404@stsci.edu> References: <4E245896.3020601@stsci.edu> <4E29D2E0.6030708@gemini.edu> <4E2DD5E0.5070404@stsci.edu> Message-ID: <4E36CBC1.6010206@stsci.edu> On 07/25/2011 04:45 PM, Erik Bray wrote: > On 07/25/2011 08:09 AM, Erik Tollerud wrote: >> I have made a new version of the coding guidelines and posted them to: >> http://astropy.org/development/codeguide.html >> >> This version incorporates most of the feedback we've gotten so far on >> this thread, so if you've suggested something, you might want to look >> to make sure what's in there is what you had in mind. In particular, >> Michael, you may want to look at the new phrasing for the data file >> limit. The rephrasing addresses my concerns. Thank you. Mike -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA From sienkiew at stsci.edu Mon Aug 1 14:03:27 2011 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Mon, 01 Aug 2011 14:03:27 -0400 Subject: [AstroPy] Testing Guidelines In-Reply-To: References: <00945222-7EE6-421B-AB46-A534A4E4A733@astro.physik.uni-goettingen.de> Message-ID: <4E36EA6F.3000103@stsci.edu> Erik Tollerud wrote: > In principle, the similarities between nose and py.test mean we > wouldn't really have to make a decision until we need features that > differ between them- developers could run whichever they prefer... > If the decision goes that way, I can write up a document describing a common subset that covers most of what you need to do in routine testing. Then you make your standard "use the astrolib-defined nose/py.test subset whenever it is practical". Only a few unusual cases will need to deviate. > Except there's one problem: the configuration files are formatted > differently... We want to use configuration settings for just one of > the packages so that the suite always runs the same. What configuration file is that? I don't recall ever writing a configuration file for either nose or py.test. >> By the way, it looks like there's been a lot of work on unittest in >> python 2.7 (aka unittest2) so how does that compare to nose and >> py.test? >> > > The biggest change I see is that it seems to now include a test > discovery tool, but it is much less documented (a few paragraphs > rather than many pages each for the other two), and seems to lack most > of the nose and py.test runners' customization (like configuring in > the setup.cfg file, easy plugins, etc.). It's an improvement, but it's > still based around the more complex syntax of unittest, so most of > what I said above as far as I can tell is still true. > IMHO, the most interesting feature to me are the new comparison functions. I never really liked all the weird "fail unless not less than or equal" kind of functions, but the nice thing in unittest2 is that some of the comparison functions are able to display useful reports about what the nature of the failure. For example, I seem to remember a string compare that will split multi-line strings and display a diff-like result. It strikes me as poor modularization, though: there should be a separate library of comparison functions that can be used with any test framework, not a slightly different implementation in every test framework. I think you can write a test function for nose or py.test and still use a unittest2 comparison function; you just have to be a little tricky. It's the kind of thing you would hide in a library. Maybe we provide our own library of test helper functions. The biggest negative of unittest2 is that it is still unittest. When I first read about unittest, I thought "this is crazy complicated for running a simple test; I'm not going to use it". I have a better understanding of it now, but I still only ever use it when I have no other choice, and that basically means when I am working on code that somebody else already wrote using unittest. > Regardless, we couldn't use that anyway if we're planning to stay > 2.6-compatible. > If you really like the new unittest, you can install unittest2 in python 2.6. The drawback is that each test file has to detect the three possible cases: new unittest, unittest2, or old unittest. Mark S. From embray at stsci.edu Tue Aug 2 10:15:44 2011 From: embray at stsci.edu (Erik Bray) Date: Tue, 2 Aug 2011 10:15:44 -0400 Subject: [AstroPy] Coding Guidelines draft (comments encouraged) In-Reply-To: <4E2DD5E0.5070404@stsci.edu> References: <4E245896.3020601@stsci.edu> <4E29D2E0.6030708@gemini.edu> <4E2DD5E0.5070404@stsci.edu> Message-ID: <4E380690.1020501@stsci.edu> On 07/25/2011 04:45 PM, Erik Bray wrote: > On 07/25/2011 08:09 AM, Erik Tollerud wrote: >> I have made a new version of the coding guidelines and posted them to: >> http://astropy.org/development/codeguide.html >> >> This version incorporates most of the feedback we've gotten so far on >> this thread, so if you've suggested something, you might want to look >> to make sure what's in there is what you had in mind. In particular, >> Michael, you may want to look at the new phrasing for the data file >> limit. Additionally, a few of you may want to look over the new >> phrasing for when C extensions are acceptable. >> >> >> One thing I have *not* yet altered is the section on super() and >> multiple inheritance, as the discussion does not seem to have >> concluded. > > Allow me to add a little more fuel to the discussion then :) > > First, for some additional motivating background, here's a post by Guido > on the history of class method resolution orders (MROs) in Python, and > the rationale for the current solution: > http://python-history.blogspot.com/2010/06/method-resolution-order.html > > It's easier reading than any PEP on the topic, so I would consider it > worth reading for anyone who would like more background. > > The recommendation given in the current Coding Guidelines completely > breaks the intended MRO for __init__(). In this example A.__init__() is > called twice (as well as object.__init__(), though this does nothing)! > The effective MRO is D->B->A->object->C->A->object. You can see this > for yourself if you take the original example and add some print statements: > > >>> class A(object): > ... inits = 0 > ... def __init__(self): > ... self.inits += 1 > ... if self.inits> 1: > ... print 'Calling A.__init__() again!' > ... else: > ... print 'Calling A.__init__() for the first time.' > ... > >>> class B(A): > ... def __init__(self): > ... print 'Calling B.__init__().' > ... A.__init__(self) > ... > >>> class C(A): > ... def __init__(self): > ... print 'Calling C.__init__().' > ... A.__init__(self) > ... > >>> class D(C, B): > ... def __init__(self): > ... print 'Calling D.__init__().' > ... B.__init__(self) > ... C.__init__(self) > >>> D() > Calling D.__init__(). > Calling B.__init__(). > Calling A.__init__() for the first time. > Calling C.__init__(). > Calling A.__init__() again! > <__main__.D object at 0x2afb22dd7750> > > While this may be harmless in some cases, it's most likely not what the > developer really wants. And it's completely different from what Python > would otherwise do which is D->C->B->A->object. This is a much more > sensible MRO (and based on a well thought out algorithm that handles > numerous corner cases that you might not think of immediately). This is > also very difficult to do without cooperative super() calls. > > Having some classes *not* using super() will break any code that does > try to use them as part of a cooperative super() call. So the better > policy is to *require* the use of super(), especially in __init__() > which is the most common case--I can't emphasize this enough :). > > The problems with this, I think, are overstated: In the simplest and > most common case of single-inheritance using super(Foo, self).__init__() > is equivalent to Foo.__init__(self). In the case of inheriting from two > classes with no overlapping functionality--orthogonal bases as James put > it--again it's a moot point. > > super() *only* adds complexity and/or confusion in diamond-like or even > more complex class hierarchies. But in these cases super() will always > make sure that the "right" thing is done. What Python's algorithm > considers "right" may not always be exactly what the developer wants, > but in the case of multiple inheritance Python follows its Zen by having > One Right Way to do it. And for a complex and confusing subject like > multiple inheritance that's a good thing. > > Admittedly, the semantics for using super() in Python 2.x are > cumbersome. Python 3 at least allows calling super() with no arguments, > which is the same as super(__class__, self)--the most common way of > calling it. But that's just Python 3 :) I know people have been busy, myself included, but I wonder if anyone has had time to consider the use of super() and the defense thereof. I would change the coding guidelines read opposite of how they do currently: Use of super() should be encouraged except where one knows for sure that it's not going to be appropriate, due to the need for a customized method resolution order. What *should* be discouraged is the use of multiple inheritance except in the cases of orthogonal bases, or if one is really sure what they're doing. On an unrelated matter, I have one other suggestion for the coding guidelines: A top level package's __init__.py should be importable under all circumstances, and should not too much "stuff" in it, for lack of a better word. To explain: Several of our own packages have an __init__.py that contains a lot of functionality, such that when I try to import it, it might crash (due to some prerequisite not being met), take a very long time (due to it importing many submodules unnecessarily), or it might have actual side effects like writing to the filesystem. All of these behaviors should be discouraged. In particular it can cause problems for installation and test frameworks which use the Python import mechanism to discover packages and modules on the path. Merely importing the package should not fail due to, for example, an environment variable not being set. There are valid reasons for the __init__.py containing functionality, in particular for ease of use at the Python command line. But they should be designed so that they can at least be imported without side-effects. This would mean cleanly disabling certain functionality if any prerequisites are not bet, and delaying any side-effects until it's certain that they are necessary. Just to give a concrete example (that's long since been fixed, actually) matplotlib used to try to write out a default cache/config directory upon import, which could fail if the process it was running in didn't have permission to create that directory. That's the kind of thing that should be avoided. I think that a note to that effect should be added to the coding guidelines. I'd be happy to write up a draft if people agree with this. Thanks, Erik From thomas.robitaille at gmail.com Thu Aug 4 12:41:26 2011 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Thu, 4 Aug 2011 11:41:26 -0500 Subject: [AstroPy] AstroPy Coordination Meeting this fall In-Reply-To: References: Message-ID: Hi everyone, If you are interested in coming to the coordination meeting in the fall and haven't voted for a date yet, please indicate your preference by the end of this week so we can make a decision. By the way, if you can't make either date, you can select 'neither'. Thanks, Thomas On 26 July 2011 17:38, Thomas Robitaille wrote: > Hi everyone, > > Following the poll on a coordination meeting this fall, it looks like > the CfA is convenient for the most people, so Tom Aldcroft and myself > have been looking into when/how we could organize this. We are > envisaging a two-day AstroPy development coordination meeting for > AstroPy (not a general Python in Astronomy meeting, which could happen > as a AAS splinter for example). We've come up with a couple of dates > that would be best in terms of logistics, namely September 8-9th and > October 12-13th. > > Note that this would be more of an informal meeting than a conference > (no 'official' catering for example). We're planning on booking a > meeting room big enough for 30-40 people with a projector, tables, and > (of course) internet. We will also try and make sure that we can hold > meetings in smaller sub-groups for coordination relating to specific > components on one of the days. > > We've created a poll at the following URL where you can indicate your > name and preferences: > > http://www.doodle.com/7ea9i6frm95tekv9 > > If neither of the dates work, please indicate it so we can discuss this further! > > Thanks! > > Thomas > > ps: In case this is relevant to some of you, the AAS HEAD meeting is > 7-10th September in Rhode Island, which would conflict with the first > set of dates. > From thomas.robitaille at gmail.com Tue Aug 9 22:01:45 2011 From: thomas.robitaille at gmail.com (Thomas Robitaille) Date: Tue, 9 Aug 2011 22:01:45 -0400 Subject: [AstroPy] AstroPy Coordination Meeting this fall In-Reply-To: References: Message-ID: Hi everyone, It seems that the October dates work best for people, so this is just to confirm that we will hold the AstroPy coordination meeting on October 12-13th 2011 at the Harvard-Smithsonian Center for Astrophysics. In addition to finalizing decisions and coordinating the next development steps, we thought it might be fun to get going on some coding, so we are planning to have an optional coding sprint on the Friday (October 14th) for anyone interested in staying an extra day. We've created a preliminary page on the GitHub wiki and have included the list of people who said they would be able to make those dates: https://github.com/astropy/astropy/wiki/CfAMeeting2011 Feel free to add or remove your name as necessary (you will need a GitHub account) or send me an email if you want me to do it. A preliminary agenda and logistical information will follow. If you have ideas or suggestions for the agenda, please feel free to send me an email (or post a reply to this message). We look forward to having you over at CfA in the fall! Cheers, Thomas On 26 July 2011 18:38, Thomas Robitaille wrote: > Hi everyone, > > Following the poll on a coordination meeting this fall, it looks like > the CfA is convenient for the most people, so Tom Aldcroft and myself > have been looking into when/how we could organize this. We are > envisaging a two-day AstroPy development coordination meeting for > AstroPy (not a general Python in Astronomy meeting, which could happen > as a AAS splinter for example). We've come up with a couple of dates > that would be best in terms of logistics, namely September 8-9th and > October 12-13th. > > Note that this would be more of an informal meeting than a conference > (no 'official' catering for example). We're planning on booking a > meeting room big enough for 30-40 people with a projector, tables, and > (of course) internet. We will also try and make sure that we can hold > meetings in smaller sub-groups for coordination relating to specific > components on one of the days. > > We've created a poll at the following URL where you can indicate your > name and preferences: > > http://www.doodle.com/7ea9i6frm95tekv9 > > If neither of the dates work, please indicate it so we can discuss this further! > > Thanks! > > Thomas > > ps: In case this is relevant to some of you, the AAS HEAD meeting is > 7-10th September in Rhode Island, which would conflict with the first > set of dates. > From omar.vpa at gmail.com Wed Aug 10 03:44:44 2011 From: omar.vpa at gmail.com (=?ISO-8859-1?Q?Omar_Trinidad_Guti=E9rrez_M=E9ndez?=) Date: Wed, 10 Aug 2011 02:44:44 -0500 Subject: [AstroPy] Image Processing Message-ID: Hello friends: I am Omar Trinidad Guti?rrez M?ndez, I am working in Astronomical Image Processing... I am working with OpenCV. Greetings -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.tollerud at gmail.com Mon Aug 15 02:30:06 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Sun, 14 Aug 2011 23:30:06 -0700 Subject: [AstroPy] Coding Guidelines draft (comments encouraged) In-Reply-To: <4E380690.1020501@stsci.edu> References: <4E245896.3020601@stsci.edu> <4E29D2E0.6030708@gemini.edu> <4E2DD5E0.5070404@stsci.edu> <4E380690.1020501@stsci.edu> Message-ID: > I know people have been busy, myself included, but I wonder if anyone > has had time to consider the use of super() and the defense thereof. Based on the lack of further discussion on the top, it would seem not :) > I would change the coding guidelines read opposite of how they do > currently: Use of super() should be encouraged except where one knows > for sure that it's not going to be appropriate, due to the need for a > customized method resolution order. ?What *should* be discouraged is the > use of multiple inheritance except in the cases of orthogonal bases, or > if one is really sure what they're doing. You raise some very good points - my main concern was that it always be consistently super() or consistently not . I can see that use of super() would be a safer guideline given these use cases - does anyone object to this? If not (within a few days,hopefully), I will update the guidelines to suggest using super() unless there is a specific reason not to (and require that it be specifically mentioned if so), as well as discouraging multiple inheritance without a good reason (and replace the old example with an orthogonal base/mixin example that uses super()). > On an unrelated matter, I have one other suggestion for the coding > guidelines: > > A top level package's __init__.py should be importable under all > circumstances, and should not too much "stuff" in it, for lack of a > better word. ?To explain: Several of our own packages have an > __init__.py that contains a lot of functionality, such that when I try > to import it, it might crash (due to some prerequisite not being met), > take a very long time (due to it importing many submodules > unnecessarily), or it might have actual side effects like writing to the > filesystem. > > All of these behaviors should be discouraged. ?In particular it can > cause problems for installation and test frameworks which use the Python > import mechanism to discover packages and modules on the path. ?Merely > importing the package should not fail due to, for example, an > environment variable not being set. > > There are valid reasons for the __init__.py containing functionality, in > particular for ease of use at the Python command line. ?But they should > be designed so that they can at least be imported without side-effects. > ?This would mean cleanly disabling certain functionality if any > prerequisites are not bet, and delaying any side-effects until it's > certain that they are necessary. > > Just to give a concrete example (that's long since been fixed, actually) > matplotlib used to try to write out a default cache/config directory > upon import, which could fail if the process it was running in didn't > have permission to create that directory. ?That's the kind of thing that > should be avoided. ?I think that a note to that effect should be added > to the coding guidelines. ?I'd be happy to write up a draft if people > agree with this. Sounds good to me - feel free to write up such a note and submit it either in github pull request form or just on this mailing list. -- Erik Tollerud From erik.tollerud at gmail.com Mon Aug 15 03:25:50 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Mon, 15 Aug 2011 00:25:50 -0700 Subject: [AstroPy] Testing Guidelines In-Reply-To: <4E36EA6F.3000103@stsci.edu> References: <00945222-7EE6-421B-AB46-A534A4E4A733@astro.physik.uni-goettingen.de> <4E36EA6F.3000103@stsci.edu> Message-ID: On Mon, Aug 1, 2011 at 11:03 AM, Mark Sienkiewicz wrote: > Erik Tollerud wrote: >> >> In principle, the similarities between nose and py.test mean we >> wouldn't really have to make a decision until we need features that >> differ between them- developers could run whichever they prefer... >> > > If the decision goes that way, I can write up a document describing a common > subset that covers most of what you need to do in routine testing. ?Then you > make your standard "use the astrolib-defined nose/py.test subset whenever it > is practical". ?Only a few unusual cases will need to deviate. That seems like a great idea to me. Unless there are objections, I'm inclined to suggest we adopt py.test as the suggested runner based on it having the widest compatibility... Or are there still misgivings about this? (I'm speculating not given that there's been nothing on this topic in the last couple weeks.) >> Except there's one problem: the configuration files are formatted >> differently... ?We want to use configuration settings for just one of >> the packages so that the suite always runs the same. > > What configuration file is that? ?I don't recall ever writing a > configuration file for either nose or py.test. In setup.cfg you can add a [nosetest] or a [pytest] section to customize various things like which directories to look into (if not default), as well as a variety of options setting how the output appears. While not necessarily important if you know what you're doing, this makes it much easier to have random people running the test suite, because you can be sure the output they are seeing looks just like the output you expect to be seeing. I suppose this isn't necessary if none of the defaults will be changed, but it still makes sense to specify which we want people to run (and developers to be familiar with). Assuming we adopt py.test, though, the other useful change would be to generate the standalone py.test script and hook it into "python setup.py test" so that no one has to download py.test to run the test suite with py.test. That's the only thing I can see that would definitely require a source code change. >> The biggest change I see is that it seems to now include a test >> discovery tool, but it is much less documented (a few paragraphs >> rather than many pages each for the other two), and seems to lack most >> of the nose and py.test runners' customization (like configuring in >> the setup.cfg file, easy plugins, etc.). It's an improvement, but it's >> still based around the more complex syntax of unittest, so most of >> what I said above as far as I can tell is still true. >> > > > IMHO, the most interesting feature to me are the new comparison functions. Just so we're on the same page, by this do you mean all the new assert* methods of the TestCase class? > I never really liked all the weird "fail unless not less than or equal" kind > of functions, but the nice thing in unittest2 is that some of the comparison > functions are able to display useful reports about what the nature of the > failure. ?For example, I seem to remember a string compare that will split > multi-line strings and display a diff-like result. > > It strikes me as poor modularization, though: ?there should be a separate > library of comparison functions that can be used with any test framework, > not a slightly different implementation in every test framework. > > I think you can write a test function for nose or py.test and still use a > unittest2 comparison function; you just have to be a little tricky. ?It's > the kind of thing you would hide in a library. ?Maybe we provide our own > library of test helper functions. It's not clear to me that it's possible to use these comparison tool outside unittest2 - they seem to all be methods of TestCase and thus have to be done inside a unittest TestCase object (which is the whole point of using nose or py.test to avoid). As you say, that's really too bad, because they have some nice features. It looks to me like most of this sort of useful contextual information is part of in py.test's output, though (see http://pytest.org/latest/example/reportingdemo.html#tbreportdemo). The multiline string diff as well as a sequence diff reporting seems to be builtin to py.test if you just do "assert a==b" ... I didn't realize that until now - pretty neat! > The biggest negative of unittest2 is that it is still unittest. ?When I > first read about unittest, I thought "this is crazy complicated for running > a simple test; I'm not going to use it". ?I have a better understanding of > it now, but I ?still only ever use it when I have no other choice, and that > basically means when I am working on code that somebody else already wrote > using unittest. I completely agree on this point - that's why I certainly don't want to say "only unittest tests will be accepted" or something along those lines. -- Erik Tollerud From embray at stsci.edu Mon Aug 15 10:12:13 2011 From: embray at stsci.edu (Erik Bray) Date: Mon, 15 Aug 2011 10:12:13 -0400 Subject: [AstroPy] Coding Guidelines draft (comments encouraged) In-Reply-To: References: <4E245896.3020601@stsci.edu> <4E29D2E0.6030708@gemini.edu> <4E2DD5E0.5070404@stsci.edu> <4E380690.1020501@stsci.edu> Message-ID: <4E49293D.7090701@stsci.edu> On 08/15/2011 02:30 AM, Erik Tollerud wrote: >> I know people have been busy, myself included, but I wonder if anyone >> has had time to consider the use of super() and the defense thereof. > > Based on the lack of further discussion on the top, it would seem not :) > >> I would change the coding guidelines read opposite of how they do >> currently: Use of super() should be encouraged except where one knows >> for sure that it's not going to be appropriate, due to the need for a >> customized method resolution order. What *should* be discouraged is the >> use of multiple inheritance except in the cases of orthogonal bases, or >> if one is really sure what they're doing. > > You raise some very good points - my main concern was that it always > be consistently super() or consistently not . I can see that use of > super() would be a safer guideline given these use cases - does anyone > object to this? > > If not (within a few days,hopefully), I will update the guidelines to > suggest using super() unless there is a specific reason not to (and > require that it be specifically mentioned if so), as well as > discouraging multiple inheritance without a good reason (and replace > the old example with an orthogonal base/mixin example that uses > super()). Thanks! Sounds like a good plan. I may also add an example of my own, but a mixin example sounds like a good start. >> On an unrelated matter, I have one other suggestion for the coding >> guidelines: >> >> A top level package's __init__.py should be importable under all >> circumstances, and should not too much "stuff" in it, for lack of a >> better word. To explain: Several of our own packages have an >> __init__.py that contains a lot of functionality, such that when I try >> to import it, it might crash (due to some prerequisite not being met), >> take a very long time (due to it importing many submodules >> unnecessarily), or it might have actual side effects like writing to the >> filesystem. >> ... > Sounds good to me - feel free to write up such a note and submit it > either in github pull request form or just on this mailing list. Ah, I hadn't realized that the coding guide and other docs were on github now. I will do that then. Thanks again, Erik From sienkiew at stsci.edu Mon Aug 15 11:29:45 2011 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Mon, 15 Aug 2011 11:29:45 -0400 Subject: [AstroPy] Testing Guidelines In-Reply-To: References: <00945222-7EE6-421B-AB46-A534A4E4A733@astro.physik.uni-goettingen.de> <4E36EA6F.3000103@stsci.edu> Message-ID: <4E493B69.90607@stsci.edu> Erik Tollerud wrote: > On Mon, Aug 1, 2011 at 11:03 AM, Mark Sienkiewicz wrote: > >> If the decision goes that way, I can write up a document describing a common >> subset that covers most of what you need to do in routine testing. Then you >> make your standard "use the astrolib-defined nose/py.test subset whenever it >> is practical". Only a few unusual cases will need to deviate. >> > > That seems like a great idea to me. I'll put something together when I get some time. > Unless there are objections, I'm > inclined to suggest we adopt py.test as the suggested runner based on > it having the widest compatibility... Or are there still misgivings > about this? (I'm speculating not given that there's been nothing on > this topic in the last couple weeks.) > Unless somebody specifically requests a poll, I think we have a consensus. >>> Except there's one problem: the configuration files are formatted >>> differently... We want to use configuration settings for just one of >>> the packages so that the suite always runs the same. >>> >> What configuration file is that? I don't recall ever writing a >> configuration file for either nose or py.test. >> > > In setup.cfg you can add a [nosetest] or a [pytest] section to > I see - you are talking about a setuptools config file, not a nose config or py.test config. I'll have to read up on what that is about. > Assuming we adopt py.test, though, the other useful change would be to > generate the standalone py.test script and hook it into "python > setup.py test" so that no one has to download py.test to run the test > suite with py.test. That's the only thing I can see that would > definitely require a source code change. > Yes. Put that in the coding standard. We should have a script (with a standardized name) to update all the generated source code. It should re-gen C interface defintions, and make the py.test standalone script. Presumably there may be other things, e.g. if the author uses a parser generator or something like that. >> IMHO, the most interesting feature to me are the new comparison functions. >> > > Just so we're on the same page, by this do you mean all the new > assert* methods of the TestCase class? > Yes. > It's not clear to me that it's possible to use these comparison tool > outside unittest2 - they seem to all be methods of TestCase and thus > have to be done inside a unittest TestCase object (which is the whole > point of using nose or py.test to avoid). As you say, that's really > too bad, because they have some nice features. > All you need is to make a TestCase object and call the comparison methods. Here is a proof of concept: import unittest2 class dummy_ut2( unittest2.TestCase ) : # not named test_something __test__ = False # just in case def runTest( wtf ) : raise Exception('Should never be called') xcmp = dummy_ut2() def test_a() : xcmp.assertAlmostEqual( 1.001, 1.002, places=4 ) In principle, you can bury this kind of thing in a library, then use the comparison functions even when you don't want to make classes based on unittest2. The major drawback I see here is that py.test reports a complete listing of the function that raises the exception, NOT the function that it called to run the test. So, you get a listing of assertAlmostEqual instead of a listing of test_a. I have in mind various ideas for workarounds. So why would you do this? - get the nice comparison functions of unittest2 without re-implementing them - make them available to any test system Of course, nothing here stops anybody from writing assert a == b when that is the convenient thing to do. > It looks to me like most of this sort of useful contextual information > is part of in py.test's output, though (see > http://pytest.org/latest/example/reportingdemo.html#tbreportdemo). > The multiline string diff as well as a sequence diff reporting seems > to be builtin to py.test if you just do "assert a==b" ... I didn't > realize that until now - pretty neat! > That is nice. I had not seen that before. From jturner at gemini.edu Tue Aug 16 14:01:07 2011 From: jturner at gemini.edu (James Turner) Date: Tue, 16 Aug 2011 14:01:07 -0400 Subject: [AstroPy] Coding Guidelines draft (comments encouraged) In-Reply-To: References: <4E245896.3020601@stsci.edu> <4E29D2E0.6030708@gemini.edu> <4E2DD5E0.5070404@stsci.edu> <4E380690.1020501@stsci.edu> Message-ID: <4E4AB063.8060102@gemini.edu> >> I would change the coding guidelines read opposite of how they do >> currently: Use of super() should be encouraged except where one knows >> for sure that it's not going to be appropriate, due to the need for a >> customized method resolution order. What *should* be discouraged is the >> use of multiple inheritance except in the cases of orthogonal bases, or >> if one is really sure what they're doing. > > You raise some very good points - my main concern was that it always > be consistently super() or consistently not . I can see that use of > super() would be a safer guideline given these use cases - does anyone > object to this? It's good to see these guidelines benefiting from everyone's experience -- my only comment would be to encourage good examples for those of us who are still a bit unsure exactly what super does and why :-). (I know it won't matter for simple cases that we're most likely to use.) BTW, I notice that the Python docs say super only works for new-style classes, so perhaps our guidelines should require those (I don't think they are part of PEP 8)? Cheers, James. From embray at stsci.edu Tue Aug 16 14:25:13 2011 From: embray at stsci.edu (Erik Bray) Date: Tue, 16 Aug 2011 14:25:13 -0400 Subject: [AstroPy] Coding Guidelines draft (comments encouraged) In-Reply-To: <4E4AB063.8060102@gemini.edu> References: <4E245896.3020601@stsci.edu> <4E29D2E0.6030708@gemini.edu> <4E2DD5E0.5070404@stsci.edu> <4E380690.1020501@stsci.edu> <4E4AB063.8060102@gemini.edu> Message-ID: <4E4AB609.6040609@stsci.edu> On 08/16/2011 02:01 PM, James Turner wrote: >>> I would change the coding guidelines read opposite of how they do >>> currently: Use of super() should be encouraged except where one knows >>> for sure that it's not going to be appropriate, due to the need for a >>> customized method resolution order. What *should* be discouraged is the >>> use of multiple inheritance except in the cases of orthogonal bases, or >>> if one is really sure what they're doing. >> >> You raise some very good points - my main concern was that it always >> be consistently super() or consistently not . I can see that use of >> super() would be a safer guideline given these use cases - does anyone >> object to this? > > It's good to see these guidelines benefiting from everyone's experience > -- my only comment would be to encourage good examples for those of us > who are still a bit unsure exactly what super does and why :-). > (I know it won't matter for simple cases that we're most likely to use.) > > BTW, I notice that the Python docs say super only works for new-style > classes, so perhaps our guidelines should require those (I don't think > they are part of PEP 8)? > > Cheers, > > James. Good points--I will see about adding an example to the documentation. And yes, the guidelines should add that new-style classes are required (for any new code that is--there are some classes in the Python stdlib that are still not new-style, and nothing can be done about that). Also, for Python 3 it's a non-issue. Though it's meaningless until there's some actual code, it will be good at some point to discuss Python 3. But I'd hold off on going any detail on that until there's code to actually worry about porting. Thanks, Erik From erik.tollerud at gmail.com Tue Aug 16 14:25:45 2011 From: erik.tollerud at gmail.com (Erik Tollerud) Date: Tue, 16 Aug 2011 11:25:45 -0700 Subject: [AstroPy] Coding Guidelines draft (comments encouraged) In-Reply-To: <4E4AB063.8060102@gemini.edu> References: <4E245896.3020601@stsci.edu> <4E29D2E0.6030708@gemini.edu> <4E2DD5E0.5070404@stsci.edu> <4E380690.1020501@stsci.edu> <4E4AB063.8060102@gemini.edu> Message-ID: > It's good to see these guidelines benefiting from everyone's experience > -- my only comment would be to encourage good examples for those of us > who are still a bit unsure exactly what super does and why :-). > (I know it won't matter for simple cases that we're most likely to use.) > > BTW, I notice that the Python docs say super only works for new-style > classes, so perhaps our guidelines should require those (I don't think > they are part of PEP 8)? Good point - technically it's already in there because we're requiring Python 3.x compatibility, and in 3.x all classes behave like new-style classes... but that's a potential source of confusion because the 2to3 tool doesn't complain if you use an old-style class (which implicitly means it gets converted to new-style). So I'll add a statement that only new-style classes are to be used. -- Erik Tollerud From laidler at stsci.edu Tue Aug 16 18:22:29 2011 From: laidler at stsci.edu (Victoria G. Laidler) Date: Tue, 16 Aug 2011 18:22:29 -0400 Subject: [AstroPy] Testing Guidelines In-Reply-To: References: <00945222-7EE6-421B-AB46-A534A4E4A733@astro.physik.uni-goettingen.de> <4E36EA6F.3000103@stsci.edu> Message-ID: <4E4AEDA5.1020309@stsci.edu> Erik Tollerud wrote: > On Mon, Aug 1, 2011 at 11:03 AM, Mark Sienkiewicz wrote: > >> Erik Tollerud wrote: >> >>> In principle, the similarities between nose and py.test mean we >>> wouldn't really have to make a decision until we need features that >>> differ between them- developers could run whichever they prefer... >>> >>> >> If the decision goes that way, I can write up a document describing a common >> subset that covers most of what you need to do in routine testing. Then you >> make your standard "use the astrolib-defined nose/py.test subset whenever it >> is practical". Only a few unusual cases will need to deviate. >> > > That seems like a great idea to me. Unless there are objections, I'm > inclined to suggest we adopt py.test as the suggested runner based on > it having the widest compatibility... Or are there still misgivings > about this? (I'm speculating not given that there's been nothing on > this topic in the last couple weeks.) > Mike Droettboom has experimented with py.test a little bit while working on a py.test plugin for Pandokia. He reports that it's not quite so compatible as all that, ie, there are useful test extensions (such as module-level setup and teardown) that are supported by nose that py.test does not handle correctly. Mike, do you want to say more about that? Also, I meant to report back regarding the status of nose that I got from the TiP folks a bit ago: - the primary developer of nose, Jason Pellerin, doesn't have time to do very much, but there is starting to be more maintenance activity and contribution from the community on the nose-dev list (http://groups.google.com/group/nose-dev). nose 1.1 was released at the end of July - the plan is to move to a BSD-licensed nose2 package based on the unittest2 plugins branch, but that unittest2 branch is on hold until the unittest2 developer (Michael Foord) can get back to it. (https://bitbucket.org/jpellerin/nose2/overview, http://hg.python.org/unittest2/) From omar.vpa at gmail.com Wed Aug 17 11:53:22 2011 From: omar.vpa at gmail.com (=?ISO-8859-1?Q?Omar_Trinidad_Guti=E9rrez_M=E9ndez?=) Date: Wed, 17 Aug 2011 10:53:22 -0500 Subject: [AstroPy] About a FITS Images Message-ID: Hi! ?Anyone knows about an public Astronomical Database Images in FITS format? Greetings -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.schwarzburg at googlemail.com Wed Aug 17 12:03:46 2011 From: stefan.schwarzburg at googlemail.com (Stefan Schwarzburg) Date: Wed, 17 Aug 2011 18:03:46 +0200 Subject: [AstroPy] About a FITS Images In-Reply-To: References: Message-ID: You can have a look at this site: http://fits.gsfc.nasa.gov/fits_samples.html Cheers, Stefan 2011/8/17 Omar Trinidad Guti?rrez M?ndez > Hi! > > ?Anyone knows about an public Astronomical Database Images in FITS format? > > Greetings > > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroe at stsci.edu Wed Aug 17 14:57:50 2011 From: mdroe at stsci.edu (Michael Droettboom) Date: Wed, 17 Aug 2011 14:57:50 -0400 Subject: [AstroPy] Testing Guidelines In-Reply-To: <4E4AEDA5.1020309@stsci.edu> References: <00945222-7EE6-421B-AB46-A534A4E4A733@astro.physik.uni-goettingen.de> <4E36EA6F.3000103@stsci.edu> <4E4AEDA5.1020309@stsci.edu> Message-ID: <4E4C0F2E.5000003@stsci.edu> On 08/16/2011 06:22 PM, Victoria G. Laidler wrote: > Erik Tollerud wrote: >> On Mon, Aug 1, 2011 at 11:03 AM, Mark Sienkiewicz wrote: >> >>> Erik Tollerud wrote: >>> >>>> In principle, the similarities between nose and py.test mean we >>>> wouldn't really have to make a decision until we need features that >>>> differ between them- developers could run whichever they prefer... >>>> >>>> >>> If the decision goes that way, I can write up a document describing a common >>> subset that covers most of what you need to do in routine testing. Then you >>> make your standard "use the astrolib-defined nose/py.test subset whenever it >>> is practical". Only a few unusual cases will need to deviate. >>> >> That seems like a great idea to me. Unless there are objections, I'm >> inclined to suggest we adopt py.test as the suggested runner based on >> it having the widest compatibility... Or are there still misgivings >> about this? (I'm speculating not given that there's been nothing on >> this topic in the last couple weeks.) >> > Mike Droettboom has experimented with py.test a little bit while working > on a py.test plugin for Pandokia. He reports that it's not quite so > compatible as all that, ie, there are useful test extensions (such as > module-level setup and teardown) that are supported by nose that py.test > does not handle correctly. > > Mike, do you want to say more about that? The nose "compatibility" plugin in py.test handles only the most basic cases. I have no idea how much work it would be to bring it closer. But I think in the long run, we should standardize on both the tool and the format, as compatibility layers are bound to diverge over time. Mike From sienkiew at stsci.edu Wed Aug 17 15:11:21 2011 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Wed, 17 Aug 2011 15:11:21 -0400 Subject: [AstroPy] Testing Guidelines In-Reply-To: <4E4AEDA5.1020309@stsci.edu> References: <00945222-7EE6-421B-AB46-A534A4E4A733@astro.physik.uni-goettingen.de> <4E36EA6F.3000103@stsci.edu> <4E4AEDA5.1020309@stsci.edu> Message-ID: <4E4C1259.2040608@stsci.edu> Victoria G. Laidler wrote: > Mike Droettboom has experimented with py.test a little bit while > working on a py.test plugin for Pandokia. He reports that it's not > quite so compatible as all that, ie, there are useful test extensions > (such as module-level setup and teardown) that are supported by nose > that py.test does not handle correctly. It appears that the nose compatibility is not good enough that you can just assume your nose tests will work in py.test. When I look at it closely, it looks more like marketing than actual working software. A lot of the compatibility mode depends on the similarity between the systems, but there are some things where there is actual compatibility code. I know of nothing you can do in nose that you can't do in py.test. There are many differences in syntax, though. It is still possible to write to a simplified test format that work in both systems. I have sample tests that work in both unmodified that have: module setup, module teardown, test function, test class (with setup and teardown), skip test function/method (using a helper function), test generator using yield Mark From omar.vpa at gmail.com Thu Aug 18 14:05:43 2011 From: omar.vpa at gmail.com (=?ISO-8859-1?Q?Omar_Trinidad_Guti=E9rrez_M=E9ndez?=) Date: Thu, 18 Aug 2011 13:05:43 -0500 Subject: [AstroPy] About FITS format Message-ID: Guys: What is the color space of FITS format... I'd like know it... Could be possible translate it to RGB or CMYK color spaces without loosing information... Greetings -------------- next part -------------- An HTML attachment was scrubbed... URL: From perry at stsci.edu Thu Aug 18 14:29:08 2011 From: perry at stsci.edu (Perry Greenfield) Date: Thu, 18 Aug 2011 14:29:08 -0400 Subject: [AstroPy] About FITS format In-Reply-To: References: Message-ID: <0DCE2992-68AF-47C2-923F-F93C61DC9D2D@stsci.edu> FITS, as such, doesn't have the concept of color space. People have found ways of using fits to hold RGB images and the like, but generally, a FITS image is usually taken through one filter. It's usually up to someone to combine images from different filters into a color image. But perhaps you have one of these "color" images already. If so, where did you get it? What does the header show? Perry On Aug 18, 2011, at 2:05 PM, Omar Trinidad Guti?rrez M?ndez wrote: > Guys: > > What is the color space of FITS format... I'd like know it... Could > be possible translate it to RGB or CMYK color spaces without loosing > information... > > Greetings > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy From jslavin at cfa.harvard.edu Mon Aug 22 12:18:30 2011 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Mon, 22 Aug 2011 12:18:30 -0400 Subject: [AstroPy] equivalent routine to IDL Astronomy Library lineid_plot Message-ID: <1314029910.24674.24.camel@shevek> Hi all, Does any know if there exists a python/matplotlib equivalent for the IDL Astronomy Library routine named lineid_plot? What it does is plot a spectrum with line list identifications annotated on it at the top of the plot. I searched and couldn't find anything like it. It does nice things like making multiple line segments to separate the line ids for cases where the lines are too close together. Jon -- ______________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA ______________________________________________________________ From marquett at iap.fr Tue Aug 23 12:27:43 2011 From: marquett at iap.fr (Jean-Baptiste Marquette) Date: Tue, 23 Aug 2011 18:27:43 +0200 Subject: [AstroPy] ATpy questions Message-ID: <451E75A7-228A-40C3-BEBF-5B769EAEFFE3@iap.fr> Hi all, I have 3 questions about the use of ATpy: How to add a leading "#" to the header of the Table? It is possible to read tables with a header like "# erosid Ra Dec MagR", but writing such a table removes the "#". How to replace in a table an entire column by the content of a single-column asciitable ? Coding like: Data = atpy.Table(Catalog, type='ascii', numpy=False) DataDistort = Data RA, DEC = asciitable.read(RAdec, delimiter='\n', Reader=asciitable.NoHeader, numpy=False), asciitable.read(DECdec, delimiter='\n', Reader=asciitable.NoHeader, numpy=False) DataDistort.Ra = RA[0] DataDistort.Dec = DEC[0] put the first value of RA/DEC on all the rows of DataDistort.Ra/Dec. Finally: How to change the format of a column? I didn't find anything to force the writing of trailing zeros. Thanks for your help, Cheers Jean-Baptiste -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldcroft at head.cfa.harvard.edu Tue Aug 23 12:41:40 2011 From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft) Date: Tue, 23 Aug 2011 12:41:40 -0400 Subject: [AstroPy] ATpy questions In-Reply-To: <451E75A7-228A-40C3-BEBF-5B769EAEFFE3@iap.fr> References: <451E75A7-228A-40C3-BEBF-5B769EAEFFE3@iap.fr> Message-ID: On Tue, Aug 23, 2011 at 12:27 PM, Jean-Baptiste Marquette wrote: > Hi all, > I have 3 questions about the use of ATpy: > > How to add a leading "#" to the header of the Table? It is possible to read > tables with a header like "# ?erosid ? ? ?Ra ? ? ? ? Dec ? ? ?MagR", but > writing such a table removes the "#". Hopefully this example helps with two of your questions: In [1]: import asciitable In [2]: dat = asciitable.read('a b\n 1 2') # Read a simple table In [3]: asciitable.write(dat, sys.stdout, Writer=asciitable.CommentedHeader, formats={'a': '%.4f', 'b': '%.2f'}) # a b 1.0000 2.00 > How to replace in a table an entire column by the content of a single-column > asciitable ? > > Coding like: > Data = atpy.Table(Catalog, type='ascii', numpy=False) > DataDistort = Data > RA, DEC = asciitable.read(RAdec, delimiter='\n', Reader=asciitable.NoHeader, > numpy=False), asciitable.read(DECdec, delimiter='\n', > Reader=asciitable.NoHeader, numpy=False) > DataDistort.Ra = RA[0] > DataDistort.Dec = DEC[0] This should work: DataDistort.Ra[:] = RA[0] DataDistort.Dec[:] = DEC[0] > put the first value of RA/DEC on all the rows of DataDistort.Ra/Dec. > Finally: > > How to change the format of a column? I didn't find anything to force the > writing of trailing zeros. As above, use the "formats" keyword when writing using asciitable. And don't be afraid to read the docs, it's right there for you. :-) http://cxc.harvard.edu/contrib/asciitable/#commonly-used-parameters-for-write - Tom > Thanks for your help, > Cheers > Jean-Baptiste > _______________________________________________ > AstroPy mailing list > AstroPy at scipy.org > http://mail.scipy.org/mailman/listinfo/astropy > > From hack at stsci.edu Tue Aug 23 16:50:42 2011 From: hack at stsci.edu (Warren J. Hack) Date: Tue, 23 Aug 2011 16:50:42 -0400 Subject: [AstroPy] TABLES/STSDAS v3.14 and STSCI_PYTHON v2.12 NOW AVAILABLE Message-ID: <4E5412A2.1030602@stsci.edu> ******************************************************* TABLES/STSDAS v3.14 and STSCI_PYTHON v2.12 NOW AVAILABLE ******************************************************* The Science Software Branch of the Space Telescope Science Institute wishes to announce the availability of version 3.14 of the Space Telescope Science Data Analysis Software (STSDAS). Concurrent with the STSDAS release, we have also released v3.14 of the TABLES external package. Both of these packages are layered upon IRAF as external packages; it is therefore necessary to obtain and install IRAF (from http://iraf.noao.edu) before installing TABLES and STSDAS. STSDAS is linked against libraries in TABLES, so TABLES must be installed before STSDAS. ------ STSDAS ------ This release of STSDAS contains changes to STIS, COS, ACS, and WFC3. This release includes the same versions of the calibration software used in the pipeline to support all active HST instruments using the algorithms developed from the data taken during Servicing Mission 4, especially for the Advanced Camera for Surveys (ACS), Wide Field Camera 3(WFC3) and the Cosmic Origins Spectrograph(COS). This release contains the latest version of the stecf IRAF package for supporting HST data that had been developed by members of the Space Telescope European Coordinating Facility (ST-ECF) which closed on 31 December 2010. Support for these packages may be obtained by contacting the STScI Help Desk at 'help at stsci.edu'. These questions will then be forwarded to the package authors at ESO as required. STSDAS also includes some Python-based tasks; running these requires the STScI Python Libraries to be installed (all the non-Python tasks can be used in the traditional way and do not require Python or the STScI Python libraries). These tasks can only be run from PyRAF using standard IRAF CL task syntax, or within Python scripts using Python syntax. ------ Tables ------ This distribution of TABLES includes the TTOOLS package, as well as FITSIO, and TBPLOT, along with the gflib, stxtools, and tbtables libraries. All these packages and libraries have been compiled to run under 32-bit IRAF only, in contrast to the 64-bit version of TTOOLS (installed as NTTOOLS) and the tbtables library supported by IRAF and included in IRAF 2.15. ------------- STScI_Python ------------- The Science Software Branch of STScI also wishes to announce the availability of version 2.12 of STSCI_PYTHON. STScI_Python is a collection of Python modules, packages and C extensions that has been developed to provide a general astronomical data analysis infrastructure. They can be used for Python tasks that are accessible from within STSDAS when running under PyRAF or standalone from within Python. The primary testing for this release also took place using Python 2.7.1 with numpy 2.0, although this code was also tested under Python 2.5.4 as well. This testing took place under Linux and Mac OS X (both 10.5 and 10.6), but testing no longer takes place on Solaris. Some revisions to the code in this release have been made in preparation for the transition to supporting Python 3. This version does not run under Python 3, but these changes represent the first steps in making this code suitable for conversion. It is anticipated that the next full release of the PyRAF package (late 2011/early 2012) will have basic capabilities working under Python 3. This release introduces namespace changes to many of the packages as one part of the effort to update how these packages are built and installed. The packages whose names have changed include: old name ---> new name ---------- ------------- convolve stsci.convolve image stsci.image imagemanip stsci.imagemanip imagestats stsci.imagestats numdisplay stsci.numdisplay pytools stsci.tools stimage stsci.stimage ndimage stsci.ndimage Any Python code which referenced any of these packages will need to be updated to use the new names. This distribution continues to develop packages with tasks specific to each HST instrument, with updates being made to calibration code for COS, while adding tasks for working with ACS data. The updates to the ACS tasks which correct for CTE effects in ACS images. PyFITS V3.0 included in this release has been significantly revised, with the full details of the changes described in the release notes. The STWCS package has also been revised to correct bugs and add functionality to the HSTWCS object. Significant updates were also made to TEAL (the EPAR-like parameter editor GUI) to provide more advanced behaviors and to document how it can be used as a GUI for running any command-line driven Python task. This release also contains pysynphot v0.9 which contains several bug fixes and significant performance improvements for some calculations. -------------- HSTCAL Package -------------- This release also contains a new package called HSTCAL. This package contains everything necessary to compile C code, written under IRAF using the CVOS interface, without the use of IRAF at all. The HSTIO image and tables C API has been replicated using CFITSIO. This new API was then used to compile the ACS calibration code CALACS for use without IRAF. This new version of CALACS, though, relies on a new reference table, IMPHTTAB, to provide the values of the photometric keywords instead of calling IRAF's synphot package. The IMPHTTAB reference table can be downloaded using the ACS team reference file web page. This version of CALACS, Version 6.1.0, has been installed as the calibration software that gets used in the archive and for pipeline calibrations, replacing the previous STSDAS/IRAF based version. 64-bit IRAF Support =================== IRAF 2.15 includes support for 64-bit systems. The changes necessary to support 64-bits generally require applications to be modified. We will only release 32-bit binaries fo the Tables and STSDAS packages for use with IRAF 2.15. Support for 32-bit binaries will continue as long as there are sufficient plaforms that such binaries will run on. We may only convert some packages in Tables and STSDAS to 64-bit version when the 32-bit versions are no longer viable and if created will be released as a separate package with a different name. When the 32-bit versions of TABLES and STSDAS are no longer viable, support for any tasks within those packages not ported to 64-bits will end. The full description of this policy can be found online at: http://www.stsci.edu/resources/software_hardware/stsdas/iraf64 Platform Support ================ This release does not contain STSDAS/Tables binaries for PowerPC Macintosh systems. However, there are no known reasons why a user could not build this package from source code on a PowerPC using the installation instructions for STSDAS. STSDAS/Tables Binaries for this release were built on Red Hat Enterprise Linux 4 and 5, and Mac OS X 10.5 and 10.6 (Intel architecture only). STSDAS/Tables Binaries were built with IRAF 2.14, except for Solaris, which were built with IRAF 2.12.2a. IRAF is available from http://iraf.net. In addition, this distribution of STScI_Python was tested to correctly support installation on Linux, Mac OS X 10.5 (Leopard), and Mac OS X 10.6, while also being provided for installation (without IRAF) under Windows. No Solaris Support ------------------ This version was not built or tested on Solaris. The source code, however, can always be downloaded and compiled locally as needed. STSCI_Python on WINDOWS ======================= This release includes a port of stsci_python that runs natively under Windows. PyRAF is not included for use with the Windows distribution, but the source distribution for STScI_Python could potentially be installed under Cygwin to work with the IRAF installation there, although that configuration has not been verified or tested. The primary requirement for use of this installer is that the Windows executables were built against and, therefore, can run only under Python 2.7. WHERE TO OBTAIN THIS SOFTWARE ============================= STSDAS/TABLES v3.14 can be downloaded from the STSDAS web site. The installation instructions for all these packages have changed. You can now download a single tar file that contains the source code and binaries for STSDAS, TABLES, and STECF. There is also a smaller file if you just need TABLES. You can see the new installation instructions at http://www.stsci.edu/resources/software_hardware/stsdas/download Installation instructions are available on the web site. Precompiled binaries also exist for some of the ports supported by NOAO, including RedHat Linux and Mac OS X. STSCI_PYTHON v 2.12 be downloaded from the PyRAF web site: http://www.stsci.edu/resources/software_hardware/pyraf/stsci_python/current/download Installation instructions are available from the PyRAF web site, with support for installations on RedHat Linux, Mac OS X, and Windows. Please contact us through e-mail (help at stsci.edu), by telephone at (410) 338-1082. From johann.cohentanugi at gmail.com Wed Aug 24 02:42:34 2011 From: johann.cohentanugi at gmail.com (Johann Cohen-Tanugi) Date: Wed, 24 Aug 2011 08:42:34 +0200 Subject: [AstroPy] equivalent routine to IDL Astronomy Library lineid_plot In-Reply-To: <1314029910.24674.24.camel@shevek> References: <1314029910.24674.24.camel@shevek> Message-ID: <4E549D5A.5090801@gmail.com> Hi Jon, this is an ultra specialized IDL script. While I am sure it could be part of an astro dedicated extension to matplotlib, I would not be surprised that matplotlib does not deliver anything like that. Of course this is the right place to ask, as maybe someone has already implemented it for her/his own use. Could you provide a specific figure as an example of what you would like to achieve? best, JCT On 08/22/2011 06:18 PM, Jonathan Slavin wrote: > Hi all, > > Does any know if there exists a python/matplotlib equivalent for the IDL > Astronomy Library routine named lineid_plot? What it does is plot a > spectrum with line list identifications annotated on it at the top of > the plot. I searched and couldn't find anything like it. It does nice > things like making multiple line segments to separate the line ids for > cases where the lines are too close together. > > Jon From marquett at iap.fr Wed Aug 24 03:46:44 2011 From: marquett at iap.fr (Jean-Baptiste Marquette) Date: Wed, 24 Aug 2011 09:46:44 +0200 Subject: [AstroPy] ATpy questions In-Reply-To: References: <451E75A7-228A-40C3-BEBF-5B769EAEFFE3@iap.fr> Message-ID: <549CF224-A6D3-46D8-8B20-AD8048BB54BD@iap.fr> Hi Tom, Thanks for your answer, very helpful. > On Tue, Aug 23, 2011 at 12:27 PM, Jean-Baptiste Marquette > wrote: >> Hi all, >> I have 3 questions about the use of ATpy: >> >> How to add a leading "#" to the header of the Table? It is possible to read >> tables with a header like "# erosid Ra Dec MagR", but >> writing such a table removes the "#". > > Hopefully this example helps with two of your questions: > > In [1]: import asciitable > In [2]: dat = asciitable.read('a b\n 1 2') # Read a simple table > In [3]: asciitable.write(dat, sys.stdout, > Writer=asciitable.CommentedHeader, formats={'a': '%.4f', 'b': '%.2f'}) > # a b > 1.0000 2.00 > > >> How to replace in a table an entire column by the content of a single-column >> asciitable ? >> >> Coding like: >> Data = atpy.Table(Catalog, type='ascii', numpy=False) >> DataDistort = Data >> RA, DEC = asciitable.read(RAdec, delimiter='\n', Reader=asciitable.NoHeader, >> numpy=False), asciitable.read(DECdec, delimiter='\n', >> Reader=asciitable.NoHeader, numpy=False) >> DataDistort.Ra = RA[0] >> DataDistort.Dec = DEC[0] > > This should work: > > DataDistort.Ra[:] = RA[0] > DataDistort.Dec[:] = DEC[0] The right code is: RA, DEC = asciitable.read(RAdec, delimiter=' ', Reader=asciitable.NoHeader, numpy=True), asciitable.read(DECdec, delimiter=' ', Reader=asciitable.NoHeader, numpy=True) DataDistort.Ra[:] = np.asarray(RA) DataDistort.Dec[:] = np.asarray(DEC) > >> put the first value of RA/DEC on all the rows of DataDistort.Ra/Dec. >> Finally: >> >> How to change the format of a column? I didn't find anything to force the >> writing of trailing zeros. > > As above, use the "formats" keyword when writing using asciitable. > And don't be afraid to read the docs, it's right there for you. :-) > > http://cxc.harvard.edu/contrib/asciitable/#commonly-used-parameters-for-write I did browse the doc quite a while before to ask help. I was lost in the ATpy doc where the link to asciitable one is maybe not as evident as it should be. Anyway, I probably will be at CfA before December. In such a case, you will deserve a beer...{:-) Cheers JB From jslavin at cfa.harvard.edu Wed Aug 24 10:34:03 2011 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Wed, 24 Aug 2011 10:34:03 -0400 Subject: [AstroPy] equivalent routine to IDL Astronomy Library lineid_plot In-Reply-To: <4E549D5A.5090801@gmail.com> References: <1314029910.24674.24.camel@shevek> <4E549D5A.5090801@gmail.com> Message-ID: <1314196443.26304.9.camel@shevek> Johann, I wouldn't expect matplotlib to include such a routine either, but I thought that maybe some astronomer might have had enough motivation to adapt the routine. I'm attaching a figure that I made with the IDL routine. The tricky parts as far as I can tell are making sure there is enough space above the figure (providing that one wants the line labels to be above the figure as the IDL routine makes them) and the creation of those multi-segment lines when the labels are too close together. There are facilities within matplotlib with the annotate command to make such lines, though how to apply it to this specific use is not clear to me. Jon On Wed, 2011-08-24 at 08:42 +0200, Johann Cohen-Tanugi wrote: > Hi Jon, this is an ultra specialized IDL script. While I am sure it > could be part of an astro dedicated extension to matplotlib, I would not > be surprised that matplotlib does not deliver anything like that. Of > course this is the right place to ask, as maybe someone has already > implemented it for her/his own use. Could you provide a specific figure > as an example of what you would like to achieve? > > best, > JCT > > On 08/22/2011 06:18 PM, Jonathan Slavin wrote: > > Hi all, > > > > Does any know if there exists a python/matplotlib equivalent for the IDL > > Astronomy Library routine named lineid_plot? What it does is plot a > > spectrum with line list identifications annotated on it at the top of > > the plot. I searched and couldn't find anything like it. It does nice > > things like making multiple line segments to separate the line ids for > > cases where the lines are too close together. > > > > Jon -- ______________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA ______________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: flux_lines.eps Type: image/x-eps Size: 42230 bytes Desc: not available URL: From taro at ap.smu.ca Wed Aug 24 10:48:39 2011 From: taro at ap.smu.ca (Taro Sato) Date: Wed, 24 Aug 2011 11:48:39 -0300 Subject: [AstroPy] equivalent routine to IDL Astronomy Library lineid_plot In-Reply-To: <1314196443.26304.9.camel@shevek> References: <1314029910.24674.24.camel@shevek> <4E549D5A.5090801@gmail.com> <1314196443.26304.9.camel@shevek> Message-ID: On Wed, Aug 24, 2011 at 11:34 AM, Jonathan Slavin wrote: > Johann, > > I wouldn't expect matplotlib to include such a routine either, but I > thought that maybe some astronomer might have had enough motivation to > adapt the routine. ?I'm attaching a figure that I made with the IDL > routine. > > The tricky parts as far as I can tell are making sure there is enough > space above the figure (providing that one wants the line labels to be > above the figure as the IDL routine makes them) and the creation of > those multi-segment lines when the labels are too close together. ?There > are facilities within matplotlib with the annotate command to make such > lines, though how to apply it to this specific use is not clear to me. > > Jon I have my own custom routine to display line identifications at given redshift but it's not smart enough to avoid overlapping; it only alternates the offsets so that adjacent labels won't always overlap. What you have in your example plot is certainly doable with MPL... It's tricky to ensure that labels are readable most of the time but since you know how to approach the problem, why don't you create one and make it available publicly! If the desired algorithm needed is already coded in the IDL script it shouldn't be too painful. :D -- Taro Sato Department of Astronomy & Physics Saint Mary's University? ? ? ? ? ?? email: taro at ap.smu.ca Halifax, NS B3H 3C3? ? ? ? ? ? ? ?? phone: (902)420-5027 Canada? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? web: http://ap.smu.ca/~taro From jslavin at cfa.harvard.edu Wed Aug 24 11:19:06 2011 From: jslavin at cfa.harvard.edu (Jonathan Slavin) Date: Wed, 24 Aug 2011 11:19:06 -0400 Subject: [AstroPy] equivalent routine to IDL Astronomy Library lineid_plot In-Reply-To: References: <1314029910.24674.24.camel@shevek> <4E549D5A.5090801@gmail.com> <1314196443.26304.9.camel@shevek> Message-ID: <1314199146.26304.16.camel@shevek> If I had the time to do that adaptation, I'd certainly do it -- and may yet -- but it does depend on a lot of things that are very IDL specific such as the character size and plot region, etc. I think that there are some good hints in the discussion on automatically creating enough room for tick labels (http://matplotlib.sourceforge.net/faq/howto_faq.html), but there's quite a bit more needed than that. Jon On Wed, 2011-08-24 at 11:48 -0300, Taro Sato wrote: > I have my own custom routine to display line identifications at given > redshift but it's not smart enough to avoid overlapping; it only > alternates the offsets so that adjacent labels won't always overlap. > What you have in your example plot is certainly doable with MPL... > It's tricky to ensure that labels are readable most of the time but > since you know how to approach the problem, why don't you create one > and make it available publicly! If the desired algorithm needed is > already coded in the IDL script it shouldn't be too painful. :D -- ______________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin at cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA ______________________________________________________________ From aldcroft at head.cfa.harvard.edu Wed Aug 31 15:50:16 2011 From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft) Date: Wed, 31 Aug 2011 15:50:16 -0400 Subject: [AstroPy] AstroPy Coordination Meeting 2011 Message-ID: The AstroPy Coordination Meeting (Oct. 12-13 + sprint on Oct. 14) is fast approaching! I've added some details about the meeting logistics and area lodging to the wiki page: https://github.com/astropy/astropy/wiki/CfAMeeting2011 The unfortunate news is that hotel prices during October are rather high and I was unable to find anything below about $200 / night. One option would be to start the meeting late enough (say 11am) so that at least people on the East coast could fly in on the morning of the 12th and stay just one (or two nights) before flying home in the evening. In order to reduce meeting logistics spam on the astropy list, I've created a mailing list specifically for the meeting: astropy_meeting at head.cfa.harvard.edu All of the people listed on the CfaMeeting2011 wiki page (except "L.W." ??) have been added to this list. I'll be sending a second email confirming email addresses. If you do not receive this email (and think you should) or prefer a different address then let me know. Anyone else who plans to attend or just wants to receive coordination information regarding the meeting please send me an email and I will put you on the list. Best, Tom Aldcroft