Re: python -m pip install and pip install
On Fri, Oct 11, 2019 at 3:37 PM אורי wrote: > > When you upgrade pip, you have to write: > > python -m pip install --upgrade pip > > When you install or upgrade anything else, you can write "pip install". > > You can't upgrade pip using "pip install --upgrade pip". > Only a consideration on Windows. Other platforms are absolutely fine upgrading pip either way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python -m pip install and pip install
When you upgrade pip, you have to write: python -m pip install --upgrade pip When you install or upgrade anything else, you can write "pip install". You can't upgrade pip using "pip install --upgrade pip". אורי u...@speedy.net On Mon, Oct 7, 2019 at 2:21 PM Hongyi Zhao wrote: > Hi, > > What's the diff: > > python -m pip install mod > and > pip install mod > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: python -m pip install and pip install
Michael Torrie writes: > On 10/10/19 1:21 AM, Pankaj Jangid wrote: >> So the scripts will just work fine if you simply use ~import pip~ >> and work with it. >> >> Suppose you were writing bash scripts around python programs. Then >> what will be the behaviour of, >> >> pip2 install mod >> >> under a python3 environment. > > If Python 2 wasn't installed, pip2 wouldn't be found at all. If Python 2 > was available, it would happily install mod under the default/current > Python 2 environment. > I am talking about environments where both python2 and python3 installed. >> Similarly, there may be other commands specific to python2 and >> python3. All of them work flawlessly if you just replace python2 with >> python3. > > Not sure what you're getting at there. I am just trying to think about scenarios where one approach is better than other. Nothing more. -- Pankaj Jangid -- https://mail.python.org/mailman/listinfo/python-list
Re: question about making an App for Android
On Fri, Oct 11, 2019 at 10:40 AM pyotr filipivich wrote:
>
> Chris Angelico on Fri, 11 Oct 2019 09:49:03 +1100
> typed in comp.lang.python the following:
> >On Fri, Oct 11, 2019 at 9:41 AM Dennis Lee Bieber
> >wrote:
> >>
> >> On Thu, 10 Oct 2019 08:47:07 -0700, pyotr filipivich
> >> declaimed the following:
> >> >"A simple program" to divide the amount of "today's" daylight into 12
> >> >even '"hours", so that Dawn begins the First hour, the third hour is
> >> >mid-morning, noon is the middle of the day, the ninth hour mid after
> >> >noon, and the twelfth hour ends at sunset. Is simple, no? {no.}
> >> >
> >> Even ignoring "phone" this is anything but simple. It relies upon
> >> knowing one's latitude and date to allow computing the angle of the sun.
> >> And you'll need to handle the fact that above/below arctic/antarctic
> >> circles you will run into "zeros" where there is either 24 hours of
> >> daylight or 24 hours of night.
> >>
> >
> >Or maybe it's really simple, because there's an HTTP API that
> >gives you the information. There's an API for everything these days. A
> >quick web search showed up this:
> >
> >https://sunrise-sunset.org/api
>
> Thanks.
> >
> >Which means the project is a matter of taking the data and formatting
> >it. (Also probably getting lat/long from the phone's location API.)
> >I'd say this is a good-fun project - a one-week project for a student,
> >a weekend project for an expert. And yes, there WILL be edge cases to
> >deal with, but for the most part, it shouldn't be too hard.
>
> A one week project for a student. or Longer for a non-student.
>
> Oh well, as I say a lot: this wild be easy if I was doing it forty
> hours a week. And this part is a spin off of a larger mess, trying to
> understand how astronomy was done before the invention of mechanical
> clocks. I get some off the wall inspirations.
Sure, you can gauge your own skill level to get some idea of an actual
timeframe.
I'd recommend starting with a simple non-phone version of the idea,
and then think about porting it to a phone. That should reduce the
problem's complexity significantly.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: question about making an App for Android
Chris Angelico on Fri, 11 Oct 2019 09:49:03 +1100
typed in comp.lang.python the following:
>On Fri, Oct 11, 2019 at 9:41 AM Dennis Lee Bieber
>wrote:
>>
>> On Thu, 10 Oct 2019 08:47:07 -0700, pyotr filipivich
>> declaimed the following:
>> >"A simple program" to divide the amount of "today's" daylight into 12
>> >even '"hours", so that Dawn begins the First hour, the third hour is
>> >mid-morning, noon is the middle of the day, the ninth hour mid after
>> >noon, and the twelfth hour ends at sunset. Is simple, no? {no.}
>> >
>> Even ignoring "phone" this is anything but simple. It relies upon
>> knowing one's latitude and date to allow computing the angle of the sun.
>> And you'll need to handle the fact that above/below arctic/antarctic
>> circles you will run into "zeros" where there is either 24 hours of
>> daylight or 24 hours of night.
>>
>
>Or maybe it's really simple, because there's an HTTP API that
>gives you the information. There's an API for everything these days. A
>quick web search showed up this:
>
>https://sunrise-sunset.org/api
Thanks.
>
>Which means the project is a matter of taking the data and formatting
>it. (Also probably getting lat/long from the phone's location API.)
>I'd say this is a good-fun project - a one-week project for a student,
>a weekend project for an expert. And yes, there WILL be edge cases to
>deal with, but for the most part, it shouldn't be too hard.
A one week project for a student. or Longer for a non-student.
Oh well, as I say a lot: this wild be easy if I was doing it forty
hours a week. And this part is a spin off of a larger mess, trying to
understand how astronomy was done before the invention of mechanical
clocks. I get some off the wall inspirations.
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?
--
https://mail.python.org/mailman/listinfo/python-list
Re: question about making an App for Android
Dennis Lee Bieber on Thu, 10 Oct 2019 18:39:55
-0400 typed in comp.lang.python the following:
>On Thu, 10 Oct 2019 08:47:07 -0700, pyotr filipivich
>declaimed the following:
>
>
>>"A simple program" to divide the amount of "today's" daylight into 12
>>even '"hours", so that Dawn begins the First hour, the third hour is
>>mid-morning, noon is the middle of the day, the ninth hour mid after
>>noon, and the twelfth hour ends at sunset. Is simple, no? {no.}
>>
> Even ignoring "phone" this is anything but simple.
Which is why it was in quote marks. Yes, it is a simple concept,
it is the bloody implementation which gets complex.
> It relies upon
>knowing one's latitude and date to allow computing the angle of the sun.
>And you'll need to handle the fact that above/below arctic/antarctic
>circles you will run into "zeros" where there is either 24 hours of
>daylight or 24 hours of night.
I figure to initially set it for 48 degrees north, which will be
close enough for my purposes.
>
> Properly speaking, "transit" (noon) may NOT be midway between rising
>and setting.
>
>Astronomical Formulae for Calculators (4th Ed, Jean Meeus, 1988
>Willmann-Bell)
> Chapter 21 Equation of Time
> Chapter 41 Ephemeris for Physical Observations of the Sun
> Chapter 42 Rising, Transit, and Setting
>
>Astronomy With Your Personal Computer (2nd Ed, Petter Duffett-Smith, 1990
>Cambridge University Press) (Chapters are named by BASIC subroutine)
> RISET for rising and setting time
> SUN (maybe of use)
> SUNRS for civil time sunrise/sunset, along with beginning/end of
>civil, nautical, and astronomical twilight.
>
>Practical Astronomy with your Calculator or Spreadsheet (4th Ed, P.
>Duffett-Smith & J. Zwart, 1989 Cambridge University Press)
> Chapter 49 Sunrise and Sunset
> Chapter 50 Twilight
> Chapter 41 The Equation of Time
>
>
> The phone GPS services, if available, may provide the local latitude to
>the application.
>
>>But getting from the development environment (the desktop) to the
>>phone is something I am clueless about.
>>
>
> Getting anything that is not written in Java onto an Android phone is
>likely going to be a pain. You will most likely need an environment that
>runs on ARM architecture. And I have no idea what iOS requires.
Thanks. Not necessarily what I wanted to hear, but what I did
need to hear.
--
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?
--
https://mail.python.org/mailman/listinfo/python-list
Re: question about making an App for Android
On Fri, Oct 11, 2019 at 9:41 AM Dennis Lee Bieber wrote:
>
> On Thu, 10 Oct 2019 08:47:07 -0700, pyotr filipivich
> declaimed the following:
>
>
> >"A simple program" to divide the amount of "today's" daylight into 12
> >even '"hours", so that Dawn begins the First hour, the third hour is
> >mid-morning, noon is the middle of the day, the ninth hour mid after
> >noon, and the twelfth hour ends at sunset. Is simple, no? {no.}
> >
> Even ignoring "phone" this is anything but simple. It relies upon
> knowing one's latitude and date to allow computing the angle of the sun.
> And you'll need to handle the fact that above/below arctic/antarctic
> circles you will run into "zeros" where there is either 24 hours of
> daylight or 24 hours of night.
>
Or maybe it's really simple, because there's an HTTP API that
gives you the information. There's an API for everything these days. A
quick web search showed up this:
https://sunrise-sunset.org/api
Which means the project is a matter of taking the data and formatting
it. (Also probably getting lat/long from the phone's location API.)
I'd say this is a good-fun project - a one-week project for a student,
a weekend project for an expert. And yes, there WILL be edge cases to
deal with, but for the most part, it shouldn't be too hard.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: python -m pip install and pip install
On 10/10/19 1:21 AM, Pankaj Jangid wrote: > So the scripts will just work fine if you simply use ~import pip~ > and work with it. > > Suppose you were writing bash scripts around python programs. Then > what will be the behaviour of, > > pip2 install mod > > under a python3 environment. If Python 2 wasn't installed, pip2 wouldn't be found at all. If Python 2 was available, it would happily install mod under the default/current Python 2 environment. > Similarly, there may be other commands specific to python2 and > python3. All of them work flawlessly if you just replace python2 with > python3. Not sure what you're getting at there. -- https://mail.python.org/mailman/listinfo/python-list
Re: question about making an App for Android
On 10/10/19 9:47 AM, pyotr filipivich wrote:
> What I want is a "simple" program to calculate and display the
> "natural time", and do so on my phone.
>
> "A simple program" to divide the amount of "today's" daylight into 12
> even '"hours", so that Dawn begins the First hour, the third hour is
> mid-morning, noon is the middle of the day, the ninth hour mid after
> noon, and the twelfth hour ends at sunset. Is simple, no? {no.}
>
> But getting from the development environment (the desktop) to the
> phone is something I am clueless about.
>
> Any clues on the matter?
As much as I like Python, it's probably easiest nor the best choice to
make a simple app like this with a hybrid development toolkit. For
example, the Qt5-based system called VPlay. Your app would be a simple
UI file and a tiny bit of javascript to do the calculations.
In the Python world, there's a project called Kivy that lets you build
mobile Python-based applications.
--
https://mail.python.org/mailman/listinfo/python-list
Re: question about making an App for Android
On 10/10/2019 11:47 AM, pyotr filipivich wrote:
What I want is a "simple" program to calculate and display the
"natural time", and do so on my phone.
"A simple program" to divide the amount of "today's" daylight into 12
even '"hours", so that Dawn begins the First hour, the third hour is
mid-morning, noon is the middle of the day, the ninth hour mid after
noon, and the twelfth hour ends at sunset. Is simple, no? {no.}
But getting from the development environment (the desktop) to the
phone is something I am clueless about.
Any clues on the matter?
Search "python android app" with Google.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
question about making an App for Android
What I want is a "simple" program to calculate and display the
"natural time", and do so on my phone.
"A simple program" to divide the amount of "today's" daylight into 12
even '"hours", so that Dawn begins the First hour, the third hour is
mid-morning, noon is the middle of the day, the ninth hour mid after
noon, and the twelfth hour ends at sunset. Is simple, no? {no.}
But getting from the development environment (the desktop) to the
phone is something I am clueless about.
Any clues on the matter?
tschus
pyotr
--
APL is a mistake, carried through to perfection. It is the language of the
future for the programming techniques of the past: it creates a new generation
of coding bums.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
--
https://mail.python.org/mailman/listinfo/python-list
Re: python -m pip install and pip install
Hongyi Zhao writes: > Hongyi Zhao 于2019年10月8日周二 下午4:53写道： >> >> Cameron Simpson 于2019年10月8日周二 下午12:25写道： >> > >> > On 08Oct2019 02:49, Hongyi Zhao wrote: >> > >On Tue, 08 Oct 2019 06:28:05 +0530, Pankaj Jangid wrote: >> > >> A very good use-case is when you have both, python2 and python3 >> > >> installed. >> > >> python2 -m pip install mod >> > >> python3 -m pip install mod >> > >> will install the package in the corresponding PYTHONPATH. >> > >> >> > > >> > >If so, why not just: >> > >pip2 install mod >> > >and using: >> > >pip3 install mod >> > >> > Because of the slight disconnect between "pip2" and "python2", etc. Do >> > you _know_ they both use the same Python install? With "pythonX -m pip" >> > you're using the same python executable which will be accessing what you >> > just installed. >> >> I use pyenv + pip, which will do the trick. > > And nowadays, the pyenv + vurtualenv + pip + pipenv is the suggested > env management method for python. > In this way, the pipenv will solve the version dependence of the > underlying tool chain and corresponding used packages/modules. > Exactly. So the scripts will just work fine if you simply use ~import pip~ and work with it. Suppose you were writing bash scripts around python programs. Then what will be the behaviour of, pip2 install mod under a python3 environment. Similarly, there may be other commands specific to python2 and python3. All of them work flawlessly if you just replace python2 with python3. -- Regards, Pankaj Jangid -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious about library inclusion
About including piped iterators: http://code.activestate.com/recipes/580625-collection-pipeline-in-python/ On 10/10/19 13:00, Paul Moore wrote: > As another measure, look at various other libraries on PyPI and ask > yourself why *this* library needs to be in the stdlib more than those > others. The answer to that question would be a good start for an > argument to include the library. Well my answer would be that this library wouldn't add functionality but rather would allow IMO for a more readable coding style. If you split the work to be done over mulitple generators I find it easier to understand when I read something like: for item in some_file | gen1 | gen2 | gen3: ... than when I read something like: for item in gen3(gen2(gen1(somefile))): ... or than when I have to include the work in the for suite for line in somefile: tmp1 = fun1(line) tmp2 = fun2(tmp1) item = fun3(tmp2) ... or for line in somefile: item = fun3(fun2(fun1(line))) I also would include these in the itertools module instead of adding an extra module. -- Antoon. -- https://mail.python.org/mailman/listinfo/python-list
Re: Curious about library inclusion
Probably low. There would need to be a clear justification as to why
having the library in the stdlib (and hence tied to Python's release
schedule for updates/bug fixes etc - which is typically a really
severe limitation for a newish library) would be better than having it
available as a 3rd party library on PyPI. It would also mean that it
would only be available in Python 3.9+, unless a parallel backport
module was maintained on PyPI, making the argument for inclusion in
the stdlib even weaker.
Basically, someone needs to explain the benefits of having *this*
library in the stdlib, and demonstrate that they are compelling.
(Generic arguments like "being in the stdlib means no need for a 3rd
party dependency" don't count because they would apply to any library
on PyPI equally...) That's a pretty high bar to reach. Not impossible,
by any means, but it needs a lot more than "this is a neat library".
As another measure, look at various other libraries on PyPI and ask
yourself why *this* library needs to be in the stdlib more than those
others. The answer to that question would be a good start for an
argument to include the library.
Paul
On Thu, 10 Oct 2019 at 11:37, Antoon Pardon wrote:
>
> That seems to have been thoruoghly garbled so I start again.
>
> I was wondering how likely it would be that piped iterators like shown
> in http://code.activestate.com/recipes/580625-collection-pipeline-in-python/
> would make it into a future python version/ Once I started using them
> (and included some more) I found I really liked using them. For instance
> I used to write the following a lot: for line in some_file: line =
> line.strip() lst = line.split(':') do_stuff(lst) Now I seem to drift
> into writing: for lst in some_file | Strip | Split(':'): do_stuff(lst)
> where Strip and Split are defined as follows: Strip =
> Map(methodcaller('strip')) def Split(st): return
> Map(methodcaller('split', st)) I also found that Apply can be used as a
> decorator, that easily turns a generator into a piped version. So what
> are the odds? -- Antoon.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Curious about library inclusion
That seems to have been thoruoghly garbled so I start again.
I was wondering how likely it would be that piped iterators like shown
in http://code.activestate.com/recipes/580625-collection-pipeline-in-python/
would make it into a future python version/ Once I started using them
(and included some more) I found I really liked using them. For instance
I used to write the following a lot: for line in some_file: line =
line.strip() lst = line.split(':') do_stuff(lst) Now I seem to drift
into writing: for lst in some_file | Strip | Split(':'): do_stuff(lst)
where Strip and Split are defined as follows: Strip =
Map(methodcaller('strip')) def Split(st): return
Map(methodcaller('split', st)) I also found that Apply can be used as a
decorator, that easily turns a generator into a piped version. So what
are the odds? -- Antoon.
--
https://mail.python.org/mailman/listinfo/python-list
Curious about library inclusion
I was wondering how likely it would be that piped-iterators like shown in
http://code.activestate.com/recipes/580625-collection-pipeline-in-python/
would make it into a future python version. Once I started using them
(and included some more) I found I really liked working with them. For
instance I used to write the following a lot: for line in some_file: lst
= line.strip().split(':') do_stuff(lst) Now I seem to drift into
writing: for lst in some_file | Strip | Split(':'): do_stuff(lst) Where
Strip and Split are defined as follows:
Strip = Map(methodcaller('strip')) def Split(st): return
Map(methodcaller('split', st)) I also found that Apply can be used as a
decorator, that easily turns an iterator into a piped version. So what
are the odds? -- Antoon.
--
https://mail.python.org/mailman/listinfo/python-list
Re: decorator needs access to variables where it is used.
On 9/10/19 13:02, Chris Angelico wrote: > On Wed, Oct 9, 2019 at 9:53 PM Antoon Pardon wrote: >> I have some logging utilities so that when I write library code, I just use >> the following. >> >> from logutil import Logger >> >> log = Logger(__name__) > Are you always absolutely consistent with this? Do you always have it > as a module-level variable and always called "log", and you never use > the name "log" for anything else? (Namespaced usage like "math.log" is > fine, but you never have a function-local "log" or anything.) I have been up to now, but I will take this under consideration when thinking about how to proceed. >> And from then on I just use log, to do the logging of that module. >> >> But now I would like to write a decorator trace, so that a decorated >> function would log, its arguments and result. >> >> Something like: >> >> def trace(func): >> >> def wrapper(*args): >> log(DEBUG, "=> %s%s" % (func.__name__, args)) >> result = func(*args) >> log(DEBUG, "%s => %s" (func.__name__, result)) >> >> return wrapper >> >> The problem is that with this decorater, the log function >> used, will be the log function defined where the decorator >> is written and I would prefer it to use the log function >> where it is used, so that it uses the same log function >> as the function it decorates. >> > The decorator has full access to the function object, including a > reference to that function's module globals. > > def trace(func): > log = func.__globals__["log"] > ... proceed as before > > As long as you can depend on "log" always being a module-level > (global) name, and not (for instance) a closure variable, this should > work. It's a bit ugly, but it should be fine since it's buried away in > the decorator. Nice idea, I can work with that. Antoon. -- https://mail.python.org/mailman/listinfo/python-list
