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
prints to stdout
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
types
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 how
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/frequency mappings
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
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 rep...@bugs.python.org
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
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 not
what the user wants
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, before
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.python.org
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 new version
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 Decimals
Wolfgang Maier added the comment:
Ok, I finally managed to get the test suite right for this, so here is the
patch diff for everything.
I made a few final changes to the module itself (mostly to please the test
suite), so I'll edited the complete code as well.
--
keywords: +patch
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
Added file: http://bugs.python.org/file33959/statistics.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20499
Wolfgang Maier added the comment:
In principle, your approach using itertools.groupby, the existing _sum, your
decimalsum, and my _ExactRatio class could be combined.
You could call decimalsum for Decimal and subclasses, the current _sum for
everything else.
_sum would return an _ExactRatio
New submission from Wolfgang Maier:
Can this still be fixed in 3.4 ??
I came across this bug in the statistics module today:
import statistics
data = [Decimal('1e4')]
statistics.mean(data)
Traceback (most recent call last):
File pyshell#465, line 1, in module
statistics.mean(data
Wolfgang Maier added the comment:
#if type(den) != int:
#print (d, sign, digits, exp, num, den)
was inserted by me of course for debugging this. Forgot to take it out again.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20561
Wolfgang Maier added the comment:
I worked out a slightly speedier version of decimal_to_ratio today (Stefan:
that's when I duplicated your bug report):
from decimal import Context
def _decimal_to_ratio (x):
_, digits, exp = x.as_tuple()
if exp in _ExactRatio.decimal_infinite: # INF
Wolfgang Maier added the comment:
oops,
if exp in _ExactRatio.decimal_infinite: # INF, NAN, sNAN
should read
if exp in ('F', 'n', 'N'): # INF, NAN, sNAN
of course. What I pasted comes from a micro-optimization I tried, but which
doesn't give any benefit
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 given
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 a
lot clearer !
Hadn't thought
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 = fsrc.read(length)
if not buf
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 rep...@bugs.python.org
http
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
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
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21204
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 terminators
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 check is compared
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 at all
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 inherits
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.
the first line should read:
m = [myObj() for x in range(1
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 .
--
nosy: +wolma
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 pyshell#2, line 1, in module
gzout.write('abcdefgh')
File /usr/lib/python3.4/gzip.py, line 343, in write
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 rep...@bugs.python.org
http://bugs.python.org/issue21560
Wolfgang Maier added the comment:
or not - my patch just causes a different error in my example :(
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21560
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 week
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 False get converted to int in comparisons to ints.
I would expect items to be compared either
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, you'd expect the first call to return 0 and the
second 1 (since
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
--
___
Python
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1152248
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9882
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(a, b
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1682
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
Wolfgang Maier added the comment:
see issue22477 for a discussion of whether the behavior of fractions.gcd should
be changed or not
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Wolfgang Maier added the comment:
sorry, forgot to format the link:
issue22477
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Wolfgang Maier added the comment:
I wasn't arguing for or against anything, just providing a link to the relevant
discussion.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22486
Wolfgang Maier added the comment:
It doesn't seem to be the exact same problem, but still this very simple
example with parentheses in metavar fails to format correctly:
import argparse
parser = argparse.ArgumentParser()
parser.add_argument(inputfiles, metavar = 'input_file(s)', nargs
Wolfgang Maier added the comment:
am I correct that when a script contains a shebang line like:
#! python3
or
#! python3.4
i.e., one indicating just a version of, but not a full path to the interpreter,
the current patch would not use an active virtualenv even if it has a suitable
version
Wolfgang Maier added the comment:
Thanks everyone for the lively discussion !
I like Serhiy's idea of making write work with arbitrary objects supporting the
buffer protocol. In fact, I noticed before that GzipFile.write misbehaves with
array.array input. It pretends to accept
Wolfgang Maier added the comment:
- I haven't seen other requests for it
For the record, an Extend custom action class is one of very few such classes I
have ever written for argparse for exactly the OP's usecase, i.e., it is useful
for any parser that should accept the same option multiple
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23700
Wolfgang Maier added the comment:
I think this is a consequence of PEP380 and its decision to finalize the
subgenerator when the delegating generator is closed.
Consider this simple example without tempfile:
def yielder (fileobj):
yield from fileobj
with open('some_test_file', 'w') as f
Wolfgang Maier added the comment:
Actually, its scary that use of yield from can have such a subtle side-effect.
Maybe PEP380 should have taken this more seriously?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23700
Wolfgang Maier added the comment:
@Serhiy
in this line of code:
reader = csv.DictReader(fileobj, fieldnames=next(csv.reader(fileobj)))
csv.reader(fileobj) returns the generator created by fileobj.__iter__, but no
reference to it is kept so the object gets destroyed right afterwards
Wolfgang Maier added the comment:
so let's look at this step-by-step (and I hope I fully understood this myself):
- calling fileobj.__iter__ creates a generator because the method uses yield
from
- that generator does not get assigned to any reference so it will be
garbage-collected
- when
Wolfgang Maier added the comment:
The patch has a huge block replacement in the gzip.py module starting at
GzipFile.write, which makes it large and hard to identify changes. Could that
be ameliorated or is it too much work right now?
--
nosy: +wolma
Wolfgang Maier added the comment:
ok, I've prepared a patch including tests based on my last suggestion, which I
think is ready for getting reviewed.
--
Added file: http://bugs.python.org/file38600/write_bytes_like_objects.patch
___
Python tracker
Wolfgang Maier added the comment:
OTOH, it would be very hard to change the way fileobjects compared to designing
yield from differently so I'd still blame it partly.
Maybe it is unfortunate that generators have a close method instead of, say,
__close__
Wolfgang Maier added the comment:
You are probably right that the io classes are broken.
From https://docs.python.org/3/library/stdtypes.html#iterator-types:
Once an iterator’s __next__() method raises StopIteration, it must continue to
do so on subsequent calls. Implementations that do
Wolfgang Maier added the comment:
@bkabrda
not sure, but it may have to do with when exactly the object gets garbage
collected
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23700
New submission from Wolfgang Maier:
I thought I'd go back to work on a test patch for issue21560 today, but now I'm
puzzled by the explicit handling of memoryviews in gzip.GzipFile.write.
The method is defined as:
def write(self,data):
self._check_closed()
if self.mode
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
keywords: +patch
Added file: http://bugs.python.org/file38521/memoryview_write.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23688
Wolfgang Maier added the comment:
Here is a patch with memoryview tests.
Are tests and code patches supposed to go in one file or separate ones ?
--
Added file: http://bugs.python.org/file38526/test_memoryview_write.patch
___
Python tracker rep
Wolfgang Maier added the comment:
memoryview is converted to bytes because len() for memoryview returns a size
of first dimension (a number of items for one-dimension view), not a number
of bytes.
m = memoryview(array.array('I', [1, 2, 3]))
len(m)
3
len(m.tobytes())
12
len(m.cast('B
Wolfgang Maier added the comment:
@Serhiy:
Why would data = data.cast('B') be required ? When would the memoryview not be
in 'B' format already ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23688
Wolfgang Maier added the comment:
This implies sum() should accept str, unicode, list, tuple, bytearray, buffer,
and xrange.
and in fact it *does* accept all these as input. It just refuses to add the
elements of the sequence if these elements are of certain types. Of course, the
elements
Wolfgang Maier added the comment:
Initially, I also thought that this should be addressable with
Fraction.__round__ or an optimized variation of it, but Tuomas is right that it
gets complicated by the fact that you need to cope with the different format
specifiers and not all of them fit
Wolfgang Maier added the comment:
Here is a revised version of my patch addressing Serhiy's review comments.
--
Added file: http://bugs.python.org/file38639/write_bytes_like_objects_v2.patch
___
Python tracker rep...@bugs.python.org
http
Wolfgang Maier added the comment:
I see now that it is just issue21560 that went into 2.7 and that's fine.
As I said: sorry for the noise
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23688
Wolfgang Maier added the comment:
to preserve compatibility:
there is the memoryview.c_contiguous flag. Maybe we should just check it and if
it is False fall back to the old copying behavior ?
--
___
Python tracker rep...@bugs.python.org
http
Wolfgang Maier added the comment:
something like:
def write(self,data):
self._check_closed()
if self.mode != WRITE:
import errno
raise OSError(errno.EBADF, write() on read-only GzipFile object)
if self.fileobj is None:
raise
Wolfgang Maier added the comment:
Serhiy:
I think I saw that you committed this also to the 2.7 branch, but that would
not work since memoryviews do not have the nbytes attribute (they do not seem
to have cast either). One would have to calculate the length instead from other
properties
Wolfgang Maier added the comment:
ouch. haven't thought of this.
OTOH, just plain io with your example:
with open('xy', 'wb') as f:
f.write(y)
Traceback (most recent call last):
File pyshell#29, line 2, in module
f.write(y)
BufferError: memoryview: underlying buffer is not C
Wolfgang Maier added the comment:
So, with the current patch users could still not use the py launcher from a
virtual environment with scripts that are supposed to work under UNIX :(
Correct. That's not the problem this PEP is intended to solve.
Granted :)
Another PEP could be written
Wolfgang Maier added the comment:
isn't the pyvenv.cfg file specifying the version ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23465
Wolfgang Maier added the comment:
Hmm, I didn't know that (although virtualenv-based environments don't have an
equivalent to pyvenv.cfg).
Well, that complicates things then :(
But there's some confusion here. This patch only affects command line usage
(running py.exe to start Python
Wolfgang Maier added the comment:
Decimal formatting intentionally differs from float formatting, see #23460.
I see. Thanks for the pointer. What about the missing zero in the exponent ?
--
___
Python tracker rep...@bugs.python.org
http
Wolfgang Maier added the comment:
actually, I'm not sure whether formatting Decimals gives correct output under
all conditions (correctly rounded yes, but maybe not formatted correctly?).
compare:
format(float('1.481e-6'),'.3g')
'1.48e-06'
format(Decimal('1.481e-6'),'.3g')
'0.0148
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
Added file: http://bugs.python.org/file38650/write_bytes_like_objects_v3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23688
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: -wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23933
Wolfgang Maier added the comment:
I'm afraid you lost me and I do not see what your problem is here.
Maybe you should raise this on one of the Python mailing lists (see
https://www.python.org/community/lists/) ?
--
___
Python tracker rep
Wolfgang Maier added the comment:
Is it not reasonable to simply say that implementations of numbers.Rational
which allow the numerator and denominator to have types for which true
division doesn't return a float, have to provide their own implementation of
__float__()?
Unfortunately
Wolfgang Maier added the comment:
Good point.
If the numbers ABC guaranteed numerator and denominator to be Integral numbers,
this could be solved by:
return float(int(self.numerator) / int(self.denominator))
but since both could be Rationals again that does not seem to be an option
either
Wolfgang Maier added the comment:
for the even number case, I think you shouldn't do // 2, but / 2.
In general, wouldn't it be good to let the statistics module do all the stats
calculations?
--
___
Python tracker rep...@bugs.python.org
http
Wolfgang Maier added the comment:
ah sorry, it's late here already and I forgot what file this change is about.
So forget my last comment then.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22881
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22881
Wolfgang Maier added the comment:
It's not available in older Python versions, e.g. 2.6.
I know, I was talking about 3.5+, of course. This would not be backported to
Python2 anyway, would it?
--
___
Python tracker rep...@bugs.python.org
http
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23356
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8538
Wolfgang Maier added the comment:
After considering this for a while, I think:
return float(self.numerator / self.denominator)
is the best solution:
* it is simple and works reasonably well as a default
* it fixes Rational.__float__ for cases, in which numerator / denominator
returns
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
Removed file: http://bugs.python.org/file39220/statistics._sum.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24068
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
Added file: http://bugs.python.org/file39221/statistics._sum.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24068
New submission from Wolfgang Maier:
the mean function in the statistics module gives nonsensical results with
boolean values in the input, e.g.:
mean([True, True, False, False])
0.25
mean([True, 1027])
0.5
This is an issue with the module's internal _sum function that mean relies
Wolfgang Maier added the comment:
uploading an alternate, possibly slightly clearer version of the patch
--
Added file: http://bugs.python.org/file39269/statistics._sum.v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de:
--
nosy: +wolma
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5680
New submission from Wolfgang Maier:
numbers.Rational defines __float__ like this:
def __float__(self):
float(self) = self.numerator / self.denominator
It's important that this conversion use the integer's true
division rather than casting one side to float before dividing
so
1 - 100 of 208 matches
Mail list logo
