[Python-ideas] Geo coordinates conversion in stdlib

[Andrew Barnert]

On Mar 22, 2015, at 11:08 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> 
> On Mon, Mar 23, 2015 at 1:37 AM, Andrew Barnert
> <abarnert at yahoo.com.dmarc.invalid> wrote:
>> On Mar 22, 2015, at 2:38 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> 
>>> On Sun, 22 Mar 2015 17:15:39 -0400
>>> Alexander Walters
>>> <tritium-list at sdamon.com> wrote:
>>>>> On 3/21/2015 05:46, anatoly techtonik wrote:
>>>>> I think it should be in stdlib.
>>>>> 
>>>>> 11° 18′ 0″ S, 2° 42′ 0″ E   to  -11.3, 2.7  and back.
>>>>> 
>>>>> This is from Wikipedia.
>>>> Why does this need to be in the standard library?
>>> 
>>> Because Anatoly needs it, of course :)
>> 
>> Well, it would certainly be nice to have all of Wikipedia in the stdlib, but I wonder how that would affect Python's release schedule, and its use in resource-constrained systems.
>> 
>> More seriously, if you're just looking to convert arcminutes and arcseconds to and from fractional degrees, it's exactly the same algorithm as converting minutes and seconds to fractional hours, which we already have in the datetime.timedelta class. If you can't figure out the complexity of multiplying and divmodding by 60 twice, you can borrow its code, or just wrap it and delegate. That seems trivial enough to do in any project that needs it. And that means projects that want degrees-arcminutes-arcseconds-milliarcseconds (e.g., for astronomy) or just degrees and fractional arcminutes with no arcseconds (e.g., for marine navigation) or degrees, arcminutes, and eighth-arcminutes (e.g., for US military scopes) can just as easily get what they need, instead of being forced to use the variation surveyors prefer.
> 
> That's nice to know, but IIRC datetime is from the top 10 Python
> modules that need a redesign. Things contained therein doesn't pass
> human usability check, and are not used as a result.

There are thousands of projects that actually do use it; thousands of people asking questions on StackOverflow, Python-tutor, etc. and getting actual answers; etc. So your theoretical argument that it's not usable doesn't really matter given that practically it is actually usable, and used.

If you just opened up an interactive interpreter and player with the datetime.timedelta class for a few seconds instead of trying to guess based on hearsay and abstract principles whether it might be useful, you could have figured this out for yourself.

> My story for that day is that I needed to process geodata from
> Wikipedia to see the distribution over the Earth surface, so I thought
> that if I know the Python it is not a problem. It appeared that the
> problem is there, and the problem is recurring (last time I had GPS
> points).

I suspect that people who do a lot of geodata processing in Python already have third-party libs that they use, and would have no interest in a very small limited subset being duplicated in the stdlib.

> Python docs explain a lot about core OS concepts, but Python
> is not only a systems language. I'd say that it is now being replaced
> with Go for all system stuff,

I don't know anyone outside Google who's using Go for any system (or sysadmin, which seems to be more likely what you're talking about) stuff. I'm sure there are exceptions, but the idea that Python is being universally replaced by Go in that area is so ridiculous that it's hard to believe you actually meant it seriously. It's like saying that Ruby is being replaced by Scala for all web server stuff just because Scala is the fastest-growing language in that area this week.

> and more attempts are made to use is as
> a data processing language. But that is not possible if Python doesn't
> have a basic concepts of data representation from the Real Life (RL)
> (tm) in its stdlib.

Most people I know who use Python as a serious data processing language don't care much what's in the stdlib because they're using numpy and/or pandas.

> Handling geo coordinates in most used formats is as important as
> handling .zip archives in stdlib.

Not even close. Zip archives are used in a ridiculously wide range of application areas; geoccordinates are used only in processing geocoordinate data (and there only in small enough scales that you don't need numpy or some specialized geodata library that I don't know about but that I'll bet exists).