Wolfgang Maier added the comment:
works for me too on Windows:
Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:38:48) [MSC v.1900 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> u'a\nb£'
Wolfgang Maier added the comment:
> The error() function in PC/launcher.c should call exit(rc) instead of
> ExitProcess(rc). This allows the CRT to terminate properly and flush the
> stderr FILE stream.
Interesting. Why do you need to flush stderr? I would have expected it to be
u
New submission from Wolfgang Maier:
from the console:
> py -3.7
or any other not installed Python version gives:
Requested Python version (3.7) not installed
However, when the launcher is executed from python via subprocess.Popen:
>>>import subprocess
>>>p=subproce
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
<http://bugs.python.org/issue24
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue8538>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 funct
Changes by Wolfgang Maier :
Added file: http://bugs.python.org/file39221/statistics._sum.patch
___
Python tracker
<http://bugs.python.org/issue24068>
___
___
Python-bug
Changes by Wolfgang Maier :
Removed file: http://bugs.python.org/file39220/statistics._sum.patch
___
Python tracker
<http://bugs.python.org/issue24068>
___
___
Python-bug
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 a
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
<http://bugs.python.org/is
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
<http://bugs
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
<http://bu
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue22881>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue23356>
___
___
Python-bugs-list mailing list
Unsubscribe:
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__(
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:
Surprisingly, a much simpler version with just one bytearray seems to run
stably (for several minutes at least), but when you wait a while then hit
Ctrl-C, you are getting a Segmentation fault:
Python 3.4.0 (default, Apr 11 2014, 13:05:11)
[GCC 4.8.2] on
Wolfgang Maier added the comment:
Also happening with Python 3.4.0 on Ubuntu 14.04 (after ~ half a minute and A
LOT of output):
[skipping lots of lines]
buf2: 29 13 bytearray(b'12312345678901231234567890123')
buf1: 25 9 bytearray(b'2345678901231234567890123')
bu
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 castin
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue5680>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: -wolma
___
Python tracker
<http://bugs.python.org/issue23933>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Wolfgang Maier added the comment:
are you looking for:
struct.pack('i'*4, *[0]*4)
?
--
nosy: +wolma
___
Python tracker
<http://bugs.python.o
Wolfgang Maier added the comment:
I'm able to reproduce this with Python 2.7.6 on Linux, but not 2.7.9 on Windows.
Is this a POSIX-only bug or has it been fixed in the meantime ?
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/is
Wolfgang Maier added the comment:
the new test:
test_exc('%x', '1', TypeError, "%x format: a number is required, not str")
expects the wrong error message.
python -m unittest -v test.test_format
...
'%x' % '1' works? ... no
Unexpect
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 the
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
el
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
<http://bugs.python.org/issu
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-0
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
<http://bugs.python.org/is
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:
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:
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
<http://bugs.python.
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 "", line 2, in
f.write(y)
BufferError: memoryview: underlying bu
Changes by Wolfgang Maier :
Added file: http://bugs.python.org/file38650/write_bytes_like_objects_v3.patch
___
Python tracker
<http://bugs.python.org/issue23688>
___
___
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
<http://bugs.python.org/is
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 op
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,
__cl
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:
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
-
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 tr
Wolfgang Maier added the comment:
@bkabrda
not sure, but it may have to do with when exactly the object gets garbage
collected
--
___
Python tracker
<http://bugs.python.org/issue23
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. This
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
<http://bugs.python.org/issue23
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',
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue23700>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 that
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]))
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
<http://bug
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
<h
Changes by Wolfgang Maier :
--
keywords: +patch
Added file: http://bugs.python.org/file38521/memoryview_write.patch
___
Python tracker
<http://bugs.python.org/issue23
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
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 :)
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
>
Wolfgang Maier added the comment:
isn't the pyvenv.cfg file specifying the version ?
--
___
Python tracker
<http://bugs.python.org/issue23465>
___
___
Pytho
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:
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 = 'i
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:
sorry, forgot to format the link:
issue<22477>
--
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
Pyth
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
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
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue1682>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue22486>
___
___
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/issue9882>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue1152248>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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,
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:
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
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:
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
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
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
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 .
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:
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:
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:
>> - 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:
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
Changes by Wolfgang Maier :
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issue21204>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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, 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:
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:
>> 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
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:
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, bu
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:
Wolfgang Maier added the comment:
Steven,
I think
if exp >= 0:
return int(x), 1
would have been a better patch, but yours is certainly working, just slower I
guess.
--
nosy: +wolma
___
Python tracker
<http://bugs.python.org/issu
Changes by Wolfgang Maier :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue20561>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue20
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 "",
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
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: +
Changes by Wolfgang Maier :
Added file: http://bugs.python.org/file33959/statistics.py
___
Python tracker
<http://bugs.python.org/issue20499>
___
___
Python-bugs-list m
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
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:
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.
101 - 200 of 209 matches
Mail list logo
