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
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/issue34
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/issue34
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 w
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
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.
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
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
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
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 qu
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.pyt
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 doc
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.
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
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
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
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.pyt
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
&g
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
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 inheritanc
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
pull_requests: +6015
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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
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 t
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
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,
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
>
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
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 pointi
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
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 no
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 retur
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
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: -wolma
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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 <
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
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
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
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
pull_requests: +1803
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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 jus
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/i
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
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/i
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
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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
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
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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
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 discussio
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
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
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
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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.or
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.pyt
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
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
Wolfgang Maier added the comment:
Mark, PEP479 is not fully in effect in 3.6 yet. 3.7 will raise the
RuntimeError, but 3.6 still only gives a DeprecationWarning.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Wolfgang Maier added the comment:
Isn't the difference between generator expressions and comprehensions what's
dealt with by PEP479? So it seems this issue is outdated enough to deserve
being closed?
--
nosy: +wolma
___
Python tracker <
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Wolfgang Maier added the comment:
> Ah. Something like self._interpolation.before_get(self, section, option,
> value, d) could be better written as
> self._interpolation.before_get(parser=self, ...)
Yep, that's roughly what I was trying to explain.
> I still don't grock the a
Wolfgang Maier added the comment:
Ah, that's kind of confusing at first!
the 'self' in the method calls (like on line 796) refers to the ConfigParser
instance and will be bound to the parser parameter. The first parameter, the
'self' in the interpolation method definition, is not provided
Wolfgang Maier added the comment:
Ah, I just found Issue607668, which discusses the changeset 2e7fe55c0e11 that
introduced IOError suppression. The actual use case at the time was different
and I have no idea whether it would still be a problem today
Wolfgang Maier added the comment:
Hi Julius,
I guess it's a question of control and responsibilities.
If you write a program that may issue warnings under some conditions, that
program may, for example, be used with stderr redirected to a file. Now it is
possible that file gets removed while
Wolfgang Maier added the comment:
Before I forget again what I've gathered yesterday about this issue, here's a
summary of the problem:
When the the first element of args or the executable argument of
subprocess.Popen does not specify an absolute path, the way the executable gets
discovered
Wolfgang Maier added the comment:
Ping. This still isn't fixed several years later, i.e., the documentation still
describes the POSIX, but not the Windows behavior.
See also issue20927, which reports this as a bug.
--
nosy: +wolma
versions: +Python 3.5, Python 3.6, Python 3.7 -Python
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Wolfgang Maier added the comment:
Issue23016 fixed the "AttributeError: 'NoneType' object has no attribute
'write'" problem when sys.stderr is None.
With that it's now possible and good practice to set sys.stderr = None when
closing it, just as Antoine suggested.
Should this issue
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Wolfgang Maier added the comment:
Well, you *can* change the value at runtime as you are demonstrating in your
script, but you are misunderstanding the effect this will have. It *won't*
cause a reevaluation of an already parsed config file. Instead it will affect
the writing of the parsed
Wolfgang Maier added the comment:
try this:
parser.add_argument('file', nargs='?', default = argparse.SUPPRESS)
I don't think this is a bug. The default for the default parameter is None so
the behavior is consistent with the documentation.
--
nosy: +wolma
Wolfgang Maier added the comment:
No, I don't think the numeric tower ABC should be replaced by duck-typing. One
of the very reasons the fractions module exists is that it showcases how to use
the numeric tower. If you want a class to be picked up as a Rational it should
be registered
Wolfgang Maier added the comment:
sure, I just happened to have the profiling available since I used it to
optimize things. Here's similar microbenchmarks using perf:
STRINGS
===
$ python -m perf timeit -s "from fractions import Fraction"
"Fract
New submission from Wolfgang Maier:
I've spent a bit of time lately trying to optimize the instantiation of
Fractions. This is related to Issue22464, but instead of focusing on
constructing Fractions from ints, my attempts revolve around improving
instantiation from strings, floats
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Wolfgang Maier added the comment:
@serhiy.storchaka you've beaten me by a few minutes (still waiting for the test
suite to finish). Your patch is "contaminated" by an additional change in
collections/__init__.py though so I'm still uploading my version (which also
tries to stic
Wolfgang Maier added the comment:
STINNER Victor added the comment:
>BUT when Python is started from a virtual environment (created by the
>"venv" module), the re module is important by default.
>
>haypo@speed-python$ venv/bin/python3 -c 'import sys; print("re" in
Changes by Wolfgang Maier <wolfgang.ma...@biologie.uni-freiburg.de>:
--
nosy: +wolma
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Wolfgang Maier added the comment:
A warning like this sounds good to me though I'd prefer it to be slightly more
verbose, like:
"RuntimeWarning: '' found in sys.modules after import of package
'', but prior to execution of '' as '__main__'; this may
result in unpredictable beha
Wolfgang Maier added the comment:
@Martin and regarding Python3.3: Right, you cannot do the replacement when
running the module as __main__. For my use case that's not required though so
in
the module I can just do:
if __name__ == '__main__':
print('running module as a script')
else
New submission from Wolfgang Maier:
As a result of Issue14285 Python 3.5.2 now imports packages in runpy.
_get_module_details before calling importlib.util.find_spec.
Although I'm not sure how important this is, I wanted to report that this new
behaviour can have a side-effect under pretty
Wolfgang Maier added the comment:
Given your comment about sum((fullacount & fullbcount).values()), why not use
its in-place version:
fullacount &= fullbcount
matches = sum(fullacount.values())
?
--
nosy: +wolma
___
Python trac
Wolfgang Maier added the comment:
ping?
Just ran into this issue on OS X El Capitan with Region set to Germany and
Language to English. Just as Ned pointed out 2 years ago, this results in
LC_CTYPE set to 'UTF-8' in the terminal and docutils still can't cope with it.
--
nosy: +wolma
Wolfgang Maier added the comment:
> Hum, python3 looks faster on this dummy microbenchmark yeah. Who said that
> Python 3 is slower? :-)
If you're alluding to that seemingly endless thread over on python-list, let me
say that it is not my motivation to start anything like that here.
Wolfgang Maier added the comment:
Ah, but it's not that format() is slower in 3.5, but that %-formatting got
faster.
It looks as if it got optimized and I was wondering whether the same
optimization could be applied to format().
--
___
Python
Wolfgang Maier added the comment:
Your two suggestions prompted me to do a speed comparison between them and the
result surprised me.
I tried:
import random
nums = [random.randint(0, 255) for n in range(1000)]
then timed the simple:
for n in nums:
hx = '%X' % n # or hx = format(n
Wolfgang Maier added the comment:
oh and documentation is here:
https://docs.python.org/3.5/library/stdtypes.html?highlight=bytes.splitlines#bytes.splitlines
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
1 - 100 of 208 matches
Mail list logo
