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
<
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue29710>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 an
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue29258>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue17062>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue19821>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 estim
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
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue30097>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue30152>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
<http://bugs.python.org/issue30
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:
Does it? I thought it does so only if normalize_case is True.
Did I miss something?
--
___
Python tracker
<http://bugs.python.org/issue30
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&qu
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
Changes by Wolfgang Maier :
--
pull_requests: +1803
___
Python tracker
<http://bugs.python.org/issue30427>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
<http://bugs.python.org/i
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
New submission from Wolfgang Maier :
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,
Wolfgang Maier added the comment:
On 03/20/2018 04:38 PM, Anthony Sottile wrote:
>
> Anthony Sottile 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 t
Wolfgang Maier 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 mi
New submission from Wolfgang Maier :
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
Wolfgang Maier 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 us
Wolfgang Maier added the comment:
Thanks, Raymond. I'll do that once I've addressed Serhiy's points.
--
___
Python tracker
<https://bugs.pyt
Change by Wolfgang Maier :
--
pull_requests: +6015
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33144>
___
___
Python-bugs-list mai
Wolfgang Maier 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
Wolfgang Maier 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
New submission from Wolfgang Maier :
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
Change by Wolfgang Maier :
--
keywords: +patch
pull_requests: +6050
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33203>
___
___
Py
Wolfgang Maier added the comment:
ok, I've created issue 33203 to deal with raising ValueError in _randbelow
consistently.
--
___
Python tracker
<https://bugs.python.org/is
Wolfgang Maier 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
Wolfgang Maier 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. I
Wolfgang Maier 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
New submission from Wolfgang Maier :
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
Change by Wolfgang Maier :
--
keywords: +patch
pull_requests: +6093
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33228>
___
___
Py
Wolfgang Maier 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
Wolfgang Maier added the comment:
sorry, should have been issue 24567, of course.
--
___
Python tracker
<https://bugs.python.org/issue33228>
___
___
Python-bug
Wolfgang Maier 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 tr
Wolfgang Maier added the comment:
Steven's commit here also fixed issue 24068.
--
nosy: +wolma
___
Python tracker
<https://bugs.python.org/issue25177>
___
___
Wolfgang Maier added the comment:
Fixed as part of resolving issue 25177.
--
resolution: -> fixed
stage: test needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<https://bugs.python.org/issue28286>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<https://bugs.python.org/issue31756>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<https://bugs.python.org/issue14465>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Wolfgang Maier :
--
nosy: -wolma
___
Python tracker
<https://bugs.python.org/issue31756>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Wolfgang Maier :
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
Wolfgang Maier 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'
Wolfgang Maier 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 r
Wolfgang Maier 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 tracke
Wolfgang Maier 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 thre
Wolfgang Maier 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
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
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
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
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
(6
New submission from Wolfgang Maier:
Hi,
I just noticed that version output generated via the
**'version' action** of the **argparse** module
is routed to stderr. I'd expect regular output to go to stdout instead.
The current behavior also seems inconsistent to me because --help
p
New submission from Wolfgang Maier:
The current documentation of the gzip module should have its section "12.2.1.
Examples of usage" updated to reflect the changes made to the module in
Python3.2 (https://docs.python.org/3.2/whatsnew/3.2.html#gzip-and-zipfile).
Currently, the recipe
Wolfgang Maier added the comment:
>> with open(src, 'rb') as f_in:
>> with gzip.open(dst, 'wb') as f_out:
>>shutil.copyfileobj(f_in, f_out)
+1 !!
exactly as fast as my suggestion (with compression and de-compression), but
Wolfgang Maier added the comment:
same speed is not surprising though as shutil.copyfileobj is implemented like
this:
def copyfileobj(fsrc, fdst, length=16*1024):
"""copy data from file-like object fsrc to file-like object fdst"""
while 1:
buf = fs
Wolfgang Maier added the comment:
ok, I've prepared the patch using the elegant shutil solution.
--
keywords: +patch
Added file: http://bugs.python.org/file34765/gzip_example_usage_patch.diff
___
Python tracker
<http://bugs.python.org/is
Wolfgang Maier added the comment:
I do not think this is a bug in the module, but rather incorrect usage.
>From your own docs:
data should be an iterable of Real-valued numbers, with at least one
value. The optional argument mu, if given, should be the mean of
the data. If it
Wolfgang Maier added the comment:
ok, there may be use cases for calculating a variance estimate in such
situations, but IMHO what you are trying to do is to abuse a function which is
not documented to be made for the purpose and then complain that it does not
behave correctly.
The
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue21204>
___
___
Python-bugs-list mailing list
Unsubscribe:
Wolfgang Maier added the comment:
well, buffering is not the issue here. It's that the file iterator used in the
current example is line-based, so whatever the buffer size you're doing
unnecessary inspection to find and split on line t
Wolfgang Maier added the comment:
>> - if an object is in the container that is equal to the object, it will be
>> slower, but not very much.
You don't know that in general. It depends on where in the sequence the equal
object sits, and also on how expensive the equality che
Wolfgang Maier added the comment:
I don't even know where to start with this.
a) this recipe is not working
b) it's hardly readable
c) it is pointless
Why are you complicating things by testing for != ?
What advantage does this offer over == ?
You do not need class methods
Wolfgang Maier added the comment:
that clarifies things, thanks.
I would still not usually go that way though as it means defining __ne__ with
no accompanying __eq__, which means that, in a simple case, you can't use == on
instances of your class and, in the case that your class inh
Wolfgang Maier added the comment:
> l=[myObj() for x in range(1)]
>
> now compare:
>
> >>> 1 in m # slowed down by myObj.__eq__
> False
>
> >>> any(e is 1 for e in m) # identity checks only
> False
oops, sorry for the inconsistency here.
th
Wolfgang Maier added the comment:
I ran into this issue right after 3.4 got released.
I solved it by adding
extra_compile_args=["-Wno-error=declaration-after-statement"]
as an argument to the Extension() call in the package's setup.py .
New submission from Wolfgang Maier:
The docs for Python3.4 havethis to say about the arguments to the dict
constructor:
class dict(**kwarg)
class dict(mapping, **kwarg)
class dict(iterable, **kwarg)
Return a new dictionary initialized from an optional positional argument
and a possibly
New submission from Wolfgang Maier:
I ran into this:
>>> gzout = gzip.open('test.gz','wb')
>>> gzout.write('abcdefgh') # write expects bytes not str
Traceback (most recent call last):
File "", line 1, in
gzout.write('abc
Wolfgang Maier added the comment:
ok, this seems to be really easy:
patch attached
--
keywords: +patch
Added file: http://bugs.python.org/file35323/GzipFile_write.patch
___
Python tracker
<http://bugs.python.org/issue21
Wolfgang Maier added the comment:
or not - my patch just causes a different error in my example :(
--
___
Python tracker
<http://bugs.python.org/issue21
Wolfgang Maier added the comment:
isn't this exactly what I did in my patch ?
actually, it is working, I just had an error in my preliminary test script.
I may be able to work on an official test at some point, but definitely not
over the next
New submission from Wolfgang Maier:
>>> l = [False, True]
>>> l.index(True)
1
>>> l.index(False)
0
good, but:
>>> l = ['a', '', {}, 2.7, 1, 0, False, True]
>>> l.index(True)
4
>>> l.index(False)
5
Apparently, True and
Wolfgang Maier added the comment:
No, it's not that simple and I don't think this should be closed:
In my example:
>>> l = ['a', '', {}, 2.7, 1, 0, False, True]
>>> l.index(True)
4
>>> l.index(False)
5
if using __eq__ consistently,
Wolfgang Maier added the comment:
Right, forgot about that.
The consequence for the example is still far from satisfying, I think, but you
can't change it without breaking compatibility then.
Thanks for the quick reply,
Wolfgang
--
___
P
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue1152248>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue9882>
___
___
Python-bugs-list mailing list
Unsubscribe:
Wolfgang Maier added the comment:
Wouldn't it make more sense to change gcd() in the fractions module to return
only positive integers?
The current gcd could become _gcd for private use by fractions, and the new
wrapper gcd could just be implemented as:
def gcd(a,b):
return abs(_gcd
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue1682>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Wolfgang Maier:
test_binop.py says that it tests binary operators on subtypes of built-in
types, but in fact largely focuses on testing its own class Rat, which simply
inherits from object and is, essentially, just a simple implementation of
fractions.Fraction.
Instead of
Wolfgang Maier added the comment:
see issue22477 for a discussion of whether the behavior of fractions.gcd should
be changed or not
--
___
Python tracker
<http://bugs.python.org/issue22
Wolfgang Maier added the comment:
sorry, forgot to format the link:
issue<22477>
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Pyth
Wolfgang Maier added the comment:
I wasn't arguing for or against anything, just providing a link to the relevant
discussion.
--
___
Python tracker
<http://bugs.python.org/is
Wolfgang Maier added the comment:
Thanks Nick for filing this!
I've been working on modifications to statistics._sum and
statistics._coerce_types that together make the module's behaviour independent
of the order of input types (by making the decision based on the set of input
Wolfgang Maier added the comment:
Hi Oscar,
well, I haven't used sympy much, and I have no experience with the others, but
in light of your comment I quickly checked sympy and gmpy2.
You are right about them still not using the numbers ABCs, however, on your
advise I also checked ho
Wolfgang Maier added the comment:
> -Ursprüngliche Nachricht-
> Von: Steven D'Aprano [mailto:rep...@bugs.python.org]
> Gesendet: Sonntag, 2. Februar 2014 12:55
> An: wolfgang.ma...@biologie.uni-freiburg.de
> Betreff: [issue20479] Efficiently support weight/frequ
Wolfgang Maier added the comment:
Well, I was thinking about frequencies (ints) when suggesting
for x,m in data.items():
T = _coerce_types(T, type(x))
n, d = exact_ratio(x)
partials[d] = partials_get(d, 0) + n*m
in my previous message. To support weights (float or
Wolfgang Maier added the comment:
> there are currently two strict requirements for any numeric type to be usable
> with statistics._sum:
I meant *three* of course (remembered one only during writing).
--
___
Python tracker
<http://bugs.p
Wolfgang Maier added the comment:
Just to make sure that this discussion is not getting on the wrong track,
there are currently two strict requirements for any numeric type to be usable
with statistics._sum:
(1) the type has to provide either
- numerator/denominator properties or
- an
Wolfgang Maier added the comment:
> Once the input numbers are converted to float statistics._sum can handle
> them perfectly well. In this case I think the output should also be a float so
> that it's clear that precision may have been lost. If the precision of float
> is no
Wolfgang Maier added the comment:
Hi Nick and Oscar,
my patch including tests is ready. What else should I say than that I think it
is ok, but of course with only days remaining and still no feedback from
Steven, I'm not sure there is any chance for it going into 3.4 still.
Anyway, b
Wolfgang Maier added the comment:
Hi Steven,
sounds reasonable, still here's the patch in diff version.
Its rules for type coercion are detailed in _coerce_types's docstring.
Questions and comments are welcome.
Best,
Wolfgang
--
keywords: +patch
Added file: http://bugs.
Wolfgang Maier added the comment:
I have written a patch for this issue (I'm uploading the complete new code for
everyone to try it - importing it into Python3.3 works fine; a diff with
additional tests against Oscar's example will follow soon).
Just as Oscar suggested, this n
Wolfgang Maier added the comment:
> We can add a fast Decimal.as_integer_ratio() in C.
That would be a terrific thing to have !! Currently, Decimals perform really
poorly with the statistics functions and this is entirely due to this
bottleneck.
With regard to calculating the sum of Decim
1 - 100 of 209 matches
Mail list logo
