Tkinter - cannot import tklib
Hello all, I am an experienced Python user and struggle with following statement: >>> from tklib import * Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'tklib' I tried to import tklib as shown above on following of my Python installations: Anaconda Python 3.8.3, Portable Python 3.9, Python 3.10.1, Python 2.7.10 with the same negative result. I also tried to find help by googling - without success. Also I did not find a python module called tklib to install. Tkinter, ttk is working fine. There are numerous examples using "from tklib import *" so I assume it works for most. In the tk-tutorial below tklib is used without special explanation, so I assume it should be installed by default with every python installation which has Tkinter integrated. https://tk-tutorial.readthedocs.io/en/latest/intro/intro.html?highlight=app# First time that I cannot help myself. Please help, what do I do wrong? Greetings Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
[issue46056] Cannot use virtual environment on Windows 10 in corporate security settings
wolfgang kuehn added the comment: I can confirm that setting __PYVENV_LAUNCHER__ to ANY path with prefix ./venv/Scripts/ does indeed mark the python session as being a virtual environment, no special permissions needed. However, you will have no tooling support whatsoever (e.g. PyCharms Package Mngt) because __PYVENV_LAUNCHER__ is, after all, non-standard. -- ___ Python tracker <https://bugs.python.org/issue46056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46056] Cannot use virtual environment on Windows 10 in corporate security settings
wolfgang kuehn added the comment: Currently we have a glitch in our internal access rights system. This resulted in me loosing my Admin-privileges. I can only install python from the app-store, which is ok. But without venv support I am stuck for the time being. -- ___ Python tracker <https://bugs.python.org/issue46056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46056] Cannot use virtual environment on Windows 10 in corporate security settings
wolfgang kuehn added the comment: symlinks do not work for me, this may be another bug (should I create a new issue?): python -m venv --without-pip --symlinks venv Unable to symlink 'C:\\Users\\\\AppData\\Local\\Microsoft\\WindowsApps\\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\\idle.exe' to 'C:\\\venv\\Scripts\\idle.exe' Error: [Errno 22] Invalid argument: 'C:\\Users\\\\AppData\\Local\\Microsoft\\WindowsApps\\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\\idle.exe' -- ___ Python tracker <https://bugs.python.org/issue46056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46056] Cannot use virtual environment on Windows 10 in cooperate security settings
Change by wolfgang kuehn : -- title: Cannot use virtual environment on Windows 10 in cooperate security settingss -> Cannot use virtual environment on Windows 10 in cooperate security settings type: -> behavior ___ Python tracker <https://bugs.python.org/issue46056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46056] Cannot use virtual environment on Windows 10 in cooperate security settingss
New submission from wolfgang kuehn : I just installed Python3.10.1 from the Windows 10 App Store. Most workflows depend on creating virtual environments, but (1) python -m venv venv # -> Error 1260: Windows cannot open this program because it has been prevented by a software restriction policy However, a (2) python -m venv --without-pip venv completes, only to not allow execution of (3) .\venv\Scripts\python.exe # -> Error 1260: Windows cannot open this program because it has been prevented by a software restriction policy Reason for this probably are the (not so unreasonable) cooperate Software Restriction Policy (in our case enforced by Applocker): You are not allowed to execute from where you are allowed to write. So basically Python is broken in many MS Windows cooperate settings. Cooperate meaning (Software Restriction Policies) + (Usage of Virtual Environments). And my feeling is that it does not need to be, the virtual environment implementation with those *.exe copies being a kludge, IMHO. Note: (2) is reminiscent of bpo-45337, which was fixed with 3.9. -- components: Installation messages: 408380 nosy: wolfgang-kuehn priority: normal severity: normal status: open title: Cannot use virtual environment on Windows 10 in cooperate security settingss versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45237] Python subprocess not honoring append mode for stdout on Windows
wolfgang kuehn added the comment: The second alternative (wrapping the OS handle in a file descriptor) works like a charm, and is the less invasive workaround code-wise. Thanks for the magic, which I must respect as such :-) Still I feel that this is a bug since (a) it shows an unexpected behaviour, and (b) it fails to abstract away the operating system. -- ___ Python tracker <https://bugs.python.org/issue45237> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45237] Python subprocess not honoring append mode for stdout on Windows
New submission from wolfgang kuehn :
On Windows, if you pass an existing file object in append mode to a subprocess,
the subprocess does **not** really append to the file:
1. A file object with `Hello World` content is passed to the subprocess
2. The content is erased
3. The subprocess writes to the file
4. The expected output does not contain `Hello World`
Demo:
import subprocess, time, pathlib, sys
print(f'Caller {sys.platform=} {sys.version=}')
pathlib.Path('sub.py').write_text("""import sys, time
time.sleep(1)
print(f'Callee {sys.stdout.buffer.mode=}')""")
file = pathlib.Path('dummy.txt')
file.write_text('Hello World')
popen = subprocess.Popen([sys.executable, 'sub.py'],
stdout=file.open(mode='a'))
file.write_text('')
time.sleep(2)
print(file.read_text())
Expected output on Linux
Caller sys.platform='linux' sys.version='3.8.6'
Callee sys.stdout.buffer.mode='wb'
Unexpected bad output on Windows
Caller sys.platform='win32' sys.version='3.8.6'
NULNULNULNULNULNULNULNULNULNULNULCallee sys.stdout.buffer.mode='wb'
Note that the expected output is given on Windows if the file is opened in the
subprocess via `sys.stdout = open('dummy.txt', 'a')`. So it is definitely a
subprocess thing.
--
components: IO
messages: 402096
nosy: wolfgang-kuehn
priority: normal
severity: normal
status: open
title: Python subprocess not honoring append mode for stdout on Windows
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue45237>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
use set notation for repr of dict_keys?
Having a dict like
d = {'one': 1, 'two': 2}
the representation of its keys
repr(d.keys())
gives
"dict_keys(['one', 'two'])"
But since the keys are unique, wouldn't a representation using the set
notation
be more intuitive, i.e. what about changing the output of
dict_keys.__repr__ to
"dict_keys({'one', 'two'})"
(using curly braces instead of brackets)
Wolfgang
--
https://mail.python.org/mailman/listinfo/python-list
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: Indeed this a request for improvement. Technically the software works as expected. Just thousands of programmers have extra debug effort at this tate of affairs as can be deducted from the view count in the stackoverflow questions. The extra step of looking up the column name from the binding number can be avoided as i have shown by my workaround. To hide the detail of set it globally before doing that (sqlite3.paramstyle = 'named'). here in the bug report is not helpful. Part of the request is also to show the record number in executeMany - just to make lifer easier for users for sqlite3 -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: Note that there is also another error: sqlite3.InterfaceError: Error binding parameter :series - probably unsupported type. with similar issue but which actively shows the binding name (but not the record# and debugInfo ... -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: see also https://stackoverflow.com/questions/17169642/python-sqlite-insert-named-parameters-or-null for the more general problem -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: see also https://stackoverflow.com/questions/60793224/sqlite3-programmingerror-you-did-not-supply-a-value-for-binding-1 -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: see also https://stackoverflow.com/questions/46080876/python-sqlite3-you-did-not-supply-a-value-for-binding-6 -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: see also https://stackoverflow.com/questions/61556472/insert-into-a-table-and-get-the-error-sqlite3-programmingerror-you-did-not-sup -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: see also https://stackoverflow.com/questions/61788055/sqlite3-error-you-did-not-supply-a-value-for-binding-1 -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment:
The full workaround is in
https://github.com/WolfgangFahl/DgraphAndWeaviateTest/commit/f1a58d75f459bf78db327acddaf01d5cf64eb7d4
def testBindingError(self):
'''
test list of Records with incomplete record leading to
"You did not supply a value for binding 2"
see https://bugs.python.org/issue41638
'''
listOfRecords=[{'name':'Pikachu', 'type':'Electric'},{'name':'Raichu' }]
for executeMany in [True,False]:
try:
self.checkListOfRecords(listOfRecords,'Pokemon','name',executeMany=executeMany)
self.fail("There should be an exception")
except Exception as ex:
if self.debug:
print(str(ex))
self.assertTrue('no value supplied for column' in str(ex))
Giving the error messages:
INSERT INTO Pokemon (name,type) values (:name,:type)
failed: no value supplied for column 'type'
in mode "executeMany"
INSERT INTO Pokemon (name,type) values (:name,:type)
failed: no value supplied for column 'type'
record #2={'name': 'Raichu'}
if executeMany is not used and errorDebug is on
The wrapper code is:
def store(self,listOfRecords,entityInfo,executeMany=False):
'''
store the given list of records based on the given entityInfo
Args:
listOfRecords(list): the list of Dicts to be stored
entityInfo(EntityInfo): the meta data to be used for storing
'''
insertCmd=entityInfo.insertCmd
try:
if executeMany:
self.c.executemany(insertCmd,listOfRecords)
else:
index=0
for record in listOfRecords:
index+=1
self.c.execute(insertCmd,record)
self.c.commit()
except sqlite3.ProgrammingError as pe:
msg=pe.args[0]
if "You did not supply a value for binding" in msg:
columnIndex=int(re.findall(r'\d+',msg)[0])
columnName=list(entityInfo.typeMap.keys())[columnIndex-1]
debugInfo=""
if not executeMany:
if self.errorDebug:
debugInfo="\nrecord #%d=%s" % (index,repr(record))
raise Exception("%s\nfailed: no value supplied for column
'%s'%s" % (insertCmd,columnName,debugInfo))
else:
raise pe
--
___
Python tracker
<https://bugs.python.org/issue41638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment: see https://github.com/WolfgangFahl/DgraphAndWeaviateTest/issues/7 and https://github.com/WolfgangFahl/DgraphAndWeaviateTest/commit/cc7dbc4c3ade4dd6b2e74f41410e19bc21450490 -- ___ Python tracker <https://bugs.python.org/issue41638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
Wolfgang Fahl added the comment:
My workaround starts with:
try:
self.c.executemany(insertCmd,listOfRecords)
self.c.commit()
except sqlite3.ProgrammingError as pe:
msg=pe.args[0]
if "You did not supply a value for binding" in msg:
columnIndex=int(re.findall(r'\d+',msg)[0])
columnName=list(entityInfo.typeMap.keys())[columnIndex-1]
raise Exception("%s\nfailed: no value supplied for column '%s'"
% (insertCmd,columnName))
else:
raise pe
which gives me:
Exception: INSERT INTO Pokemon (name,type) values (:name,:type)
failed: no value supplied for column 'type'
but not the data yet. So i am now forced to implement another insert that does
not use executemany (which i like a lot) just to get proper debug information -
this is a pitty.
--
___
Python tracker
<https://bugs.python.org/issue41638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41638] Error message: sqlite3.ProgrammingError: You did not supply a value for binding # might be improved
New submission from Wolfgang Fahl :
def testBindingError(self):
'''
test list of Records with incomplete record leading to
"You did not supply a value for binding 2"
'''
listOfRecords=[{'name':'Pikachu', 'type':'Electric'},{'name':'Raichu' }]
resultList=self.checkListOfRecords(listOfRecords,'Pokemon','name')
Which eventually will call:
insertCmd=entityInfo.insertCmd
self.c.executemany(insertCmd,listOfRecords)
self.c.commit()
leading to the error message:
sqlite3.ProgrammingError: You did not supply a value for binding 2.
When many thousand records are inserted this message is not very helpful.
you might want to improve it to:
sqlite3.ProgrammingError: You did not supply a value for binding 2 ("type") in
record #2 with a debug option that shows the actual date like:
sqlite3.ProgrammingError: You did not supply a value for binding 2 ("type") in
record #2 debuginfo: name="Raichu", type=missing
sqlite3.ProgrammingError: You did not supply a value for binding 2.
--
components: Library (Lib)
messages: 375906
nosy: WolfgangFahl
priority: normal
severity: normal
status: open
title: Error message: sqlite3.ProgrammingError: You did not supply a value for
binding # might be improved
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40196] symtable.Symbol.is_local() can be True for global symbols
Wolfgang Stöcher added the comment:
In symtable.Function.get_locals() symbols with scopes in (LOCAL, CELL) are
selected. Also
>>> code = """\
... def foo():
...x = 42
...def bar():
... return x
... """
>>> import symtable
>>> top = symtable.symtable(code, "?", "exec")
>>> top.get_children()[0].lookup('x')._Symbol__scope == symtable.CELL
True
So I guess this would be the correct fix then:
def is_local(self):
return self.__scope in (LOCAL, CELL)
--
___
Python tracker
<https://bugs.python.org/issue40196>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40196] symtable.Symbol.is_local() can be True for global symbols
Wolfgang Stöcher added the comment: see https://stackoverflow.com/a/61040435/1725562 for a proposed fix -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue40196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40196] symtable.Symbol.is_local() can be True for global symbols
New submission from Wolfgang Stöcher : Consider this function: def f(): global e e = 1 When inspecting symbols with symtable, symbol 'e' will be global and local, whereas is_local() should return False. See the attached file for reproducing. It will output to stdout: symbol 'e' in function scope: is_global() = True, is_local() = True global scope: e = 1 -- components: Library (Lib) files: global_and_local.py messages: 365820 nosy: coproc priority: normal severity: normal status: open title: symtable.Symbol.is_local() can be True for global symbols versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file49037/global_and_local.py ___ Python tracker <https://bugs.python.org/issue40196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Spread a statement over various lines
On 17.09.19 20:59, Manfred Lotz wrote:
> I have a function like follows
>
> def regex_from_filepat(fpat):
> rfpat = fpat.replace('.', '\\.') \
> .replace('%', '.') \
> .replace('*', '.*')
>
> return '^' + rfpat + '$'
>
>
> As I don't want to have the replace() functions in one line my
> question is if it is ok to spread the statement over various lines as
> shown above, or if there is a better way?
>
One problem with explicit line continuation using \ is that it is
dependent on the backslash being the last character on the line, i.e.
a single space at the end of the line will result in a SyntaxError.
This is why implicit line continuation relying on opened parentheses,
brackets or curly braces is often preferred, and recommended over
backslash continuation in PEP8
(https://www.python.org/dev/peps/pep-0008/#maximum-line-length).
To use implicit line continuation you could either introduce extra
surrounding parentheses as suggested by others, or you may make use
of the parentheses you have already, like so:
def regex_from_filepat(fpat):
rfpat = fpat.replace(
'.', '\\.'
).replace(
'%', '.'
).replace(
'*', '.*'
)
return '^' + rfpat + '$'
--
https://mail.python.org/mailman/listinfo/python-list
[issue35706] Make it easier to use a venv with an embedded Python interpreter
Wolfgang Langner added the comment: I think this pep is related to the issue and could be a solution: https://www.python.org/dev/peps/pep-0582/ -- nosy: +tds333 ___ Python tracker <https://bugs.python.org/issue35706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34232] Python3.7.0 exe installers (32 and 64 bit) failing on Windows7
Wolfgang Maier added the comment: Oh, sorry, I didn't realize there was another file and it seems I did not keep it so I just ran the installer again to reproduce. Attached is the new pair of log files. -- Added file: https://bugs.python.org/file47722/Python 3.7.0 (64-bit)_20180731180657_000_core_JustForMe.log ___ Python tracker <https://bugs.python.org/issue34232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34232] Python3.7.0 exe installers (32 and 64 bit) failing on Windows7
Change by Wolfgang Maier : Added file: https://bugs.python.org/file47723/Python 3.7.0 (64-bit)_20180731180657.log ___ Python tracker <https://bugs.python.org/issue34232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34232] Python3.7.0 exe installers (32 and 64 bit) failing on Windows7
Change by Wolfgang Maier : Added file: https://bugs.python.org/file47712/Python 3.7.0 (64-bit)_20180726120531.log ___ Python tracker <https://bugs.python.org/issue34232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34232] Python3.7.0 exe installers (32 and 64 bit) failing on Windows7
New submission from Wolfgang Maier : System: Windows7 Enterprise SP1 64-bit Downloaded the executable installer from python.org (tried both 32- and 64-bit -> same error) Selected the default user-install and got an almost immediate Error message: The TARGETDIR variable must be provided when invoking this installer. Clicking OK reveals 0x80070643 - Fatal error during installation and the attached log file. Rebooting didn't help and I also tried playing with custom installation settings, too, but no success so far. -- components: Installation messages: 322409 nosy: steve.dower, wolma priority: normal severity: normal status: open title: Python3.7.0 exe installers (32 and 64 bit) failing on Windows7 versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Can pip install packages for all users (on a Linux system)?
On 24.07.2018 20:07, John Ladasky wrote: I've been using "sudo pip3 install" to add packages from the PyPI repository. I have multiple user accounts on the computer in question. My goal is to install packages that are accessible to all user accounts. I know that using the Synaptic Package Manager in Ubuntu will install for all users, but not every Python package is included in the Canonical repository. I hadn't noticed any discrepancies until recently. I upgraded from Ubuntu 17.10 to 18.04. In parallel, I upgraded tensorflow-gpu 1.4.0 to 1.8.0. Everything worked on my main account. However, attempting to import tensorflow from Python on a secondary account failed. Eventually I checked the pip lists in each account, and I found a reference to the old tensorflow 1.4 on the secondary account. Uninstalling that, and reinstalling tensorflow-gpu 1.8 on the secondary account fixed the problem. One possible explanation for your finding: user installs normally take precedence over system-wide installs both at import time and for pip (list, uninstall, etc.). So if you, or your users, have installed tensorflow 1.4.0 using pip install --user before, then a system-wide pip install tensorflow 1.8.0 won't override this previous version (though if your admin account has the user install, too, pip would warn you). Otherwise, a pip install without --user is effectively a system-wide install as long as your Python is a system-wide install. I believe that I now have tensorflow 1.8 installed twice on my system, once for each user. If anyone can share how to convince pip to behave like Synaptic, I would appreciate it. Thanks. If a user has a user install of tensorflow, it will always shadow the system-wide version. The only solution I know (except manipulating Python's import path list) is to pip uninstall the per-user version. Best, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: 转发: No pip for my Python 3.6.5!
On 07/09/2018 10:14 AM, 卢 嘉幸 wrote: Hi~ I am a beginner with Python. My computer is of Windows version. And I dowloaded the lastest version of python on the https://www.python.org/ . My book, Automate the Boring Stuff With Python, teaches me to install a third-party module with the command line: pip install send2trash (for example). But there comes the error message !!! What is going wrong? It makes no sense since my Python is 3.6.5 version. I doubt that my poor Python doesn’t have a pip. Does the following work for you? py -3 -m pip install send2trash work for you? If so, you can either continue to run pip like this (it is a good way) or you'll have to make pip.exe discoverable from your PATH as suggested by Abdur-Rahmaan. Best, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Question : Input after all prompts in python
On 06/11/2018 04:19 PM, moha...@gmail.com wrote:
BTW i tried the code above, but i encountered a syntax error.
print(u"\u001b[{}A".format(n), flush=True, end="")
^
SyntaxError :invalid syntax
That's probably because you have been running it in Python2.
Most people here assume you mean Python3 nowadays if you say Python,
especially when you ask a beginner's question.
--
https://mail.python.org/mailman/listinfo/python-list
[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: Try to think of it this way: By choosing a default of True, every new project with subparsers that aims for Python <3.7 compatibility will have to take some measures (either overwrite the default or special-case 3.3-3.6). So no matter whether this is the "least surprising" choice, it is an inconvenient one that makes the default almost useless for years to come. In the long term, when support for Python<=3.6 is finally not important anymore, you would get a slightly more consistent API (though I never thought of a subparser as a regular positional argument before this issue), but the price for it seems too high to me. Since backwards compatibility is easy to restore by overwriting the default, I can certainly live with the choice of True, but I think it's not the best one could get out of this new and useful keyword. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24068] statistics module - incorrect results with boolean input
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: Fixed as part of resolving issue 25177. -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25177] OverflowError in statistics.mean when summing large floats
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: Steven's commit here also fixed issue 24068. -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33228] Use Random.choices in tempfile
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: Actually, in Python2.7 random.choice is implemented with the same susceptibility to the rounding bug as Python3's choices, still nobody ever reported a tempfile IndexError problem (I guess). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33228] Use Random.choices in tempfile
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: sorry, should have been issue 24567, of course. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33228] Use Random.choices in tempfile
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: @serhiy as I understand issue 33228, the double rounding problem potentially causing an IndexError can only affect choices() if the len of the sequence to choose from is greater than 2049, but the string in question here is only 37 characters long. Alternatively, choices may fail with certain weights (https://bugs.python.org/msg275594), but _RandomNameSequence is not using weights. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33228] Use Random.choices in tempfile
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- keywords: +patch pull_requests: +6093 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33228] Use Random.choices in tempfile
New submission from Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: A rather trivial change: tempfile._RandomNameSequence could make use of random.Random.choices introduced in 3.6. IMO, the suggested change would give clearer and also faster code. It also updates the docstring of the class, which currently talks about a six-character string, when an eight-character string gets returned. -- messages: 314969 nosy: wolma priority: normal severity: normal status: open title: Use Random.choices in tempfile type: performance versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33193] Cannot create a venv on Windows when directory path contains dollar character
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment:
An exotic case, but it also affects Linux:
python3.7 -m venv 'at$test'
Error: Command '['/home/maier/at$test/bin/python3.7', '-Im', 'ensurepip',
'--upgrade', '--default-pip']' returned non-zero exit status 2.
[maier@nb19 ~]$ mkdir 'at$test'
mkdir: cannot create directory ‘at$test’: File exists
[maier@nb19 ~]$ cd 'at$test'
[maier@nb19 at$test]$ bin/python -m ensurepip
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Exception:
Traceback (most recent call last):
File "/usr/lib64/python3.7/distutils/util.py", line 187, in subst_vars
return re.sub(r'\$([a-zA-Z_][a-zA-Z_0-9]*)', _subst, s)
File "/usr/lib64/python3.7/re.py", line 198, in sub
return _compile(pattern, flags).sub(repl, string, count)
File "/usr/lib64/python3.7/distutils/util.py", line 184, in _subst
return os.environ[var_name]
File "/usr/lib64/python3.7/os.py", line 678, in __getitem__
raise KeyError(key) from None
KeyError: 'test'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/tmp/tmpppaapmyk/pip-9.0.1-py2.py3-none-any.whl/pip/basecommand.py",
line 215, in main
status = self.run(options, args)
File
"/tmp/tmpppaapmyk/pip-9.0.1-py2.py3-none-any.whl/pip/commands/install.py", line
342, in run
prefix=options.prefix_path,
File "/tmp/tmpppaapmyk/pip-9.0.1-py2.py3-none-any.whl/pip/req/req_set.py",
line 784, in install
**kwargs
File
"/tmp/tmpppaapmyk/pip-9.0.1-py2.py3-none-any.whl/pip/req/req_install.py", line
851, in install
self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
File
"/tmp/tmpppaapmyk/pip-9.0.1-py2.py3-none-any.whl/pip/req/req_install.py", line
1064, in move_wheel_files
isolated=self.isolated,
File "/tmp/tmpppaapmyk/pip-9.0.1-py2.py3-none-any.whl/pip/wheel.py", line
247, in move_wheel_files
prefix=prefix,
File "/tmp/tmpppaapmyk/pip-9.0.1-py2.py3-none-any.whl/pip/locations.py", line
153, in distutils_scheme
i.finalize_options()
File "/usr/lib64/python3.7/distutils/command/install.py", line 307, in
finalize_options
self.expand_basedirs()
File "/usr/lib64/python3.7/distutils/command/install.py", line 486, in
expand_basedirs
self._expand_attrs(['install_base', 'install_platbase', 'root'])
File "/usr/lib64/python3.7/distutils/command/install.py", line 480, in
_expand_attrs
val = subst_vars(val, self.config_vars)
File "/usr/lib64/python3.7/distutils/util.py", line 189, in subst_vars
raise ValueError("invalid variable '$%s'" % var)
ValueError: invalid variable '$'test''
So the venv actually gets created, but it's ensurepip which chokes on the $.
--
nosy: +wolma
versions: +Python 3.7, Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33193>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33203] random.choice: raise IndexError on empty sequence even when not using getrandbits internally
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: @selik: it's true _randbelow doesn't work for negative numbers, but the difference is that both branches are affected, the docstring does not make any guarantees about it, and no public part of the random module is affected by this behavior. In addition, "fixing" _randbelow for negative input cannot be done without impacting performance of several public methods of random.Random so I don't think this should be done. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33203] random.choice: raise IndexError on empty sequence even when not using getrandbits internally
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: @rhettinger: the reason the ValueError gets raised correctly in the getrandbits-dependent branch is because getrandbits itself does a n<=0 check (in C for random.Random, in Python for random.SystemRandom). So I thought the real reason why _randbelow does not perform the check was that it would be redundant, which it isn't when only random is used. So instead of thinking about the suggested check as something that impacts performance (which certainly it does), I would rather see it as adding something into that second branch that was forgotten and gave that branch a performance benefit over the other one, which it never deserved. It is also worthwhile to remember that any performance impact of this will only hit subclasses of random.Random that define random, but not getrandbits. Your alternative idea of having random.choice catch (ValueError, ZeroDivisionError) would affect random.Random and all subclasses. If a subclass defines getrandbits, it needs to perform that check anyway and, thinking about this more, I suggest that the requirement for any user-provided getrandbits to raise ValueError on k <= 0 should actually be added to the getrandbits docs. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33144] random._randbelow optimization
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: ok, I've created issue 33203 to deal with raising ValueError in _randbelow consistently. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33203] random.choice: raise IndexError on empty sequence even when not using getrandbits internally
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- keywords: +patch pull_requests: +6050 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33203] random.choice: raise IndexError on empty sequence even when not using getrandbits internally
New submission from Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
from https://docs.python.org/3/library/random.html#random.choice:
Return a random element from the non-empty sequence seq. If seq is empty,
raises IndexError.
Indeed:
>>> import random
>>> random.choice([])
Traceback (most recent call last):
File "", line 1, in
File "/home/wolma/cpython/random.py", line 259, in choice
raise IndexError('Cannot choose from an empty sequence') from None
IndexError: Cannot choose from an empty sequence
but when not using getrandbits internally:
>>> class MyRandom(random.Random):
... def random(self):
... return super().random()
...
>>> my_random=MyRandom()
>>> my_random.choice([])
Traceback (most recent call last):
File "", line 1, in
File "/home/wolma/cpython/random.py", line 257, in choice
i = self._randbelow(len(seq))
File "/home/wolma/cpython/random.py", line 245, in _randbelow
rem = maxsize % n
ZeroDivisionError: integer division or modulo by zero
This is because the ValueError that random.choice tries to catch gets raised
only in the getrandbits-dependent branch of Random._randbelow, but not in the
branch using only Random.random (even though Random._randbelow suggests uniform
behaviour.
--
components: Library (Lib)
messages: 314787
nosy: rhettinger, serhiy.storchaka, wolma
priority: normal
severity: normal
status: open
title: random.choice: raise IndexError on empty sequence even when not using
getrandbits internally
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33203>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33144] random._randbelow optimization
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: In addition, I took the opportunity to fix a bug in the original _randbelow in that it would only raise the advertised ValueError on n=0 in the getrandbits-dependent branch, but ZeroDivisionError in the pure random branch. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33144] random._randbelow optimization
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: So, the PR implements the behaviour suggested by Serhiy as his cases 1 and 2. Case 2 changes *existing* behaviour because before it was sufficient to have a user-defined getrandbits anywhere in the inheritance tree, while with the PR it has to be more recent (or be defined within the same class) as the random method. I'm not 100% sold on this particular aspect so if you think the old behaviour is better, then that's fine with me. In most real situations it would not make a difference anyway (or do people build complex inheritance hierarchies on top of random.Random?). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33144] random._randbelow optimization
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- pull_requests: +6015 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33144] random._randbelow optimization
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: Thanks, Raymond. I'll do that once I've addressed Serhiy's points. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33144] random._randbelow optimization
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: Serhiy: > I like the idea in general, but have comments about the implementation. > > __init_subclass__ should take **kwargs and pass it to > super().__init_subclass__(). type(cls.random) is not the same as > type(self.random). I would use the condition `cls.random is > _random.Random.random` instead, or check if the method is in cls.__dict__. > > This will break the case when random or getrandbits methods are patched after > class creation or per instance, but I think we have no need to support this. > My bad, sorry, and thanks for catching all these issues! You're absolutely right about the class type checks not being equivalent to the original ones at the instance level. Actually, this is due to the fact that I first moved the checks out of _randbelow and into __init__ just as Raymond would have done and tested this, but then I realized that __init_subclass__ looked just like the right place and moved them again - this time without testing on derived classes again. From a quick experiment it looks like types.MethodDescriptorType would be the correct type to check cls.random against and types.FunctionType would need to be checked against cls.getrandbits, but that starts to look rather esoteric to me - so you are probably right that something with a cls.__dict__ check or the alternative suggestion of `cls.random is _random.Random.random` are better solutions, indeed. > We could support also the following cases: > > 1. > class Rand1(Random): > def random(self): ... > # _randbelow should use random() > > class Rand2(Rand1): > def getrandbits(self): ... > # _randbelow should use getrandbits() > # this is broken in the current patch > Right, hadn't thought of this situation. > 2. > class Rand1(Random): > def getrandbits(self): ... > # _randbelow should use getrandbits() > > class Rand2(Rand1): > def random(self): ... > # _randbelow should use random() > # this is broken in the current code > May be worth fixing, too. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: please test the new PyPI (now in beta)
For me, that's a window width issue. The sidebar with the filters only
shows when the window is wide enough. Unfortunately, the text mentioning
it doesn't change, so this should be fixed.
On 03/27/2018 12:06 PM, Steven D'Aprano wrote:
On Tue, 27 Mar 2018 10:48:15 +0100, Paul Moore wrote:
By the way, on the search page:
https://pypi.org/search/
it says "Enter a search query above, or select a filter from the list
of classifiers on the left" but there is no such filter or list of
classifiers.
Do you not get the section
"""
Filter Projects
By Programming Language
By License
By Framework
...
"""
on the left of the page?
There's nothing on the left of the page. It has:
(pypi logo) (search projects text box)
("Enter a search query..." with examples)
(Add filter button)
then the blue footer with "Get Help", "About PyPI", etc.
--
https://mail.python.org/mailman/listinfo/python-list
[issue33144] random._randbelow optimization
New submission from Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: Given that the random module goes a long way to ensure optimal performance, I was wondering why the check for a match between the random and getrandbits methods is performed per call of Random._randbelow, when it could also be done at instantiation time (the attached patch uses __init_subclass__ for that purpose and, in my hands, gives 10-25% speedups for calls to methods relying on _randbelow). Is it really necessary to guard against someone monkey patching the methods rather than using inheritance? -- components: Library (Lib) files: randbelow.patch keywords: patch messages: 314455 nosy: rhettinger, wolma priority: normal severity: normal status: open title: random._randbelow optimization type: performance versions: Python 3.8 Added file: https://bugs.python.org/file47501/randbelow.patch ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Entering a very large number
On 03/23/2018 01:30 PM, Wolfgang Maier wrote:
On 03/23/2018 01:16 PM, ast wrote:
Hi
I found this way to put a large number in
a variable.
C = int(
"28871482380507712126714295971303939919776094592797"
"22700926516024197432303799152733116328983144639225"
"94197780311092934965557841894944174093380561511397"
"4215424169339729054237110027510420801349667317"
"5515285922696291677532547505856101949404200039"
"90443211677661994962953925045269871932907037356403"
"22737012784538991261203092448414947289768854060249"
"76768122077071687938121709811322297802059565867")
A very simple improvement would be to use a single
triple-quoted string. Assuming you are copy/pasting
the number from somewhere that will save a lot of your
time.
Like this, for example:
n = int(
''.join("""
37107287533902102798797998220837590246510135740250
46376937677490009712648124896970078050417018260538
74324986199524741059474233309513058123726617309629
91942213363574161572522430563301811072406154908250
23067588207539346171171980310421047513778063246676
89261670696623633820136378418383684178734361726757
28112879812849979408065481931592621691275889832738
44274228917432520321923589422876796487670272189318
47451445736001306439091167216856844588711603153276
70386486105843025439939619828917593665686757934951
62176457141856560629502157223196586755079324193331
64906352462741904929101432445813822663347944758178
92575867718337217661963751590579239728245598838407
58203565325359399008402633568948830189458628227828
80181199384826282014278194139940567587151170094390
35398664372827112653829987240784473053190104293586
86515506006295864861532075273371959191420517255829
71693888707715466499115593487603532921714970056938
54370070576826684624621495650076471787294438377604
53282654108756828443191190634694037855217779295145
36123272525000296071075082563815656710885258350721
45876576172410976447339110607218265236877223636045
17423706905851860660448207621209813287860733969412
""".split())
)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Entering a very large number
On 03/23/2018 01:16 PM, ast wrote: Hi I found this way to put a large number in a variable. C = int( "28871482380507712126714295971303939919776094592797" "22700926516024197432303799152733116328983144639225" "94197780311092934965557841894944174093380561511397" "4215424169339729054237110027510420801349667317" "5515285922696291677532547505856101949404200039" "90443211677661994962953925045269871932907037356403" "22737012784538991261203092448414947289768854060249" "76768122077071687938121709811322297802059565867") A very simple improvement would be to use a single triple-quoted string. Assuming you are copy/pasting the number from somewhere that will save a lot of your time. It works but is it not optimal since there is a string to int conversion. I was not able to put an integer directly because character '\' for line cut doesnt work inside an integer C = \ 28871482380507712126714295971303939919776094592797\ 22700926516024197432303799152733116328983144639225\ ... 76768122077071687938121709811322297802059565867 doesn't work Do you have a better idea ? Thx -- https://mail.python.org/mailman/listinfo/python-list
[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: _wants_ is a bit a strong word, but, at least, you can do a bit a nicer job than the default error, like printing a nicely formatted list of subcommands as you would get it with the main parsers help. In fact, in my own code I'm actually catching the missing subparser situation, then calling parse_args again with ['--help'] :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: On 03/20/2018 04:38 PM, Anthony Sottile wrote: > > Anthony Sottile <asott...@umich.edu> added the comment: > > The intention of the change in issue 26510 was to pick the least surprising > behaviour for the default value of subparsers -- the compatiblity with the > behaviour before the regression was introduced in 3.3 was a nice side-effect. > As with the rest of positional arguments in argparse, the positional > subparsers were changed to required by default. > Since the 3.3 change happened a long time ago and has been kept through the next three releases, I never considered it a regression, but rather thought the original behavior was an oddity of early Python 3s (I've never written an argparse-based parser in Python 2), so it's interesting to see this in the larger historical context. Overall, I think "least surprising" is in the eye of the beholder here and I want to emphasize that I'm all for your change of adding the keyword argument, just not so convinced about your choice of the default. My main argument for a default of False and against True: having True as the default will only lead people used to the Python 2 and pre-3.3 way of things to think that they have code working for Python 3, when, in fact, that code will break under 3.3-3.6, and, at least, 3.6 will stay in widespread use for a long time (even Ubuntu 18.04 will still ship with it as the default python3, so Python3.6 will outlast the life cycle of Python 2 by a good measure). Conversely, most projects are dropping Python 3.2 support these days or have done so already, so nobody really cares about how things worked in this version (I think it's telling along these lines that your - corrected - SO link dates back from 2013). So I think, it is a rather unnecessary incompatibility you are introducing for project maintainers even if the original issue was a regression. > The main issue addressing the 3.3 regression I believe is > https://bugs.python.org/issue9253 and not the one linked. > > When I revived the patch, I surveyed a number of open source tools using > subparsers (~10-20) and they all fell into the following categories: > > - Used the workaround (part of this SO post: > https://stackoverflow.com/a/23354355/812183) (most fell into this category) > - crashed with some sort of TypeError (NoneType has no attribute startswith, > KeyeError: None, etc.) due to not handling "optional" subparsers > - Manually handled when the subparser was `None` to raise an argparse error As yet another option, and similar to the third one on your list, I'm using the set_defaults method of the subparser, and I'm checking whether the corresponding key is present in the Namespace. > > You can enable a 3.3-3.7 compatible "always optional subparsers" with a > similar pattern that was used to manually restore the pre-regression > behaviour: > > subparsers = parser.add_subparsers(...) > subparsers.required = False > Ah, right! That's a good option. Didn't realize it would work this way, too :) But a still think you should consider my above argument. > I believe the error message issue is already tracked: > https://bugs.python.org/issue29298 > I see, that looks as if it would fix this part. It would be great if it could get merged into Python 3.7 still. > -- > > ___ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue33109> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: curious asymmetry in range limiting
On 03/20/2018 03:21 PM, Robin Becker wrote: I don't know how I never came across this before, but there's a curious asymmetry in the way ranges are limited Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> s = '0123456789' >>> print(repr(s[-5:5])) '' >>> print(repr(s[5:15])) '56789' >>> why is the underflow start index treated so differently from the limit index overflow? I suppose there must be some reason, but it eludes me. It's because in the slice [-5:5] the -5 is not trying to access an element at an index < 0, but indicating the fifth-last element in the sequence. -- https://mail.python.org/mailman/listinfo/python-list
[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True
New submission from Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: I find the True default for 'required' quite cumbersome introduced as a result of issue 26510. With existing parsers it can unnecessarily break compatibility between Python3.x versions only to make porting a bit easier for Python2 users. I think, this late in the life cycle of Python2, within Python3 compatibility should be ranked higher than py2to3 portability. Command line parsing of a package of mine has long used optional subparsers (without me even thinking much about the fact). Now in 3.7, running python3.7 -m MyPackage without arguments (the parser is in __main__.py) I get the ill-formatted error message: __main__.py: error: the following arguments are required: while my code in 3.3 - 3.6 was catching the empty Namespace returned and printed a help message. Because the 'required' keyword argument did not exist in < 3.7 there was no simple way for me to write code that is compatible between all 3.x versions. What I ended up doing now is to check sys.argv before trying to parse things, then print the help message, when that only has a single item, just to keep my existing code working. OTOH, everything would be just fine with a default value of False. Also that truncated error message should be fixed before 3.7 gets released. -- components: Library (Lib) messages: 314145 nosy: Anthony Sottile, bethard, eric.araujo, memeplex, paul.j3, wolma priority: normal severity: normal status: open title: argparse: make new 'required' argument to add_subparsers default to False instead of True type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Console
On 03/07/2018 03:41 PM, Jeremy Jamar St. Julien wrote: I had an problem when trying to start the python GUI. It said there was a subprocess startup error. I was told to start IDLE in a console with idlelib and see what python binary i was runnning IDLE with. Im using windows 10 and i guess console refers to the terminal window and i have no idea what they meant by "the binary its running with" The simplest way to open the console on Windows is to press Win+R (the Windows key together with the r key that is). In the run dialog that appears then, type cmd and the console window should appear. To start IDLE from there type: py -m idlelib Good luck, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Ways to make a free variable local to a function?
On 03/05/2018 07:44 PM, Terry Reedy wrote: On 3/5/2018 9:34 AM, Chris Angelico wrote: On Tue, Mar 6, 2018 at 12:52 AM, Terry Reedy <tjre...@udel.edu> wrote: On 3/5/2018 7:12 AM, Kirill Balunov wrote: # 1. By passing through local variable's default values def func_local_1(numb, _int = int, _float = float, _range = range): You are not required to mangle the names. def func_local_1(numb, int = int, float = float, range = range): ... Even so, this does mess up the function's signature, Which I why I only said that using the original names solves the syntax highlighting issue (of marking built-ins as built-ins). leaving your callers wondering if they can call it with some sort of range parameter. (Though in this particular instance, range() is only called once, so it's pretty much useless to try to optimize it.) In theory, the CPython bytecode compiler (don't know about other Python implementations) could just add these as constants. Yes, what we really want for this sort of thing are unrebindable local constants. A simple syntax change could do it. def func_local_1(numb; int = int, float = float, range = range): The binding after ';' belong in the header because they should be done once. Ah, I did not really understand initially what Kirill was trying to achieve by putting the name binding into the function signature. Now I do, but I don't think it is a good idea. Sanctioning this with dedicated syntax would only make Python more static because for any function defined this way, you would lose the ability to alter the behavior of that function through changing the global binding after the function has been called (in the example above, you could no longer mock replace int, float and range on subsequent func_local_1 calls) and I don't think this is something that should be encouraged. Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there are good DRY fix for this painful design pattern?
On 26.02.2018 15:41, Steven D'Aprano wrote: I have a class with a large number of parameters (about ten) assigned in `__init__`. The class then has a number of methods which accept *optional* arguments with the same names as the constructor/initialiser parameters. If those arguments are None, the defaults are taken from the instance attributes. Others have pointed out good solutions already, in particular, combining inspect and decorators or encapsulating the parameters in an object. Alternatively, you could reconsider your class design. Although I can't tell from your example whether this idea would be acceptable for your use case, consider removing your parameters from the class methods (except from __init__) altogether so the values passed during instantiation cannot be changed later. In exchange, add module-level functions corresponding to each of your class methods that accept **kwargs and that generate new instances of your class passing **kwargs on to __init__, then call the corresponding instance method. The stdlib textwrap module, for example, uses this approach. Best, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: This newsgroup (comp.lang.python) may soon be blocked by Google Gro
On 02/09/2018 12:23 PM, John Ladasky wrote: On Friday, February 9, 2018 at 12:50:16 AM UTC-8, Tim Golden wrote: Gmane offers a newsgroup interface to the mailing list I haven't visited GMane in a few years, but I found it difficult to navigate. In particular, I found searching to be cumbersome. Weren't the archives broken into 30-day blocks? I just tried GMane again two minutes ago. I can't confirm my recollections, but right now what I'm seeing is worse. If you follow this link right now... (http://gmane.org/find.php?list=comp.lang.python)... you get this: "Not all of Gmane is back yet - We're working hard to restore everything" And if you follow the link labeled "The latest news is at Gmane News" at the bottom of that page, it takes you here... (http://home.gmane.org/)... and the top blog post discussing site repairs is dated September 2016! I'm not too excited about trying GMane again after seeing that. You are certainly right about the gmane *Web Interface*. However, you can access their newsgroup interface through any newsgroup reader (including e.g. Thunderbird) and that's a really nice way of following things. -- https://mail.python.org/mailman/listinfo/python-list
[issue31978] make it simpler to round fractions
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: That, of course, wasn't my original suggestion, but since Mark started discussing other possible forms this could take, like round-to-nearest analogs of mod and divmod, I thought maybe it's worth pointing out this aspect and, yes, maybe the three-argument form would be nice. Essentially, this would be fractions.Fraction.__round__ then. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31978> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31978] make it simpler to round fractions
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: >>> for x in range(1,501): for y in range(1,501): if round(x/y, 1) != float(round(F(x,y), 1)): print(x,y) where F is fractions.Fraction Sorry! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31978> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31978] make it simpler to round fractions
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: > (E.g., if both `a` and `b` are not-too-large integers, `round(a / b)` is > still "safe" in that it will give the same result as if a non-lossy integer > division is used.) Well, it does not take particularly large a and b to break round's tie-breaking through rounding-to-even though: >>> for x in range(1,501): for y in range(1,501): if round(x/y, 1) != float(round(F(x,y), 1)): print(x,y) 1 20 2 40 3 20 3 60 4 80 5 100 6 40 6 120 7 20 7 140 8 160 9 20 9 60 9 180 10 200 11 220 12 80 12 240 13 20 13 260 14 40 14 280 15 100 15 300 16 320 17 340 18 40 18 120 18 360 19 20 19 380 20 400 21 20 21 60 21 140 21 420 22 440 23 20 23 460 24 160 24 480 25 500 ... -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31978> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31978] make it simpler to round fractions
Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de> added the comment: ok, I agree with you that the returned type should not change with the value of an argument. I simply didn't think one vs two argument versions here, but in terms of three different code branches where one returns int already. Maybe 'slight' was the wrong wording - think of it as 'easy to revert' then :) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31978> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31978] make it simpler to round fractions
New submission from Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: Hi, because of floating point inaccuracies it is suboptimal to use round(int1/int2) for rounding of a fraction. fractions.Fraction, OTOH, offers exact rounding through its implementation of __round__, but using it requires users to create a fractions.Fraction instance from two ints first. The algorithm used by Fraction.__round__ is, essentially, the same as the one used in the pure-Python version of the datetime._divide_and_round module (which, in turn, is taken from a comment by Mark Dickinson in Objects/longobject.c). My suggestion is to promote this algorithm to an exposed function in the fractions module (actually, it may make sense to have it in the math module instead - compare the case of the gcd function, which started out in fractions, but is now in transition to math) so that it can be used by Fraction.__round__, but also any other code. Attached is a patch demonstrating the idea. In addition, to the above benefit, it turns out to actually speed up Fraction.__round__ substantially, when ndigits is not None because it then avoids the generation of temporary Fraction instances, and, in my hands at least, it even makes the general (ndigits=None) case slightly faster (apparently the copied datetime._divide_and_round code is more efficient than the original in Fraction.__round__). There is one slight additional tweak in the patch: in the case of ndigits < 0, it returns an int, not a Fraction (see test_fractions modification to make it pass). I think this is actually a mistake in the current Fraction.__round__, which already promotes the result to int in the general case. This change speeds up round to the next ndigits power of ten by ~ a factor of 5 in my hands because no new Fraction needs to be instantiated anymore. A full PR could include having pure-Python datetime import the function from fractions instead of rolling its own, but I'd first like to hear whether you think this should go into math instead. -- components: Library (Lib) files: fractions_divround.patch keywords: patch messages: 305817 nosy: mark.dickinson, wolma priority: normal severity: normal status: open title: make it simpler to round fractions type: enhancement versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47254/fractions_divround.patch ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31978> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: replacing `else` with `then` in `for` and `try`
On 11/02/2017 06:09 PM, Skip Montanaro wrote: Eh, what can I say? I guess I was paying too much attention to the baseball game. Yes, "else" handles the "fall off the end" termination, not the "exit early" termination. My apologies. I do think that having a way to spell "do this when the loop exits early" makes things clearer. So, perhaps while and for loops could someday grow except clauses. :-) ... and even this idea has been discussed before: https://mail.python.org/pipermail/python-ideas/2017-March/044932.html There wasn't much enthusiasm about it though because few people (ok, maybe even just me) thought it had interesting use cases. -- https://mail.python.org/mailman/listinfo/python-list
Re: A use-case for for...else with no break
On 11/02/2017 12:45 PM, Alberto Berti wrote: "Steve" == Steve D'Aprano <steve+pyt...@pearwood.info> writes: py> for x in "abcdefgh": Steve> ... print(x, end='') Steve> ... py> efghpy> Steve> "For ... else" to the rescue! py> for char in "abcdefgh": Steve> ... print(char, end='') Steve> ... else: Steve> ... print() Steve> ... Steve> abcdefgh py> else doesn't seem to bring any advantage over: for char in "abcdefgh": print(char, end='') print() Try running it interactively and you'll see, wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Code Snippets
On 01.11.2017 18:25, Stefan Ram wrote: I started to collect some code snippets: Sleep one second __import__( "time" ).sleep( 1 ) Get current directory __import__( "os" ).getcwd() Get a random number __import__( "random" ).random() And so on. You get the idea. However, reportedly, all those snippets are anti-patterns because they use »__import__«. But what I like about them: You just paste them in where you want them to be, and your done. What I'm supposed to do instead, I guess, is: Sleep one second import time ... time.sleep( 1 ) Get current directory import os ... os.getcwd() Get a random number import random ... random.random() Now, the user has to cut the import, paste it to the top of his code, then go back to the list of snippets, find the same snippet again, copy the expression, go to his code, then find the point where he wanted to insert the snippet again, and finally insert the snippet. And still there now is a risk of name collisions. So, it seems to me that __import__ is just so much better! I'm not sure why you think this has to do with import vs __import__. If you're worried bout having things on separate lines, you could write: import os; os.getcwd() ,etc., which is actually saving a few characters :) -- https://mail.python.org/mailman/listinfo/python-list
Re: matplot plot hangs
On 01.11.2017 00:40, Andrew Z wrote: hello, learning python's plotting by using matplotlib with python35 on fedora 24 x86. Installed matplotlib into user's directory. tk, seemed to work - http://www.tkdocs.com/tutorial/install.html#installlinux - the window shows up just fine. but when trying to run the simple plot ( https://matplotlib.org/examples/pylab_examples/simple_plot.html) the script is hanging on; plt.plot(t, s) attempts to matplotlib.interactive(True) didn't bring anything, Hi Andrew, From which environment are you trying to run the example? In the terminal, from within some IDE, inside a jupyter notebook? Are you sure the script "is hanging on plt.plot(t, s)" and not after that? Best, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
[issue31756] subprocess.run should alias universal_newlines to text
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- nosy: -wolma ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14465] xml.etree.ElementTree: add feature to prettify XML output
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue14465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31756] subprocess.run should alias universal_newlines to text
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28286] gzip guessing of mode is ambiguous
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Textwrap doesn't honour NO-BREAK SPACE
On 29.09.2017 11:05, Wolfgang Maier wrote: On 29.09.2017 07:25, Steve D'Aprano wrote: I'm pretty sure this is a bug. Yes, it is a bug, but a known one: https://bugs.python.org/issue20491 The fix got backported even to 3.5, but I guess it depends which minor version you are running. I'm pretty sure that explains why people report different outcomes. Best, Wolfgang To be specific, this should be fixed from 3.5.3 and 3.6.0b3 onwards. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple board game GUI framework
On 11.09.2017 12:58, Paul Moore wrote: I'm doing some training for a colleague on Python, and I want to look at a bit of object orientation. For that, I'm thinking of a small project to write a series of classes simulating objects moving round on a chess-style board of squares. I want to concentrate on writing the classes and their behaviour, and not on display issues, but I would like it if the resulting program was reasonably interesting. To that end, I was thinking of putting together a frontend that displayed the objects moving round on a board (rather than, for example, just printing out lists of co-ordinates). I'd build the frontend, then my student could write the object classes and drop them into the framework. Maybe not exactly what you are asking for, but something I thought about for a Python class earlier this year: There are several Minecraft mods that let you interact with the game from Python. Of course, Minecraft itself is Java code, but it's a prime example of OOP and you are getting a very sophisticated and fully tested display engine for free. It's a bit complicated to get started with (which eventually made me postpone this experiment to next year's class), but I think it may be a lot of fun, especially if you've played Minecraft before. Here's a link to get you started: http://www.instructables.com/id/Python-coding-for-Minecraft/ Best, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
On 08/10/2017 04:28 PM, Steve D'Aprano wrote: Every few years, the following syntax comes up for discussion, with some people saying it isn't obvious what it would do, and others disagreeing and saying that it is obvious. So I thought I'd do an informal survey. What would you expect this syntax to return? As one of the people who have suggested this or similar syntax once I hope I'm not too far off a potential consensus :) [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5] [1, 2, 3] For comparison, what would you expect this to return? (Without actually trying it, thank you.) [x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5] [1, 2, 3, 4, 5] How about these? [x + y for x in (0, 1, 2, 999, 3, 4) while x < 5 for y in (100, 200)] [100, 200, 101, 201, 102, 202] [x + y for x in (0, 1, 2, 999, 3, 4) if x < 5 for y in (100, 200)] [100, 200, 101, 201, 102, 202, 103, 203, 104, 204] Thanks for your comments! -- https://mail.python.org/mailman/listinfo/python-list
Re: Write this accumuator in a functional style
On 07/11/2017 08:11 AM, Steven D'Aprano wrote:
I have a colleague who is allergic to mutating data structures. Yeah, I
know, he needs to just HTFU but I thought I'd humour him.
Suppose I have an iterator that yields named tuples:
Parrot(colour='blue', species='Norwegian', status='tired and shagged out')
and I want to collect them by colour:
accumulator = {'blue': [], 'green': [], 'red': []}
for parrot in parrots:
accumulator[parrot.colour].append(parrot)
That's pretty compact and understandable, but it require mutating a bunch
of pre-allocated lists inside an accumulator. Can we re-write this in a
functional style?
The obvious answer is "put it inside a function, then pretend it works by
magic" but my colleague's reply to that is "Yes, but I'll know that its
actually doing mutation inside the function".
Help me humour my colleague.
Hmm, isn't this just asking for itertools.groupby on the parrots sorted
by colour?
--
https://mail.python.org/mailman/listinfo/python-list
[issue27268] Incorrect error message on float('')
Wolfgang Maier added the comment: Could somebody turn this into a PR to move things forward? I guess Nofar mistakenly set resolution to "works for me", but meant "patch works for me"? -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Transitioning from Linux to Windows
On 03.06.2017 15:44, chitt...@uah.edu wrote:
I am looking for suggestions, ideas.
I have developed python (3.6.x, 2.7.x) scripts that run well as a user on an
ubuntu/16.04 system - the scripts look for files, parses the files, assembles
an output for the user.
I first cd into a particular directory on the system (where I know the files
exist) and run the script - the final result is in my working directory.
What I am now trying to do is ... figure out the least painful way to have
other users do the same - BUT sitting in front of a Windows desktop (7 or 10).
Ideally, I would like to set up the user on their Windows 7/10 system so that they can
"login" to the ubuntu system (say putty) - change working directory (to where
desired) - run the script (on the ubuntu system) - and scp the file back to the windows
desktop.
("porting" the ubuntu script to anaconda(3) on the windows desktop IS possible (but it
has not been as easy as I had hoped!) (django and programs like that do seem to provide a
"GUI" to have python scripts run on ubuntu/systems - but the setup looks
mysterious/complicated (to me anyway))
I stumbled onto "paramiko" - is that a possible answer?
Any suggestion/ideas would be greatly appreciated!
(I am perfectly willing to stick to 3.6.x, unless there is a clean/easy
solution using 2.7.x)
krishnan
An alternative to writing your own server app using django, though
admittedly less exciting from a developer's point of view, could be
x2goclient/server (http://wiki.x2go.org/doku.php/start). That would be
more like your putty suggestion, but a lot more user-friendly.
Wolfgang
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python not able to find package but it is installed
On 05/30/2017 09:27 PM, Mahmood Naderan via Python-list wrote: Well yes. It looks in other folders But $ find /opt -name openpyxl /opt/rocks/lib/python2.6/site-packages/openpyxl So, your pip knows about a search path that python doesn't know. That can have a number of reasons still and one would be Pavol's suggestion that your pip command may run on a different python than the python you invoke with the commmand 'python'. However, this would require that you have two separate installs of python2.6 on your system, which sounds rather unlikely. Another possibility is that pip picks up additional directories from a pip config file somewhere. To check this you could compare pip show openpyxl to pip show --isolated openpyxl (which would ignore any pip config file or environment variable) or (since I don't remember what commands your rather old version of pip will support): pip list vs pip list --isolated (which should give all installed packages pip knows about with and without additional config settings. Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Python not able to find package but it is installed
On 05/30/2017 10:18 AM, Mahmood Naderan via Python-list wrote: Hello, Although I have installed a package via pip on a centos-6.6, python interpreter still says there is no such package! Please see the output below $ python exread2.py input.xlsx tmp/output Traceback (most recent call last): File "/home/mahmood/excetest/exread2.py", line 1, in from openpyxl import load_workbook ImportError: No module named openpyxl $ pip install openpyxl DEPRECATION: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of pip will drop support for Python 2.6 Requirement already satisfied: openpyxl in /opt/rocks/lib/python2.6/site-packages ... In addition to checking sys.path as suggested, also try running python -V to check if it's Python2.6 as reported by pip or if you have two different versions of Python installed. -- https://mail.python.org/mailman/listinfo/python-list
[issue30413] Add fnmatch.filterfalse function
Wolfgang Maier added the comment: Yet another thing I just realized (sorry for being so annoying): With os.normcase calling os.fspath in 3.6+ it is not really a NOP anymore even on posix. As a consequence, you can now do some weird things with fnmatch: in all cases, and only in these, where the module *does* call normcase you can pass in Path-like objects as the names. This works with fnmatch.fnmatch on all platforms, never for fnmatchcase, and platform-dependently (on Windows, but not on posix platforms) for filter/filterfalse. It's mostly that last case that worries me because it makes it easy to accidentally write code that is not platform-independent. Also note that you can also pass a Path-like object as pat everywhere except in fnmatchcase. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30413] Add fnmatch.filterfalse function
Wolfgang Maier added the comment: > Good catch! It seems to me that they are redundant. Please open a new issue > for this. done: issue 30427 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30427] isinstance checks in os.path.normcase redundant with os.fspath
Wolfgang Maier added the comment: Just created a PR for this, which eliminates the redundancy. This also changes the error message (making it less specific), but not the type of a raised exception. If you think that the error message deserves to be preserved that could, of course, be done too. -- type: -> performance ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30427] isinstance checks in os.path.normcase redundant with os.fspath
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- pull_requests: +1803 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30427] isinstance checks in os.path.normcase redundant with os.fspath
New submission from Wolfgang Maier: os.path.normcase as defined in both posixpath and ntpath is now calling os.fspath on its argument first. With that I think the following isinstance(str, bytes) checks have become redundant since AFAIU os.fspath is guaranteed to return either str or bytes instances. -- components: Library (Lib) messages: 294130 nosy: wolma priority: normal severity: normal status: open title: isinstance checks in os.path.normcase redundant with os.fspath versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30413] Add fnmatch.filter_false function
Wolfgang Maier added the comment: @serhiy: my bad! I just hadn't realized this behavior of the original. With this requirement I cannot see any simpler solution than Steven's. Some other questions though to everyone involved: 1) what do you think about "os.path is posixpath" vs just checking os.name == 'posix' as I suggested earlier? 2) speaking of missing functionality in filter: What do you think of a keyword argument like 'case' to both filter and filterfalse that, when True, would make these functions behave equivalently to [n for n in names if fnmatchcase(n, pattern)] The default would be False, of course. I know this would be inconsistent in terms of argument vs separate functions, but it is easy to explain and learn and without it Windows users of filter/filterfalse would really suffer from the much poorer performance due to the slow normcase call (even slower now with the new fspath protocol) even if they pass in normalized names already. 3) not directly related to this issue, but I came across it in this context: isn't normcase in both posixpath and ntpath doing isinstance(str, bytes) checks that are redundant with os.fspath? Is this oversight or am I missing something again? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30413] Add fnmatch.filter_false function
Wolfgang Maier added the comment: Does it? I thought it does so only if normalize_case is True. Did I miss something? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30413] Add fnmatch.filter_false function
Wolfgang Maier added the comment: Hi, seems I had the same thoughts as you, Steven. I had started working on a patch independently yesterday, but after making my changes to fnmatch itself, I found I had too many other things to do to address unittests and doc changes to turn this into a real patch - so thank you for spending time on all of this. I just downloaded your patch and merged it with mine because I think my version of fnmatch.py may be simpler and slightly faster (though like you I didn't run performance tests). Feel free to do whatever you like with this alternate version - it's not that there is much new in it to take credit for :) Another thing I noted: fnmatch takes a rather unusual approach to determine whether normcase is NOP or not. It imports posixpath only to see if it is the same as os.path. That looks pretty weird and wasteful to me (especially if you are running this on Windows and are effectively importing posixpath just for fun then). I think it would be better to just check os.name instead (like pathlib does for example). I moved the corresponding check to the top of the module to make this easier to address, should that be of interest. I'm also using the result of the check in fnmatch.fnmatch because I don't see any reason why you wouldn't want to benefit from it there as well. -- nosy: +wolma Added file: http://bugs.python.org/file46880/filterfalse.alternate_patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30307] https://docs.python.org/3/tutorial/introduction.html#strings Section 3.1.2 doc issue
Wolfgang Maier added the comment: The section is correct as it is. Just try it in the interactive interpreter to convince yourself. -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: How to update python from 3.5.2 to 3.5.3 on Linux
On 03.05.2017 17:11, Thomas Nyberg wrote: On 05/03/2017 11:04 AM, Daiyue Weng wrote: nope, I was thinking it might be good to update to 3.5.3 for security reasons? (CCing back in python-list since I accidentally dropped it.) I wouldn't worry about it. Package managers tend to usually take care of security updates. (Of course there is criticism of Linux Mint saying they're not as great at this...) Looking at Ubuntu 16.04, they are still on 3.5.1 (plus Ubuntu's own patches): http://packages.ubuntu.com/xenial/python3 Maybe I'm mistaken here, but I don't think that is fully true. With an LTS version of Ubuntu you I don't think you will *ever* get upgraded to a new Python version. Instead Canonical will backport changes from new maintainance releases like 3.5.2/3.5.3 to older releases of the same minor version (like the 3.5 series). So while the package for Python3.5 for Ubuntu 16.04 will seem pinned at version 3.5.1 over the lifetime of the OS, the actual Python version you are running may be newer. In fact, on my 16.04: % apt list python3 python3/xenial,now 3.5.1-3 amd64 [installed] % python3 -V Python 3.5.2 I have no clue how Mint handles this though. Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
[issue30152] Reduce the number of imports for argparse
Wolfgang Maier added the comment: @rhettinger: I do not quite understand this harsh reaction. Making argparse more responsive could, in fact, be quite a nice improvement. This is particularly true, I guess, if you want argument completion with a package like https://pypi.python.org/pypi/argcomplete. You have a point that the patch probably tries to optimize too many things in too many places at once, but that could be amended rather easily. The idea of delaying imports in argparse itself to when they are actually needed is a really good one and, for this module, it is also very reasonable that other places in the stdlib only import it when they are run as __main__. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30152] Reduce the number of imports for argparse
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30097] Command-line option to suppress "from None" for debugging
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>: -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python 3.5+ Arrow keys and others in the console
On 16.04.2017 10:56, Vincent Vande Vyvre wrote: Hi, I'm using Python 3.5 and 3.6 in venv and I see a strange behaviour in the interactive interpreter. The arrow keys can't be used to move the cursor into the current line of code or to rewrite the last lines. With the 3.5 I can use the backspace and erase the code but not in 3.6 Python 3.5.2 (default, Dec 19 2016, 11:46:33) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. f = "kjhfgt"^[[D# Left Arrow Key ^[[A# Up Arrow Key Python 3.6.1 (default, Apr 12 2017, 11:39:17) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. f = "lkjgh" ^[[A^[[B# Up Arrow Key and Backspace Key File "", line 1 ^ SyntaxError: invalid syntax Make sure you build Python (I guess you did this for 3.6, but are probably using your OS Python3.5) with readline. This needs the dev version of the readline library installed at build time. So, step 1 would be to get the library, then rebuild Python3.6 by running: 1) make clean 2) ./configure 3) make It could be worthwhile checking for other missing optional C libraries first though. If you want to make sure you have all of them, follow the steps described here: https://docs.python.org/devguide/setup.html#build-dependencies Best, Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
[issue25478] Consider adding a normalize() method to collections.Counter()
Wolfgang Maier added the comment: > >>> Counter(red=11, green=5, blue=4).normalize(100) # percentage > Counter(red=55, green=25, blue=20) I like this example, where the normalize method of a Counter returns a new Counter, but I think the new Counter should always only have integer counts. More specifically, it should be the closest approximation of the original Counter that is possible with integers adding up to the argument to the method or, statistically speaking, it should represent the expected number of observations of each outcome for a given sample size. -- nosy: +wolma ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29770] Executable help output (--help) at commandline is wrong for option -B
Wolfgang Langner added the comment: Thanks for fixing this so fast. Good work. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
