Python aliases under Windows?
Perhaps this is a silly question but still...There is PEP 394 "The "python" Command on Unix-Like Systems" which I find very reasonable, no matter how it is respected. Why was not _somewhat_ the same done for Windows? Sometimes I use, especially in IPython, to run externally: ! python3 -m dis ! python3 -m timeit ... ! python3 -m pip install ... And to make this work the same under Windows, the first step which I do after installation is to copy `python.exe` and rename it to `python3.exe` (for python 2.7 copy `python.exe` and rename it to `python2.exe`). May be there is a better way to do this under Windows, I would like to know? This copy-rename works for me, but it will not work for someone who does not have administrative rights. p.s.: I know there is a `py` launcher under Windows, but is does not help in this situation. With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On Tue, Apr 3, 2018 at 7:24 PM, Kirill Balunov wrote: > Perhaps this is a silly question but still...There is PEP 394 "The "python" > Command on Unix-Like Systems" which I find very reasonable, no matter how > it is respected. Why was not _somewhat_ the same done for Windows? > > Sometimes I use, especially in IPython, to run externally: > ! python3 -m dis > ! python3 -m timeit ... > ! python3 -m pip install ... > > And to make this work the same under Windows, the first step which I do > after installation is to copy `python.exe` and rename it to `python3.exe` > (for python 2.7 copy `python.exe` and rename it to `python2.exe`). May be > there is a better way to do this under Windows, I would like to know? This > copy-rename works for me, but it will not work for someone who does not > have administrative rights. > > p.s.: I know there is a `py` launcher under Windows, but is does not help > in this situation. Why doesn't it? That's what its job is. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
2018-04-03 12:27 GMT+03:00 Chris Angelico : > > Why doesn't it? That's what its job is. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > Because it affects my workflow under Windows and Linux. I have two options: 1. To wriie a shell script for `py` under Linux. 2. To copy-rename to python3 under Windows. Both are easy, but a little bit strange to do. With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On Tue, Apr 3, 2018 at 3:24 AM, Kirill Balunov wrote: > Perhaps this is a silly question but still...There is PEP 394 "The "python" > Command on Unix-Like Systems" which I find very reasonable, no matter how > it is respected. Why was not _somewhat_ the same done for Windows? PEP 394 is meant to provide standardization between distributions of Linux which might make different choices about how to name the python aliases. Windows doesn't have distributions, and PEP 397 was being worked on at about the same time, so I suppose it wasn't considered necessary. Also, Windows and Linux are different enough that standardization between the two environments may not have been considered a realistic goal. > Sometimes I use, especially in IPython, to run externally: > ! python3 -m dis > ! python3 -m timeit ... > ! python3 -m pip install ... > > And to make this work the same under Windows, the first step which I do > after installation is to copy `python.exe` and rename it to `python3.exe` > (for python 2.7 copy `python.exe` and rename it to `python2.exe`). May be > there is a better way to do this under Windows, I would like to know? Creating python2.bat and python3.bat instead would take up less additional disk space and would not need to be modified every time you reinstall a new release of the same minor version. > This > copy-rename works for me, but it will not work for someone who does not > have administrative rights. They could put them under their user folder and add the folder to their path, although that's creeping into power user territory. Then again, they *are* using IPython... > p.s.: I know there is a `py` launcher under Windows, but is does not help > in this situation. I don't understand. Is 'py -3' that much harder to type than 'python3' when running in Windows? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On 3 April 2018 at 10:24, Kirill Balunov wrote:
> Perhaps this is a silly question but still...There is PEP 394 "The "python"
> Command on Unix-Like Systems" which I find very reasonable, no matter how
> it is respected. Why was not _somewhat_ the same done for Windows?
History, mainly. Plus the fact that the Unix convention is *not* that
reasonable. Why should a system with only Python 3 installed (very
common on Windows) not use "python" for that interpreter? The
requirement that "python" must always refer to Python 2 comes from
historical constraints on how Linux distributions chose to write their
system scripts, AIUI.
But debating why things are the way they are isn't that productive.
It's the reality, so we need to deal with it.
> p.s.: I know there is a `py` launcher under Windows, but is does not help
> in this situation.
Could you not use an alias?
In [1]: import sys
...: if sys.platform.startswith('win'):
...: %alias python3 py -3
...: else:
...: %alias python3 python3
...:
...: ver = %python3 --version
...: ver
...:
Python 3.6.2
Paul
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
2018-04-03 16:15 GMT+03:00 Ian Kelly : > Creating python2.bat and python3.bat instead would take up less > additional disk space and would not need to be modified every time you > reinstall a new release of the same minor version. > > Thank you! > > This > > copy-rename works for me, but it will not work for someone who does not > > have administrative rights. > > They could put them under their user folder and add the folder to > their path, although that's creeping into power user territory. Then > again, they *are* using IPython... > > > p.s.: I know there is a `py` launcher under Windows, but is does not help > > in this situation. > > I don't understand. Is 'py -3' that much harder to type than 'python3' > when running in Windows? > IPython is only one of the examples, instead you can substitute Jupyter, subprocess. As I wrote before: > I have two options: > 1. To wriie a shell script for `py` under Linux. > 2. To copy-rename to python3 under Windows. > Both are easy, but a little bit strange to do. > which seems unnecessary. There is already `pip.exe`, `pip3.exe`, `pip3.6.exe` in Scripts sub-folder which in my opinion solve the same problem. With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
2018-04-03 16:45 GMT+03:00 Paul Moore :
> On 3 April 2018 at 10:24, Kirill Balunov wrote:
> > Perhaps this is a silly question but still...There is PEP 394 "The
> "python"
> > Command on Unix-Like Systems" which I find very reasonable, no matter how
> > it is respected. Why was not _somewhat_ the same done for Windows?
>
> History, mainly. Plus the fact that the Unix convention is *not* that
> reasonable. Why should a system with only Python 3 installed (very
> common on Windows) not use "python" for that interpreter? The
> requirement that "python" must always refer to Python 2 comes from
> historical constraints on how Linux distributions chose to write their
> system scripts, AIUI.
>
I understand that general rules are not possible among the various OSs. If
just `python` suits for Windows it is OK. But I have the same question, why
should a system with Python 3 installed not use both "python" and "python3"
for that interpreter? This `python3` will allow to slightly unify the
workflow on different OSs, while it will be done almost for free. I want to
add that there are plenty of tutorials which use `python3 ...` without
reference to UNIX world, why are these mental overhead with `python3` or
`py -3` necessary?
In fact, I do not really understand why the _py launcher_ way is easier or
better than `python3` or `python3.6` way even on Windows. There are already
`pip.exe`, `pip3.exe`, `pip3.6.exe` which solve the same problem, but they
are all redundant, when it is better to use `python3.6 -m pip ... ` or
currently `py -3.6 -m pip install ...`.
But debating why things are the way they are isn't that productive.
> It's the reality, so we need to deal with it.
>
> > p.s.: I know there is a `py` launcher under Windows, but is does not help
> > in this situation.
>
> Could you not use an alias?
>
> In [1]: import sys
>...: if sys.platform.startswith('win'):
>...: %alias python3 py -3
>...: else:
>...: %alias python3 python3
>...:
>...: ver = %python3 --version
>...: ver
>...:
> Python 3.6.2
Thank you this works for me!
With kind regards,
-gdg
--
https://mail.python.org/mailman/listinfo/python-list
logging.FileHandler diff Py2 v Py3
I've encountered a problem in an application I'm porting from Python
2.7 to 3.6. The logginng.FileHandler class likes "/dev/stderr" as a
destination in Python 2, but complains in Python 3.
Python 2.7.14:
>>> import logging
>>> logging.FileHandler("/dev/stderr")
Python 3.6.4:
>>> import logging
>>> logging.FileHandler("/dev/stderr")
Traceback (most recent call last):
File "", line 1, in
File "/home/skip/miniconda3/envs/python3/lib/python3.6/logging/__init__.py",
line 1030, in __init__
StreamHandler.__init__(self, self._open())
File "/home/skip/miniconda3/envs/python3/lib/python3.6/logging/__init__.py",
line 1059, in _open
return open(self.baseFilename, self.mode, encoding=self.encoding)
OSError: [Errno 29] Illegal seek
I can see how to work around the error, pass mode="w" when passing
/dev/{stdout,stderr} to the constructor. Shouldn't that bit of
ugliness be hidden in the logging module?
Skip
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On Tue, Apr 3, 2018 at 9:00 AM, Kirill Balunov wrote: > In fact, I do not really understand why the _py launcher_ way is easier or > better than `python3` or `python3.6` way even on Windows. There are already > `pip.exe`, `pip3.exe`, `pip3.6.exe` which solve the same problem, but they > are all redundant, when it is better to use `python3.6 -m pip ... ` or > currently `py -3.6 -m pip install ...`. Because py.exe is really meant to solve a slightly different problem. On Unix if you have a .py script and you run it directly, without specifying which interpreter to use, the convention is to start the script with a shebang line, and the kernel will transparently use the interpreter specified there. Windows, however, doesn't respect shebang lines and instead associates programs with files by file extension. Here's the problem: Python 2 files have a .py extension. Python 3 files also have a .py extension. Windows doesn't allow both Python binaries to be associated with the same extension. So how can we set things up so that launching a Python file will invoke the correct Python version? To solve this, Python ships with py.exe and associates *that* with the .py extension. py.exe knows what Python versions are installed, and it inspects the shebang line to decide which one to run for this particular script. The fact that py.exe can also intelligently select versions from command line arguments is just an added bonus. -- https://mail.python.org/mailman/listinfo/python-list
Re: semicolon at end of python's statements
On 04/01/2018 11:31 PM, [email protected] wrote: El miércoles, 28 de agosto de 2013, 21:18:26 (UTC-3), Mohsen Pahlevanzadeh escribió: Dear all, I'm C++ programmer and unfortunately put semicolon at end of my statements in python. Quesion: What's really defferences between putting semicolon and don't put? Yours, Mohsen Well, if you have to program in both c and python, and switch between them on intervals of time lowers than some hours I would suggest keep on with the semicolons at the end of lines... It would be very difficult to lose that habit, and while it is inoffensive on python, it may cause some troubles on c. I don't know. It's not Pep 8, or at least pycharm complains about it. I'd hate to inherit the semicolon riddled code. I switch between python and PHP twenty or so times a day since we use both at work. Once in a while I throw in a rogue semicolon, but it's not often enough to cause a bother. -- https://mail.python.org/mailman/listinfo/python-list
Re: semicolon at end of python's statements
Semicolon is optional. If you put a semicolon at the end of the of a statement, you can keep writing statements. a=3;b=2 -- https://mail.python.org/mailman/listinfo/python-list
Re: logging.FileHandler diff Py2 v Py3
Skip Montanaro wrote:
> I've encountered a problem in an application I'm porting from Python
> 2.7 to 3.6. The logginng.FileHandler class likes "/dev/stderr" as a
> destination in Python 2, but complains in Python 3.
>
> Python 2.7.14:
>
import logging
logging.FileHandler("/dev/stderr")
>
>
> Python 3.6.4:
>
import logging
logging.FileHandler("/dev/stderr")
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/skip/miniconda3/envs/python3/lib/python3.6/logging/__init__.py",
> line 1030, in __init__
> StreamHandler.__init__(self, self._open())
> File
> "/home/skip/miniconda3/envs/python3/lib/python3.6/logging/__init__.py",
> line 1059, in _open
> return open(self.baseFilename, self.mode, encoding=self.encoding)
> OSError: [Errno 29] Illegal seek
>
> I can see how to work around the error, pass mode="w" when passing
> /dev/{stdout,stderr} to the constructor. Shouldn't that bit of
> ugliness be hidden in the logging module?
I think the culprit is io.open() rather than the logging module. Why does
>>> io.open("/dev/stderr", "a")
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 29] Illegal seek
even try to seek()?
--
https://mail.python.org/mailman/listinfo/python-list
Re: logging.FileHandler diff Py2 v Py3
On 3 April 2018 at 17:54, Peter Otten <[email protected]> wrote: > I think the culprit is io.open() rather than the logging module. Why does > io.open("/dev/stderr", "a") > Traceback (most recent call last): > File "", line 1, in > OSError: [Errno 29] Illegal seek > > even try to seek()? Because it's append mode so it needs to go to the end? Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On 4/3/2018 11:43 AM, Ian Kelly wrote: On Tue, Apr 3, 2018 at 9:00 AM, Kirill Balunov wrote: In fact, I do not really understand why the _py launcher_ way is easier or better than `python3` or `python3.6` way even on Windows. There are already `pip.exe`, `pip3.exe`, `pip3.6.exe` which solve the same problem, but they These are put in the pythonxy/Scripts directory. So they only work if the pythonxy/Scripts directory is on the path. But there really should only be 1 such directory on the path. Otherwise, the meaning of pip.exe and pip3.exe depends on the order of the multiple /Scripts directories. are all redundant, when it is better to use `python3.6 -m pip ... ` or currently `py -3.6 -m pip install ...`. Because the last works with multiple python installations. Because py.exe is really meant to solve a slightly different problem. On Unix if you have a .py script and you run it directly, without specifying which interpreter to use, the convention is to start the script with a shebang line, and the kernel will transparently use the interpreter specified there. Windows, however, doesn't respect shebang lines and instead associates programs with files by file extension. Here's the problem: Python 2 files have a .py extension. Python 3 files also have a .py extension. Windows doesn't allow both Python binaries to be associated with the same extension. So how can we set things up so that launching a Python file will invoke the correct Python version? To solve this, Python ships with py.exe and associates *that* with the .py extension. py.exe knows what Python versions are installed, and it inspects the shebang line to decide which one to run for this particular script. The fact that py.exe can also intelligently select versions from command line arguments is just an added bonus. I consider it essential, as I often run scripts with more than one version, so baking a version into the script is wrong. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: semicolon at end of python's statements
On 04/03/2018 09:48 AM, [email protected] wrote: Semicolon is optional. If you put a semicolon at the end of the of a statement, you can keep writing statements. a=3;b=2 PyCharm still complains about two statements on one line and sites Pep 8. I never used to pay much attention to Pep 8, but PyCharm has greatly eroded my resistance. -- https://mail.python.org/mailman/listinfo/python-list
Re: logging.FileHandler diff Py2 v Py3
Paul Moore wrote: > On 3 April 2018 at 17:54, Peter Otten <[email protected]> wrote: >> I think the culprit is io.open() rather than the logging module. Why does >> > io.open("/dev/stderr", "a") >> Traceback (most recent call last): >> File "", line 1, in >> OSError: [Errno 29] Illegal seek >> >> even try to seek()? > > Because it's append mode so it needs to go to the end? I expected that to be handled by the C library, and in C there is no error: $ cat open_stderr_in_appendmode.c #include main() { FILE * stderr = fopen("/dev/stderr", "a"); if (stderr == 0) { printf("failed\n"); } else { printf("succeded\n"); fprintf(stderr, "\nthis goes to stderr\n"); fclose(stderr); } } $ gcc open_stderr_in_appendmode.c $ ./a.out succeded this goes to stderr The same goes for Py2's built-in and codecs.open(): $ python Python 2.7.6 (default, Nov 23 2017, 15:49:48) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import codecs >>> import io >>> with open("/dev/stderr", "a") as f: f.write("works\n") ... works >>> with codecs.open("/dev/stderr", "a") as f: f.write("works\n") ... works >>> with io.open("/dev/stderr", "a") as f: f.write("works\n") ... Traceback (most recent call last): File "", line 1, in IOError: [Errno 29] Illegal seek >>> So io.open() really seems to do its own thing, and differently. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On Tue, Apr 3, 2018 at 3:43 PM, Ian Kelly wrote: > > Because py.exe is really meant to solve a slightly different problem. > On Unix if you have a .py script and you run it directly, without > specifying which interpreter to use, the convention is to start the > script with a shebang line, and the kernel will transparently use the > interpreter specified there. Windows, however, doesn't respect shebang > lines and instead associates programs with files by file extension. > > Here's the problem: Python 2 files have a .py extension. Python 3 > files also have a .py extension. Windows doesn't allow both Python > binaries to be associated with the same extension. So how can we set > things up so that launching a Python file will invoke the correct > Python version? To solve this, Python ships with py.exe and associates > *that* with the .py extension. py.exe knows what Python versions are > installed, and it inspects the shebang line to decide which one to run > for this particular script. > > The fact that py.exe can also intelligently select versions from > command line arguments is just an added bonus. Alternatively, there's the Windows Script Host (WSH) framework (cscript.exe console, wscript.exe GUI), which supports a generic WSF file extension that allows mixing multiple languages in a single script, and integrates with COM, ASP, and native debuggers. PyWin32 supports WSH. This could have been adapted to support Python 3 as a separate Windows scripting engine. That said, for general use, the py launcher's registration+shebang support is more flexible than the WSH registration-only approach. The launcher supports virtual Unix shebangs for cross-platform scripts and arbitrary executable paths for scripts that depend on virtual environments. I use it for the .py[w] file association and creating virtual environments. I still prefer `python` on the command line. Even on Linux I don't frequently use `python3` or `python3.X`. I do very little with the system Python. If you really miss typing "python3.6", I suggest using relative symbolic links (e.g. CMD's `mklink` command) created in the same directory as python[w].exe. Using relative symlinks requires installing Python on a NTFS volume that supports them, so it's not a viable solution for external drives that use FAT32 or exFAT. In the latter case, an alternative to batch scripts is to create a "python[w]3.6.lnk" shell shortcut to "python[w].exe". Leave the "start in" folder empty, so it will inherit the parent's working directory, and add .LNK to the system PATHEXT environment variable. One caveat is that, unlike symlinks or batch scripts, executing shell shortcuts requires ShellExecute[Ex] (called from Explorer, CMD, PowerShell, etc). CreateProcess (e.g. subprocess.Popen with shell=False) doesn't know anything about .LNK files. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
2018-04-03 22:04 GMT+03:00 eryk sun : > On Tue, Apr 3, 2018 at 3:43 PM, Ian Kelly wrote: > > > > Because py.exe is really meant to solve a slightly different problem. > > On Unix if you have a .py script and you run it directly, without > > specifying which interpreter to use, the convention is to start the > > script with a shebang line, and the kernel will transparently use the > > interpreter specified there. Windows, however, doesn't respect shebang > > lines and instead associates programs with files by file extension. > > > > Here's the problem: Python 2 files have a .py extension. Python 3 > > files also have a .py extension. Windows doesn't allow both Python > > binaries to be associated with the same extension. So how can we set > > things up so that launching a Python file will invoke the correct > > Python version? To solve this, Python ships with py.exe and associates > > *that* with the .py extension. py.exe knows what Python versions are > > installed, and it inspects the shebang line to decide which one to run > > for this particular script. > > > > The fact that py.exe can also intelligently select versions from > > command line arguments is just an added bonus. > Thank you Ian, Terry, Eryk! Now I understand the purpose of py launcher in general. I don't have Windows near, will `py -3.6 ...` work if Python36 is not on the Path? If not, it seems to me, that if `python3.exe` and `python3.6.exe` were provided they would be equivalent, and together they will complement together and unify UNIX and Windows workflow. Am I missing something? > Alternatively, there's the Windows Script Host (WSH) framework > (cscript.exe console, wscript.exe GUI), which supports a generic WSF > file extension that allows mixing multiple languages in a single > script, and integrates with COM, ASP, and native debuggers. PyWin32 > supports WSH. This could have been adapted to support Python 3 as a > separate Windows scripting engine. > > That said, for general use, the py launcher's registration+shebang > support is more flexible than the WSH registration-only approach. The > launcher supports virtual Unix shebangs for cross-platform scripts and > arbitrary executable paths for scripts that depend on virtual > environments. I use it for the .py[w] file association and creating > virtual environments. I still prefer `python` on the command line. > Even on Linux I don't frequently use `python3` or `python3.X`. I do > very little with the system Python. > > If you really miss typing "python3.6", I suggest using relative > symbolic links (e.g. CMD's `mklink` command) created in the same > directory as python[w].exe. Using relative symlinks requires > installing Python on a NTFS volume that supports them, so it's not a > viable solution for external drives that use FAT32 or exFAT. In the > latter case, an alternative to batch scripts is to create a > "python[w]3.6.lnk" shell shortcut to "python[w].exe". Leave the "start > in" folder empty, so it will inherit the parent's working directory, > and add .LNK to the system PATHEXT environment variable. One caveat is > that, unlike symlinks or batch scripts, executing shell shortcuts > requires ShellExecute[Ex] (called from Explorer, CMD, PowerShell, > etc). CreateProcess (e.g. subprocess.Popen with shell=False) doesn't > know anything about .LNK files. > -- > https://mail.python.org/mailman/listinfo/python-list > Thank you for your detailed advice, I'll try to understand. Why under Windows everything is so complicated... Concerning dealing with `python` vs `python3` it is a matter of habit, and I find the latter option more reliable and missing it under Windows. With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
Re: logging.FileHandler diff Py2 v Py3
> > >> I think the culprit is io.open() rather than the logging module. Why > does > Thanks, Peter. It never even occurred to me to look at the source code around the call. I saw open() and thought "built-in open". I forgot that the io package supplanted a bunch of lower level i/o. I'll poke around a little and maybe open a bug report if I can't find any explanation for the change in behavior. Skip > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On 4/3/2018 4:16 PM, Kirill Balunov wrote: Thank you Ian, Terry, Eryk! Now I understand the purpose of py launcher in general. I don't have Windows near, will `py -3.6 ...` work if Python36 is not on the Path? Yes. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
julian 0.14 library
Hi, Has anyone try this https://pypi.python.org/pypi/julian/0.14 i got this error trying to import julian >>> import julian Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/dist-packages/julian/__init__.py", line 1, in from julian.julian import to_jd, from_jd File "/usr/local/lib/python2.7/dist-packages/julian/julian.py", line 5 def __to_format(jd: float, fmt: str) -> float: ^ SyntaxError: invalid syntax cheers, -- https://mail.python.org/mailman/listinfo/python-list
Re: In asyncio, does the event_loop still running after run_until_complete returned?
On Mon, 02 Apr 2018 23:37:51 -0600, Ian Kelly wrote: > If it helps to demystify things, here is a simplified version of what > run_until_complete actually does: > > def run_until_complete(self, future): > """Run until the Future is done. > > If the argument is a coroutine, it is wrapped in a Task. > > Return the Future's result, or raise its exception. """ Demystify, he says. Future, he says. Coroutine. Task. What's self? What's tasks? What's events? Enquiring minds want to know. >future = tasks.ensure_future(future, loop=self) > future.add_done_callback(self.stop) > self.run_forever() > future.remove_done_callback(self.stop) > return future.result() > > def run_forever(self): > """Run until stop() is called.""" o_O That's obviously a different meaning to the word "forever" than I learnt at school. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: Python aliases under Windows?
On Tue, Apr 3, 2018 at 8:16 PM, Kirill Balunov wrote: > > will `py -3.6 ...` work if Python36 is not on the Path? Yes, by default it will work. When installed for all users, the launcher is installed in the Windows directory. For a per-user install, the launcher is installed in a subdirectory of the user's program files, and the installer adds the launcher's directory to PATH. > Concerning dealing with `python` vs `python3` it is a matter of habit, and I > find the > latter option more reliable and missing it under Windows. On Windows, I don't have any Python version permanently set in PATH. It's set by the current virtual environment. Even in Unix, an active virtual environment has a `python` command for Python 3. The issue is only with the system `python` command (i.e. /usr/bin/python), which I don't use directly. -- https://mail.python.org/mailman/listinfo/python-list
Re: In asyncio, does the event_loop still running after run_until_complete returned?
Ian於 2018年4月3日星期二 UTC+8下午1時38分57秒寫道： > On Mon, Apr 2, 2018 at 9:01 PM, wrote: > > def run_forever(self): > """Run until stop() is called.""" >try: > events._set_running_loop(self) > while True: > self._run_once() > if self._stopping: > break > finally: > self._stopping = False > events._set_running_loop(None) > What's the purpose of resetting self._stopping back to False in finally clause? --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: julian 0.14 library
On Wed, Apr 4, 2018 at 12:24 PM, sum abiut wrote: > Hi, > Has anyone try this https://pypi.python.org/pypi/julian/0.14 > > i got this error trying to import julian > import julian > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib/python2.7/dist-packages/julian/__init__.py", line 1, > in > from julian.julian import to_jd, from_jd > File "/usr/local/lib/python2.7/dist-packages/julian/julian.py", line 5 > def __to_format(jd: float, fmt: str) -> float: > ^ > SyntaxError: invalid syntax > Looks like that package requires Python 3, but was uploaded to PyPI without any version tags. You could try running it in Python 3.x, but there's no way to know which ".x" versions are going to work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: In asyncio, does the event_loop still running after run_until_complete returned?
On Tue, Apr 3, 2018 at 9:20 PM, wrote: > What's the purpose of resetting self._stopping back to False in finally > clause? Presumably so that the loop won't immediately stop again if you restart it. -- https://mail.python.org/mailman/listinfo/python-list
