[AstroPy] POLL: vision for a common Astronomy package

[Wolfgang Kerzendorf]

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
>>
>
>