Geo coordinates conversion in stdlib
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. -- anatoly t.
On Sat, Mar 21, 2015 at 8:46 PM, anatoly techtonik <techtonik@gmail.com> 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.
Put some code together, stick it on PyPI... oh, and while you're there, see if someone else has already written it. You never know, it might well be there! ChrisA
On Sun, 22 Mar 2015 17:15:39 -0400 Alexander Walters <tritium-list@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 :) Regards Antoine.
On Mar 22, 2015, at 2:38 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 22 Mar 2015 17:15:39 -0400 Alexander Walters <tritium-list@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.
On Sun, Mar 22, 2015 at 3:37 PM, Andrew Barnert < abarnert@yahoo.com.dmarc.invalid> wrote:
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.
I"m not suggesting this is an stdlib candiate, but it'snot quite that simple. With FP precision issues you can end up with results like: 1° 60′ 13″ which you don't want. I haven't checked to see if datetime deal siwththis corectly but I'd guess it does :-) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Sun, Mar 22, 2015, at 19:13, Chris Barker wrote:
On Sun, Mar 22, 2015 at 3:37 PM, Andrew Barnert < abarnert@yahoo.com.dmarc.invalid> wrote:
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.
I"m not suggesting this is an stdlib candiate, but it'snot quite that simple. With FP precision issues you can end up with results like:
1° 60′ 13″
I'm not sure I believe this is true. Do you have a concrete example of an actual floating point value that will do this?
On Mon, Mar 23, 2015 at 1:37 AM, Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:
On Mar 22, 2015, at 2:38 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 22 Mar 2015 17:15:39 -0400 Alexander Walters <tritium-list@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. 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). 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, 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. Handling geo coordinates in most used formats is as important as handling .zip archives in stdlib. -- anatoly t.
On Mon, Mar 23, 2015 at 5:08 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Handling geo coordinates in most used formats is as important as handling .zip archives in stdlib.
That may or may not be the case, but if it is, the best way to argue the point is: 1) Find or create a third-party package on PyPI 2) Demonstrate that this package has a stable API 3) Demonstrate or pledge support for the package 4) Appeal for the package's inclusion in the stdlib You'll need to show that there's benefit to having it in the stdlib as opposed to on PyPI - demonstrate the problem with "pip install packagename" that means that you want it in the standard library. Just *stating* that there is a need isn't sufficient - you need to prove it. ChrisA
On Mon, Mar 23, 2015 at 10:21 AM, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Mar 23, 2015 at 5:08 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Handling geo coordinates in most used formats is as important as handling .zip archives in stdlib.
That may or may not be the case, but if it is, the best way to argue the point is:
1) Find or create a third-party package on PyPI 2) Demonstrate that this package has a stable API 3) Demonstrate or pledge support for the package 4) Appeal for the package's inclusion in the stdlib
You'll need to show that there's benefit to having it in the stdlib as opposed to on PyPI - demonstrate the problem with "pip install packagename" that means that you want it in the standard library. Just *stating* that there is a need isn't sufficient - you need to prove it.
Why the wave module is there? Or ioctl module? Are they so widely used? This process is flawed. If anybody would sponsor the research on popularity of stdlib, I believe that math will be excluded from top 50 as well. Will stdlib without math will still be ok? The measure to estimate the usefullness of standard library is not in download score, but in coverage across different areas. There thousands of people downloading stuff from youtube, so should we include youtube-dl instead of math? -- anatoly t.
On Sat, Mar 28, 2015 at 12:52 AM, anatoly techtonik <techtonik@gmail.com> wrote:
Why the wave module is there? Or ioctl module? Are they so widely used?
This process is flawed. If anybody would sponsor the research on popularity of stdlib, I believe that math will be excluded from top 50 as well. Will stdlib without math will still be ok?
The measure to estimate the usefullness of standard library is not in download score, but in coverage across different areas. There thousands of people downloading stuff from youtube, so should we include youtube-dl instead of math?
The criteria for the *removal* from the stdlib would be insanely tight, compared to the criteria for *addition*. So some modules might now simply be grandfathered in (I suspect wave is one of them), due to the shift in ease of grabbing stuff off PyPI. But the math module is pretty important and fundamental, so it's not going anywhere. As to youtube-dl, though: Definitely not. No matter how popular it is, it still fails the criterion of release schedule synchronization - it needs to be agile enough to update as often as it needs, according to host site changes, and would be shackled rather badly by inclusion in the stdlib. (You probably don't want to get it from your OS repo either.) But none of this changes the recommendations I made earlier. You need to *demonstrate*, not simply state, a need; and one of the best ways to demonstrate support, API stability, usage, etc, is to stick a package up on PyPI. Not everything needs to be in the stdlib, but if you're going to argue that something should be, what better way than by pointing out what it's already doing? ChrisA
On Fri, Mar 27, 2015 at 5:04 PM, Chris Angelico <rosuav@gmail.com> wrote:
Why the wave module is there? Or ioctl module? Are they so widely used?
This process is flawed. If anybody would sponsor the research on
On Sat, Mar 28, 2015 at 12:52 AM, anatoly techtonik <techtonik@gmail.com> wrote: popularity
of stdlib, I believe that math will be excluded from top 50 as well. Will stdlib without math will still be ok?
The measure to estimate the usefullness of standard library is not in download score, but in coverage across different areas. There thousands of people downloading stuff from youtube, so should we include youtube-dl instead of math?
The criteria for the *removal* from the stdlib would be insanely tight, compared to the criteria for *addition*. So some modules might now simply be grandfathered in (I suspect wave is one of them), due to the shift in ease of grabbing stuff off PyPI. But the math module is pretty important and fundamental, so it's not going anywhere.
As to youtube-dl, though: Definitely not. No matter how popular it is, it still fails the criterion of release schedule synchronization - it needs to be agile enough to update as often as it needs, according to host site changes, and would be shackled rather badly by inclusion in the stdlib. (You probably don't want to get it from your OS repo either.)
But none of this changes the recommendations I made earlier. You need to *demonstrate*, not simply state, a need; and one of the best ways to demonstrate support, API stability, usage, etc, is to stick a package up on PyPI. Not everything needs to be in the stdlib, but if you're going to argue that something should be, what better way than by pointing out what it's already doing?
There is now quite a big lump of data for me that in social systems (such as community developed projects) the reputation is more important than rationale, so how do you imagine a demonstration? Well, I have this: https://en.wikipedia.org/wiki/List_of_solar_eclipses_in_the_21st_century here is the list of all sun eclipses in the World. How would you show them on map to paste into your student paper? You need to import the table into your spreadsheet, then transform coordinates into floats and then export the data for you map drawing tools. The problem - spreadsheets don't convert coordinates. You need a script for that. And that script you will need for much every data processing involving data from Wikipedia. Is that fair enough for demonstration of a need? -- anatoly t.
On Mar 22, 2015, at 11:08 PM, anatoly techtonik <techtonik@gmail.com> wrote:
On Mon, Mar 23, 2015 at 1:37 AM, Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:
On Mar 22, 2015, at 2:38 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 22 Mar 2015 17:15:39 -0400 Alexander Walters <tritium-list@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).
On Mon, Mar 23, 2015 at 11:29 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Mar 22, 2015, at 11:08 PM, anatoly techtonik <techtonik@gmail.com> wrote:
On Mon, Mar 23, 2015 at 1:37 AM, Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:
On Mar 22, 2015, at 2:38 PM, Antoine Pitrou <solipsis@pitrou.net>
On Sun, 22 Mar 2015 17:15:39 -0400 Alexander Walters <tritium-list@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
wrote: 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.
On Mar 29, 2015 6:59 PM, "anatoly techtonik" <techtonik@gmail.com> wrote:
On Mon, Mar 23, 2015 at 11:29 AM, Andrew Barnert <abarnert@yahoo.com>
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
wrote: 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. It isn't just granularity, it is pace of development. Once something is in stdlib, is pretty much impossible to make substantial changes to it. Even if all the other criteria were met, the pace of development of projects like numpy and pandas is far too fast for stdlib. Numpy devs, at least, have explicitly stated they do not want numpy in the stdlib for precisely this reason. "stdlib is where packages go to die". I don't know who originally said that, but it is very true.
On 23/03/2015 06:08, anatoly techtonik wrote:
On Mon, Mar 23, 2015 at 1:37 AM, Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:
On Mar 22, 2015, at 2:38 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 22 Mar 2015 17:15:39 -0400 Alexander Walters <tritium-list@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.
I'm looking forward to seeing your redesign for all 10 modules on the bug tracker. Can you get this done in time for 3.5 beta? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 23.03.2015 07:08, anatoly techtonik wrote:
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). 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, 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.
Well, sorry Anatoly that we haven't already solved all your problems for you ;-) If you are really interested in a solution to your problem, have a look at this large collection of tools for doing GIS in Python: https://pythongisresources.wordpress.com/categories/ More specifically, you're probably looking for one of these packages: https://pythongisresources.wordpress.com/projections-2/ It's all just a pip install away. BTW: If you expect the Python stdlib to make coffee, clean your house and drive your kids to school, you're probably looking at the wrong language - we only do batteries in the stdlib :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 23 2015)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2015-03-12: Released mxODBC 3.3.2 ... http://egenix.com/go71 ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Mon, Mar 23, 2015 at 12:16 PM, M.-A. Lemburg <mal@egenix.com> wrote:
BTW: If you expect the Python stdlib to make coffee, clean your house and drive your kids to school, you're probably looking at the wrong language - we only do batteries in the stdlib :-)
Well, I got your point, it is not about GPS module anymore, it is about inability of community decisions on the stuff that looks like highly subjective and personal. I don't think I can get convincing data for that, because nobody has the money to spend time on that data mining stuff, especially me. So the final argument would need to be extended to do the research on Python usage in non-computer science and system programming world to see if GPS conversion module in standard library provides any value. That means that we need to find the metrics that will be more useful than just a PyPI download index.
I could go on an on about my experience and what problems I solve, but... Nope. that is just flat wrong. Zipfiles are part of the import system, and everyone uses them all the time in python. Coordinate conversion is not a problem I have encountered, and a far as i can tell, not many people will. On 3/23/2015 02:08, anatoly techtonik wrote:
Handling geo coordinates in most used formats is as important as handling .zip archives in stdlib.
participants (11)
-
Alexander Walters -
anatoly techtonik -
Andrew Barnert -
Antoine Pitrou -
Chris Angelico -
Chris Barker -
Greg Ewing -
M.-A. Lemburg -
Mark Lawrence -
random832＠fastmail.us -
Todd