[Python-ideas] Geo coordinates conversion in stdlib

[anatoly techtonik]

On Mon, Mar 23, 2015 at 11:29 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

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

The fact that thousands of people are asking question on SO about datetime
is the main indicator that the module fails usability check. If it passed,
there was no need to ask stuff. If docs were good, the rate of question was
much lower.

And when I say about top 10 modules that need a redesign, it is not
abstract.

http://sayspy.blogspot.com/2009/07/informal-poll-what-python-stdlib.html

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


Actually, these people are journalists and we'd like to teach them some
Python scripting. If regexps and file reading operations are there, it is
still a problem to do an interesting case without installing a lot of
stuff, meaning that they are not using Python, but some Python
distribution. Maybe you're right - every type Python user should have a
specialized Python distribution like Anaconda or WinPython, but the most
basic entrypoint should be in stdlib.

There should be evolution in learning, going from math -> SciPy, urlib2 ->
requests, etc. The Python should come with toys for most major uses of
scripting languages in modern world. It is already long past only "computer
science" stuff.


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


Well, maybe it is only my impression, but I haven't seen any wide used user
level app recently written in Python, and there is a plenty of tools
written in Go for the areas that were once Python domain - system tools.
Docker, LXD, Syncthing - these are the tools that I actually use almost
daily, and I am looking at https://github.com/limetext/lime right now for
some reason.

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


Yes, and that's sad that the Python still doesn't have the basic building
blocks of Pandas in stdlib. It is the proven de-facto popularity
achievement that is required for packages to enter stdlib, but that still
doesn't happen. Looks like the granularity of package is not sufficient for
designing next stdlib - the need is to descent into the level of structures.


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


There are indeed a lot of proliferation in geo standards, but for the basis
stuff I trust the Wikipedia choice, because the practicality beats purity.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150327/f28a08f8/attachment-0001.html>