Re: Spread a statement over various lines

[Wolfgang Maier]

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

[issue34232] Python3.7.0 exe installers (32 and 64 bit) failing on Windows7

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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!

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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?

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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`

[Wolfgang Maier]

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

[Wolfgang Maier]

On 11/02/2017 12:45 PM, Alberto Berti wrote:

"Steve" == Steve D'Aprano  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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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]

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]

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]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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]

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]

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]

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]

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

[Wolfgang Maier]

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]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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

[Wolfgang Maier]

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]

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

[issue29258] __init__.py required for pkgutil.walk_packages in python3

[Wolfgang Maier]

Wolfgang Maier added the comment:

> all that's required here is to eliminate the check for __init__.py from 
> pkgutil._iter_file_finder_modules

Ok, I was exaggerating here. To do it right would require a more complex 
change, but that's all that's needed to get an estimate of the effect the real 
thing would have.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29258>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29258] __init__.py required for pkgutil.walk_packages in python3

[Wolfgang Maier]

Wolfgang Maier added the comment:

While it is rather trivial to implement the proposed functionality - all that's 
required here is to eliminate the check for __init__.py from 
pkgutil._iter_file_finder_modules - this would have undesired impacts on, e.g., 
pydoc.apropos:
This function would then recursively report *any* directory/subdirectory on 
sys.path, which is quite surely not what people want.

I think this is a fundamental problem with namespace packages: they are nice 
and flexible for specific imports, but they make it impossible to know whether 
a directory found on the filesystem is *intended* as a Python package or not.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29258>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19821] pydoc.ispackage() could be more accurate

[Wolfgang Maier]

Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:


--
nosy: +wolma

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19821>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17062] An os.walk inspired replacement for pkgutil.walk_packages

[Wolfgang Maier]

Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:


--
nosy: +wolma

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17062>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29258] __init__.py required for pkgutil.walk_packages in python3

[Wolfgang Maier]

Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:


--
nosy: +wolma

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29258>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29769] pkgutil._iter_file_finder_modules should not be fooled by *.py folders

[Wolfgang Maier]

New submission from Wolfgang Maier:

The current implementation of _iter_file_finder_modules parses folders with a 
valid Python module extension as modules (e.g. it would report a *folder* xy.py 
as a module xy).
As a result, e.g., pydoc.apropos('') fails if such a folder is found anywhere 
on sys.path.

I'm attaching a patch that fixes this and also brings a few minor improvements 
(like using a set instead of a dict with 1 values and reusing the function in 
ImpImporter).

However, I have a question about it (which is also the reason why I didn't turn 
this into a PR right away): in addition to checking that an item detected as a 
module is not a directory, I think it would be good to also check that an 
__init__ module inside a possible package really is a file. If I uncomment the 
respective check in the patch though, I'm getting a test_pydoc failure because 
the test creates a package directory with no access to contained file 
attributes. So even though there is an __init__.py file in the package dir the 
isfile() check fails. I think that should, in fact, happen and the pydoc test 
is wrong, but apparently whoever wrote the test had a different opinion.
Any thoughts?

--
components: Library (Lib)
files: pkgutil.patch
keywords: patch
messages: 289285
nosy: ncoghlan, wolma
priority: normal
severity: normal
status: open
title: pkgutil._iter_file_finder_modules should not be fooled by *.py folders
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file46714/pkgutil.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29769>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15343] "pydoc -w " writes out page with empty "Package Contents" section

[Wolfgang Maier]

Wolfgang Maier added the comment:

Sorry, for generating noise on this very old issue, but was there a specific 
reason to duplicate the code of ImpImporter.find_module in changeset 
9101eab6178c instead of factoring it out?

--
nosy: +wolma

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15343>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29710] Incorrect representation caveat on bitwise operation docs

[Wolfgang Maier]

Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:


--
nosy: +wolma

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29710>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29414] Change 'the for statement is such an iterator' in Tutorial

[Wolfgang Maier]

Wolfgang Maier added the comment:

> [...] I prefere the chapter as it currently is, because IMHO it
> introduces the concepts more gradually than your proposal.

That's ok! It's your PR and I only wanted to show an alternative.
I was hoping for a bit more people to provide feedback though.

The main reason I'm interested in changes to the tutorial is because
I'm teaching Python to undergraduates (not in CS, but in Biology) and
I recommend them to work through the Tutorial alongside the course so
I have a natural interest in its quality and really appreciate any
improvement, which I think your PR is certainly offering :)

Let me still comment on some of your points regarding my suggestion:

> In addition the modification of the title section from "for
> Statements" to "for Loops" IMHO makes the title not consistent with
> the other section titles.

I don't see this point. The other section titles are not about loops.
The preceding chapter introduces while loops as a loop, not a
statement, and this chapter talks about while and for loops further
down the page. 

>> - restructured the for loop section to discuss Python for loops
>> first and only compare them to Pascal/C afterwards
> +0. I think for a reader who is coming from another language is better
> to have the current introduction. But maybe it is not the same for a
> reader who is learning Python as a first programming language.

I don't agree with you on this. I'm coming from a C background myself,
but if I want to learn a new language the first thing I'm interested in
is not how it's *not* working, but how it does.
Plus, it's 2017, Perl has foreach, Javascript has at least
array.foreach and even C++11 has auto-iteration over collections so starting an 
explanation of for loops with 'hey, look Python is different 
from two > 40 years old languages' feels a bit outdated.

Regarding my main point of removing most of the ranges section it is
possible I went a bit too far with that and maybe one should still
briefly mention the optional start argument and stress that stop is not
included in the range, but my seealso is quite prominent and the linked
section on range is pretty good.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29414>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29414] Change 'the for statement is such an iterator' in Tutorial

[Wolfgang Maier]

Wolfgang Maier added the comment:

I studied the github PR and thought about it carefully, and that made me come 
to believe that the chapter deserves a larger rewrite not just of one section, 
but of several.
I'm attaching my proposed change as a "classical" patch here for discussion. I 
hope that's still a valid way to do this as I did not want to mess with the 
original PR by Marco and, instead, wanted to see my proposal discussed first.

Some of the changes I made:
- I don't think range() really deserves its own section in a chapter about 
control flow, so I removed most of it and linked to the relevant stdtypes 
section instead
- moved the definition of an iterable up into the for loop section
- restructured the for loop section to discuss Python for loops first and only 
compare them to Pascal/C afterwards
- moved the example for modifying a list while iterating over it to the 
datastructures chapter

I find this new version much clearer, but lets see what people here think.

--
nosy: +wolma
Added file: http://bugs.python.org/file46681/controlflow_datastructures.patch

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29414>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Disallowing instantiation of super class

[Wolfgang Maier]

On 24.02.2017 01:19, Irv Kalb wrote:

Hi,
I have built a set of three classes:
-  A super class, let's call it: Base

-  A class that inherits from Base, let's call that: ClassA

-  Another class that inherits from Base, let's call that: ClassB

ClassA and ClassB have some code in their __init__ methods that set some 
instance variables to different values.  After doing so, they call the the 
__init__ method of their common super class (Base) to set some other instance 
variables to some common values.  This all works great.  Instances of ClassA 
and ClassB do just what I want them to.



[...]


If I can find a way to determine that the caller is attempting to instantiate 
Base directly, I will raise an exception.



A pattern I'm using sometimes to achieve this is:

class Base:
def __init__(self):
self.set_common()
self.set_specific()

def set_common(self):
self.a = 10

def set_specific(self):
raise NotImplementedError()


class A(Base):
def set_specific(self):
self.b = 20


class B(Base):
def set_specific(self):
self.b = 30


Of course, MRAB's and Peter's suggestion are very similar ideas.

--
https://mail.python.org/mailman/listinfo/python-list

Re: PTH files: Abs paths not working as expected. Symlinks needed?

[Wolfgang Maier]

On 15.02.2017 13:42, poseidon wrote:

On 15/02/17 12:16, Wolfgang Maier wrote:

On 15.02.2017 10:33, poseidon wrote:

In /usr/lib/python3.6/site-packages I wrote a file tau4.pth. It contains
the line

/home/poseidon/tau4/swr/py3/src

In /home/poseidon/tau4/swr/py3/src there's an __init__.py file, so it
should be possible to write

import tau4

in my programs.



No, that's not what you should expect!
A path file contains paths to be added at interpreter startup to the
package/module search path stored in sys.path. That is, in your example,
if you put a file tau4.py or a tau4 directory with the __init__.py file
inside into /home/poseidon/tau4/swr/py3/src, *then* you could import
tau4.


It works, if I set a symlink to /home/poseidon/tau4/swr/py3/src in the
site-packages dir:

ln -s /home/poseidon/tau4/swr/py3/src
/usr/lib/python3.6/site-packages/tau4



Well this works because now Python finds (following the symlink) a tau4
package (i.e., a directory with that name and an __init__.py file
inside) in /usr/lib/python3.6/site-packages. The .pth file is not
involved in this at all.



Yes, removed it (symlink still there) and it still works. But then, what
are pth files for? I'd just place a symlink to the package and am done
with. The path doesn't seem to be needed in sys.path (where it would go
if placed in a pth file). If I write

from tau4 import datalogging

that works, too. So no need for the path being in sys.path (i.e. in a
pth file)?



I guess a major point of .pth files is that you only have one or a small 
number of files with a clear purpose polluting the containing directory. 
Of course, you could put symlinks to all your packages and modules into 
site-packages, but what's the point of putting them somewhere else in 
the first place? Also, you cannot create symlinks across devices, but 
.pth files will work.


Best,
Wolfgang

--
https://mail.python.org/mailman/listinfo/python-list

Re: PTH files: Abs paths not working as expected. Symlinks needed?

[Wolfgang Maier]

On 15.02.2017 10:33, poseidon wrote:

In /usr/lib/python3.6/site-packages I wrote a file tau4.pth. It contains
the line

/home/poseidon/tau4/swr/py3/src

In /home/poseidon/tau4/swr/py3/src there's an __init__.py file, so it
should be possible to write

import tau4

in my programs.



No, that's not what you should expect!
A path file contains paths to be added at interpreter startup to the 
package/module search path stored in sys.path. That is, in your example, 
if you put a file tau4.py or a tau4 directory with the __init__.py file 
inside into /home/poseidon/tau4/swr/py3/src, *then* you could import tau4.



It works, if I set a symlink to /home/poseidon/tau4/swr/py3/src in the
site-packages dir:

ln -s /home/poseidon/tau4/swr/py3/src /usr/lib/python3.6/site-packages/tau4



Well this works because now Python finds (following the symlink) a tau4 
package (i.e., a directory with that name and an __init__.py file 
inside) in /usr/lib/python3.6/site-packages. The .pth file is not 
involved in this at all.



https://docs.python.org/3.6/library/site.html suggests that PTH files
only work relative to the site-packages dir. But digging around in e.g.
StackOverflow I got the impression that absolute paths should work as
well. If so, what am I doing wrong?

I'm on Arch Linux, Python 3.6.

Kind regards
Paul




--
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess problem

[Wolfgang Maier]

On 09.02.2017 01:56, Andreas Paeffgen wrote:

The Problem with the subprocess code is: Using the sourcecode
functioning as normal.
The frozen app with cx_freeze on every platform just returns an empty
result

Here is the code in short:
def get_path_pandoc():




   settings = QSettings('Pandoc', 'PanConvert')

   path_pandoc = settings.value('path_pandoc','')




   if not os.path.isfile(path_pandoc):




   if platform.system() == 'Darwin' or os.name == 'posix':

   args = ['which', 'pandoc']

   p = subprocess.Popen(

   args,

   stdin=subprocess.PIPE,

   stdout=subprocess.PIPE)




   path_pandoc =
str.rstrip(p.communicate(path_pandoc.encode('utf-8'))[0].decode('utf-8'))


The whole problematic code can be checked on
http://github.com/apaeffgen/panconvert
in source/converters/interface_pandoc.py



Checking your repo I found that get_path_pandoc, the function from which 
you took the code snippet above, will always return None if 
os.path.isfile(path_pandoc).


This is probably not what you are intending. Do you know if path_pandoc 
is maybe set to an existing file in your frozen code already so the 
whole 'which' or 'where' branch is never executed?


Best,
Wolfgang

--
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess problem

[Wolfgang Maier]

On 09.02.2017 01:56, Andreas Paeffgen wrote:

The Problem with the subprocess code is: Using the sourcecode
functioning as normal.
The frozen app with cx_freeze on every platform just returns an empty
result

Here is the code in short:
def get_path_pandoc():




   settings = QSettings('Pandoc', 'PanConvert')

   path_pandoc = settings.value('path_pandoc','')




   if not os.path.isfile(path_pandoc):




   if platform.system() == 'Darwin' or os.name == 'posix':

   args = ['which', 'pandoc']

   p = subprocess.Popen(

   args,

   stdin=subprocess.PIPE,

   stdout=subprocess.PIPE)




   path_pandoc =
str.rstrip(p.communicate(path_pandoc.encode('utf-8'))[0].decode('utf-8'))


The whole problematic code can be checked on
http://github.com/apaeffgen/panconvert
in source/converters/interface_pandoc.py



Checking your repo I found that get_path_pandoc, the function from which 
you took the code snippet above, will always return None if 
os.path.isfile(path_pandoc).


This is probably not what you are intending. Do you know if path_pandoc 
is maybe set to an existing file in your frozen code already so the 
whole 'which' or 'where' branch is never executed?


Best,
Wolfgang

--
https://mail.python.org/mailman/listinfo/python-list

Re: Rename file without overwriting existing files

[Wolfgang Maier]

On 01/30/2017 03:49 AM, Steve D'Aprano wrote:

This code contains a Time Of Check to Time Of Use bug:

if os.path.exists(destination)
raise ValueError('destination already exists')
os.rename(oldname, destination)


In the microsecond between checking for the existence of the destination and
actually doing the rename, it is possible that another process may create
the destination, resulting in data loss.

Apart from keeping my fingers crossed, how should I fix this TOCTOU bug?



There is a rather extensive discussion of this problem (with no good 
cross-platform solution if I remember correctly):


https://mail.python.org/pipermail/python-ideas/2011-August/011131.html

which is related to http://bugs.python.org/issue12741

Wolfgang

--
https://mail.python.org/mailman/listinfo/python-list

[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English

[Wolfgang Maier]

Wolfgang Maier added the comment:

I think PEP 538 extended to the UTF-8 locale *would* help here. Specifically, 
it would coerce only LC_CTYPE to en_US.UTF-8 (unless OS X has C.UTF-8), which I 
guess is good enough for the purpose here.

I do agree that it is not the kind of problem that PEP 538 tries to solve right 
now, but it could be extended to cover other types of problematic locales like 
this one. Just wanted to make you aware of this possibility.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English

[Wolfgang Maier]

Wolfgang Maier added the comment:

To me this issue seems quite related to PEP 538. Maybe the LC_CTYPE coercion 
proposed in the PEP could be extended to cover the case of LC_CTYPE=UTF-8?

--
nosy: +ncoghlan
versions: +Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Search a sequence for its minimum and stop as soon as the lowest possible value is found

[Wolfgang Maier]

On 1/6/2017 15:04, Peter Otten wrote:

Example: you are looking for the minimum absolute value in a series of
integers. As soon as you encounter the first 0 it's unnecessary extra work
to check the remaining values, but the builtin min() will continue.

The solution is a minimum function that allows the user to specify a stop
value:


from itertools import count, chain
stopmin(chain(reversed(range(10)), count()), key=abs, stop=0)

0

How would you implement stopmin()?



How about:

def stopmin (iterable, key, stop):
def take_until ():
for e in iterable:
yield e
if key(e) <= stop:
break
return min(take_until(), key=key)

?

--
https://mail.python.org/mailman/listinfo/python-list

[issue28956] return minimum of modes for a multimodal distribution instead of raising a StatisticsError

[Wolfgang Maier]

Wolfgang Maier added the comment:

What's the justification for this proposed change? Isn't it better to report 
the fact that there isn't an unambiguous result instead of returning a rather 
arbitrary one?

--
nosy: +steven.daprano, wolma
versions: +Python 3.7 -Python 3.5

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28956>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28859] os.path.mount sometimes raises FileNotFoundError on Windows

[Wolfgang Maier]

Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:


--
nosy: +wolma

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28859>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18971] Use argparse in the profile/cProfile modules

[Wolfgang Maier]

Wolfgang Maier added the comment:

oops, typing in wrong window. Very sorry.

--
nosy: +wolma
title: calendar -> Use argparse in the profile/cProfile modules

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18971>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18971] calendar

[Wolfgang Maier]

Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:


--
title: Use argparse in the profile/cProfile modules -> calendar

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18971>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15533] subprocess.Popen(cwd) documentation

[Wolfgang Maier]

Wolfgang Maier added the comment:

Just found issue15451, which reports a similar inconsistency between Windows 
and POSIX for 'PATH' provided through the Popen env parameter as for cwd. It 
seems that, on POSIX-platforms, the PATH environment variable passed through 
env affects the executable lookup if executable does *not* contain a dirname, 
but on Windows the new PATH never affects executable lookup. So, again, 
relative executable paths are causing platform-specific behavior.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15533>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14845] list() != []

[Wolfgang Maier]

Wolfgang Maier added the comment:

running with "-W always":

>>> def five(x):
... for _ in range(5):
... yield x
... 

>>> F = five('x')

>>> [next(F) for _ in range(10)]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1, in 
StopIteration

>>> list(next(F) for _ in range(10))
__main__:1: DeprecationWarning: generator '' raised StopIteration
[]

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14845>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com