python-quantities-developers team mailing list archive

[Darren Dale <dsdale24@xxxxxxxxx>]

I just pushed some changes to the trunk, quantities does not use setuptools
anymore. If someone want to use setuptools, they can contribute a
setupegg.py file.

Tests are now handled using numpy's infrastructure. Just do:

import quantities
quantities.test()

to run the unit tests. If you have coverage installed, you can also do:

coverage_report()

I moved the umath tests into umath/tests/, and I made a minor change to the
__repr__ formatting, so it will look like:

array([ 20.     ,  30.     ,   3.14159]) * J**2*kPa/BTU

I think that's as much as I want to change it for now.

Darren



On Tue, Feb 10, 2009 at 8:11 PM, John Salvatier <jsalvatier@xxxxxxxxx>wrote:

>
> for "[20, 30 , 3.14159] * kPa * J **2 / BTU"
> I think
> array([ 20.     ,  30.     ,   3.14159]) * J**2 * kPa / BTU
> Would look cleaner.
>
> for "print [20, 30 , 3.14159] * kPa * J **2 / BTU"
> I think either
> [ 20.       30.        3.14159] J² · kPa / BTU
> or
> [ 20.       30.        3.14159] J² kPa / BTU
> Would look cleaner.
>
> Just my two cents.
>
> I can implement concatenate and sqrt if that's useful.
>
> John
>
>
> On Tue, Feb 10, 2009 at 11:49 AM, Darren Dale <dsdale24@xxxxxxxxx> wrote:
>
>>
>>
>> On Mon, Feb 9, 2009 at 9:22 PM, John Salvatier <jsalvatier@xxxxxxxxx>wrote:
>>
>>> Sounds good.
>>>
>>> Here are some miscellaneous notes:
>>>
>>>    1. In the tutorial, the part describing simplification in unambiguous
>>>    situations is vague. It might be good to say that "unambiguous" means the
>>>    units cancel directly
>>>    2. I still think units when printed need more spacing between terms.
>>>    The units term seems cramped
>>>
>>>
>> What do think would look better?
>>
>>>
>>>    1. Is there a general rule for how plural vs. non-plural unit names
>>>    are handled by quantities? I ask because f = Quantity(1, 'feet') works but
>>>    the UnitQuantity feet is not defined (so q = 1* feet does not work). It
>>>    might be useful to mention how this works in the tutorial as this seems like
>>>    the sort of thing that could frustrate new users. Alternatively, Quantities
>>>    could define a bunch of common plural units, but this seems like a lot of
>>>    extra variables.
>>>
>>> Yeah, it is maybe a bit confusing. I'll add a note in the documentation
>> that plural variants for unit names are only available through strings for
>> now. If there is a big demand for plural variants, they can be added later.
>>
>>
>>> Can you tell me which numpy mailing list you will be posting to? I would
>>> like to sign up so I can listen to the discussion.
>>>
>>
>> There is only the one list- numpy-discussion
>>
>>
>>> Have you thought about what you want to do with ufuncs?
>>>
>>
>> ugh. We can't use __array_wrap__ because ufuncs do not provide an
>> analogous hook for preprocessing input, only post-processing. Also, numpy
>> segfaults when it is passed an ndarray subclass with out=None. I reported it
>> to the numpy maililng list but didn't get a response.
>>
>> I think we need a more elegant way to handle ufuncs, using wrappers like
>> is done in ma. There is a lot of repetitive stuff that needs to be done. For
>> example, we need to make sure that if out is used, we are not attempting an
>> operation that modifies the units in place unless out owns its own data.
>> Also, passing magnitudes to the ufunc, or short-circuiting to the
>> numpy.ufunc if quantities are not passed could be handled by wrapper code.
>>
>> I dont think its too important to address these remaining ufunc issues
>> before requesting comments. Although, I think we need to implement
>> concatenate and sqrt.
>>
>> One further thought: is there an easy way to generate a list of all the
>>> units and constants with descriptions in the documentation? If so, I think
>>> it would be useful to have on the doc page.
>>>
>>
>> That would be useful. I'm not sure, I'll have to look into it.
>>
>> I noticed today that running setup.py install was doing an egg install on
>> my computer at work, and that eric4 was not able to run scripts because of
>> some issue with the egg. The scripts ran fine from the shell. I'm so sick of
>> all the subtle problems associated with setuptools, and with setuptools lack
>> of maintainance. Before making an announcement I'm going to remove support
>> for setuptools and add support to run the tests the same way numpy and scipy
>> does it.
>>
>> Darren
>>
>>
>>> Best Regards,
>>> John
>>>
>>>  On Mon, Feb 9, 2009 at 12:41 PM, Darren Dale <dsdale24@xxxxxxxxx>wrote:
>>>
>>>> I added support for customizable default units today. Yesterday I did a
>>>> bit of work to use numpy's sphinx extensions so we can pass through numpy's
>>>> docstrings and document the API with sphinx, I changed the documentation
>>>> decorator a little bit, extended the tutorial, implemented the regular
>>>> expression to properly convert integer powers to unicode superscript
>>>> characters, squashed a bunch of bugs, and there are some other improvements
>>>> I'm forgetting at the moment. I posted some new snapshots at
>>>> packages.python.org/quantities, please give them a try and let me know
>>>> if you find any problems.
>>>>
>>>> I would like to post a request for comment at numpy discussion in the
>>>> next couple of days. I dont think I'm going to make any more changes to the
>>>> codebase for now, and I'm not planning to tag any new releases, but I need
>>>> to put a page together discussing how the package is designed. When thats
>>>> done, and the snapshots have seen some use, I'll make an announcement on the
>>>> numpy mailing list, hopefully next monday.
>>>>
>>>> Darren
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~python-quantities-developers<https://launchpad.net/%7Epython-quantities-developers>
>>>> Post to     : python-quantities-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~python-quantities-developers<https://launchpad.net/%7Epython-quantities-developers>
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>