[AstroPy] POLL: vision for a common Astronomy package

Thomas Robitaille thomas.robitaille at gmail.com
Tue Jun 28 04:00:24 EDT 2011


Thanks for all the feedback!

I agree that we'll probably want to require Python 2.6+ as well as
support Python 3. We deliberately left out specific coding
requirements like this for now, as there are many similar specific
issues to consider (docstring format, testing framework, C extensions,
Cython, etc.). We've been keeping a list, and if the vision is
approved and we can move ahead, then we can start listing coding
guidelines such as these on the wiki.

Cheers,
Tom

On 28 June 2011 07:44, Wolfgang Kerzendorf <wkerzendorf at googlemail.com> wrote:
> I think we should write python 3 compliant code as most of it is written
> new anyways. Why not save us future pain.
>
> Cheers
>    W
> On 28/06/11 2:55 PM, Erik Tollerud wrote:
>> To clarify, we're not intending  to completely disallow other
>> dependencies, but only stating that they should not be used
>> *initially* when the package is imported.  The idea is that someone
>> should be able to use everything that doesn't specifically require
>> another dependency without getting an ImportError.  If something
>> requires an extra dependency, it should only end up issuing a
>> dependency error when that particular functionality is needed.  For
>> example, "import astropy" and "import astropy.submodule" should always
>> work, but "import astropy.submodule.guiapp" or
>> "astropy.submodule.showgui()" should assue an ImportError if you don't
>> have the appropriate toolkit installed.
>>
>> We also plan to keep watch on the external dependencies to make sure
>> they don't spiral out-of-control, but that will be done case-by-case.
>>
>> You're both right that we should be a bit clearer about what parts of
>> the standard library, though.  My opinion is that we should definitely
>> count everything up to 2.6 (2.6 includes some absolutely crucial
>> features like ABCs), but 2.7 stdlib and anything that's optionally
>> included should be put in the same category as external deps
>> (shouldn't be necessary for the base imports).
>>
>>
>> On Mon, Jun 27, 2011 at 6:32 PM, Matthew Turk<matthewturk at gmail.com>  wrote:
>>> Agreed -- since dependencies are a focus of this vision statement, it
>>> might also be worthwhile to state whether or not modules that are
>>> conditionally compiled (sqlite, ctypes, tkinter, although that is
>>> covered under "GUI" in the statement) in CPython are allowable for
>>> dependencies.
>>>
>>> -Matt
>>>
>>> On Mon, Jun 27, 2011 at 4:30 PM, James Turner<jturner at gemini.edu>  wrote:
>>>> Just another (perhaps overly-obvious) thought. When you list the
>>>> "Python Standard Library", we probably need to decide what version(s)
>>>> of Python we're targeting (can I depend on a standard library module
>>>> that's only in Python 2.7?). Likewise for the other allowed
>>>> dependencies, otherwise people might depend on conflicting versions
>>>> or something.
>>>>
>>>>
>>>> On 27/06/11 18:51, James Turner wrote:
>>>>> Sounds pretty good, but I'm balking a little bit at NO external
>>>>> dependencies. Obviously we can't have an unmanageable proliferation
>>>>> of them, but having none would seem to imply, for example, that we
>>>>> can't include anything that uses a database -- unless we're going to
>>>>> bundle the whole database into *each* "affiliated package" that needs
>>>>> it. It's no good making that an optional import if the database is
>>>>> central to what the module does. Perhaps one of you can elaborate a
>>>>> bit on what you were thinking here? Are you expecting AstroPy only to
>>>>> include lower-level algorithmic/library functionality? I'd have
>>>>> thought there is also room for library routines that are closer to an
>>>>> application level, which a user can interact with more directly.
>>>>> Maybe I'm looking at this from the wrong angle though (it's quite
>>>>> late here and I haven't thought about it that long yet)? I won't
>>>>> suggest an alternative until I understand better what you had in mind.
>>>>>
>>>>> Yes to calling it AstroPy.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> James.
>>>>>
>>>>>
>>>>> On 27/06/11 16:16, Thomas Robitaille wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> In the last week, Erik, Perry, and myself have been discussing how
>>>>>> best to coordinate the development of the common Python Astronomy
>>>>>> package. We have now converged on a common vision, and would now like
>>>>>> to know whether you would be happy with it too. The vision and a
>>>>>> poll are available at the following pages:
>>>>>>
>>>>>> vision: http://astropy.wikispaces.com/vision
>>>>>>
>>>>>> poll: http://astropy.wikispaces.com/vision-polls
>>>>>>
>>>>>> In addition, 'astropy' has been suggested by several people as a name
>>>>>> for this common package, so rather than creating a multi-option poll,
>>>>>> we've created a simple yes/no poll to find out whether you would agree
>>>>>> with this name. The idea is to have a name that does not endorse any
>>>>>> specific existing project, is in line with numpy/scipy, and reflects
>>>>>> its initial development via this mailing list. The poll is located at
>>>>>> the same URL as before.
>>>>>>
>>>>>> The polls will be open unti Friday 1st July at 9pm EST.
>>>>>>
>>>>>> Thanks!
>>>>>> Thomas
>>>>>> _______________________________________________
>>>>>> AstroPy mailing list
>>>>>> AstroPy at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>> _______________________________________________
>>>> AstroPy mailing list
>>>> AstroPy at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



More information about the AstroPy mailing list