Roundup Robot added the comment:
New changeset 4580976c07cb by Victor Stinner in branch '3.3':
Issue #17429: platform.linux_distribution() now decodes files from the UTF-8
http://hg.python.org/cpython/rev/4580976c07cb
New changeset 407f18c8ce8a by Victor Stinner in branch 'default':
(Merge 3.3)
Fotis Koutoulakis added the comment:
Hello, I'm in the process of trying to find a solution to this problem, but I'm
afraid the choice of wording at some point is kind of...ambiguous.
I have some questions I want to ask, to clear some doubts in my head:
First one is:
if __main__ in a
Roundup Robot added the comment:
New changeset 831b2c80a9c9 by Victor Stinner in branch 'default':
Issue #17429: some PEP 8 compliance fixes for the platform modules, add
whitespaces
http://hg.python.org/cpython/rev/831b2c80a9c9
--
___
Python
STINNER Victor added the comment:
Thanks Toshio Kuratomi for your patch. I simplified the unit test. I'm not sure
that resetlocale restores the locale in its previous state. I don't want to
rely on two specific locales ('pt_BR.UTF8' and 'pt_BR.ISO8859-1') for a such
simple test. We have
Roundup Robot added the comment:
New changeset a951ab03bda0 by Victor Stinner in branch '3.3':
Issue #17429: Oops, remove unused import
http://hg.python.org/cpython/rev/a951ab03bda0
New changeset 209bf9576dc8 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #17429: Oops, remove unused
Changes by STINNER Victor victor.stin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17429
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17429
___
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
title: platform.platform() can throw Unicode error -
platform.linux_distribution() should decode files from UTF-8, not from the
locale encoding
___
Python tracker rep...@bugs.python.org
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19904
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset 1e3c7153a14d by Victor Stinner in branch 'default':
Fix #19830: Fix a ResourceWarning in test_poplib.
http://hg.python.org/cpython/rev/1e3c7153a14d
--
nosy: +python-dev
___
Python tracker
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: -haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18864
___
___
Python-bugs-list
STINNER Victor added the comment:
The patch fixes the ResourceWarning, thanks.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19830
___
Antoine Pitrou added the comment:
On dim., 2013-12-08 at 22:22 +, STINNER Victor wrote:
(b) for technical reasons, Python reuses the C codec during Python
initialization to decode and encode OS data, and so currently Python
*must* use the locale encoding for its filesystem encoding
Ahhh!
STINNER Victor added the comment:
Sorry, but I still don't understand this issue.
Invalid read of size 4 is a known false positive. It can be worked around
using ./configure --with-valgrind and the suppression list, or using
./configure --without-pymalloc. If you still get the warning, you
STINNER Victor added the comment:
It seems there is more work to do to get this right, but I'm not
terribly interested either. Feel free to take over.
If you are talking to me: I'm currently opposed to change anything, so I'm not
interested to work on a patch. IMO Python works fine and you
Fil Mackay added the comment:
Stefan, performance is not the principle motivator here: the intention is that
it is just sensible to support this integer type, just like supporting int64
since it is an intrinsic type supported by CPU's.
Of course any integer length could be handled by
Antoine Pitrou added the comment:
Of course any integer length could be handled by memoryview unpacker,
but this would not really make sense for int64. My view is that any
intrinsic type (ie. register type) is the key point at which it should
be supported by struct, and not a custom
Fil Mackay added the comment:
Antoine,
No, the SIMD vector should be treated as a int128 (for eg.), not as 4 python
ints. It is the unpacking process that unpacks into 4 python ints. The two
shouldn't be confused - you definitely want to be able to treat the vector in
both states (packed and
Antoine Pitrou added the comment:
The two shouldn't be confused - you definitely want to be able to
treat the vector in both states (packed and unpacked).
Why do you need the packed state as a 128-bit int, rather than as a
bytes object? You are not doing arithmetic on it, AFAIU.
--
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19905
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset 09658ea0b93d by Victor Stinner in branch 'default':
Close #19880: Fix a reference leak in unittest.TestCase. Explicitly break
http://hg.python.org/cpython/rev/09658ea0b93d
--
nosy: +python-dev
resolution: - fixed
stage: -
Roundup Robot added the comment:
New changeset c4c1c4bc8086 by Victor Stinner in branch 'default':
Issue #19876: Run also
test_selectors.test_unregister_after_fd_close_and_reuse() on Windows
http://hg.python.org/cpython/rev/c4c1c4bc8086
--
___
STINNER Victor added the comment:
Oops, I reverted my changeset c4c1c4bc8086, I didn't read why the test was
skipped on Windows. Sorry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19876
STINNER Victor added the comment:
Except that it can fail with ENOENT, but also EBADF, and EPERM if the
FD has been reused by a FD which doesn't support epoll.
Oh, I didn't know that. I ran the unit test, and I expected the two unit test
to cover any error case. So ignore my
Fil Mackay added the comment:
Antoine,
I don't think register types matter here. The struct module provides
interoperability with low-level *data types* (in C and other common
languages), not CPU *registers*.
OK, see where you're coming from. I guess my thinking was such that struct (and
Fotis Koutoulakis added the comment:
I have finished the changes needed to move script_helper from Lib/test to
Lib/test/support, and I have also documented it. Tests run gracefully (but be
sure to check out if it works as intended on your machines too)
Two notes though:
1. I have only made
Nick Coghlan added the comment:
By providing a __main__.py submodule, a package is saying I am directly
executable. When runpy says it isn't (because running that file happened to
raise ImportError), then runpy is wrong.
runpy can't make the file work (it's genuinely broken), but it can avoid
Nick Coghlan added the comment:
End users tripping over this by setting LANG=C is one of the pain points of
Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora
folks to the nosy list.
My current understanding of the situation:
- we should leave Windows and Mac OS X
Nick Coghlan added the comment:
I wouldn't worry about 3.3 at this point - the 3.3 test suite isn't going to
see major changes for its final release, so the risk of merge conflicts is low.
--
versions: -Python 3.3
___
Python tracker
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: docs@python - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18576
___
___
Nick Coghlan added the comment:
I took a look at this last night, and found the combination of moving stuff
around *and* refactoring it at the same time was too hard to review.
So, once the PEP 451 changes for runpy are done, I think it would make more
sense to tackle this as at least three
STINNER Victor added the comment:
End users tripping over this by setting LANG=C is one of the pain points of
Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora
folks to the nosy list.
Sorry, I'm not aware of such issue. Do you have examples?
- the main problem is
Berker Peksag added the comment:
I left a few comments on Rietveld.
--
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16099
___
Nick Coghlan added the comment:
On 9 December 2013 12:08, STINNER Victor rep...@bugs.python.org wrote:
STINNER Victor added the comment:
End users tripping over this by setting LANG=C is one of the pain points of
Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora
Tim Peters added the comment:
@serhiy, Mark certainly knows the proposed addition isn't _needed_ to pick
apart 64-bit integers. It's an issue there of clarity, not O() behavior. For
example, `i.bits_at(0, 52)` to get at a double's mantissa requires no thought
at all to write or to read
Tim Peters added the comment:
[@anon]
What should happen next?
1. Write docs.
2. Write a test suite and test a Python implementation.
3. Write C code, and reuse the test suite to test that.
4. Attach a patch for all of that to this issue (although a
Python implementation is no longer
Tim Peters added the comment:
The weakref.slice fix looks solid to me, although it appears to be specific to
2.7 (the methods are fancier on the current default branch, fiddling with
self._pending_removals too).
Does anyone know why the signature of pop is:
def pop(self, key, *args)
?
Sworddragon added the comment:
You should keep things more simple:
- Python and the operation system/filesystem are in a client-server
relationship and Python should validate all.
- It doesn't matter what you will finally decide to be the default encoding on
various places - all will provide
New submission from João Bernardo:
From the docs for built-in function round:
If ndigits is omitted, it defaults to zero
(http://docs.python.org/3/library/functions.html#round)
But, the only way to get an integer from `round` is by not having the second
argument (ndigits):
New submission from Matthew Gilson:
Reading the source for collections.Counter.most_common, the docstring mentions
that `n` can be `None` or omitted, but the online documentation does not
mention that `n` can be `None`.
--
assignee: docs@python
components: Documentation
messages:
Matthew Gilson added the comment:
This is a very simple patch which addresses the issue. I am still curious
whether the reported function signature should be changed from:
.. method:: most_common([n])
to:
.. method:: most_common(n=None)
. Any thoughts?
Also, while I was in there,
Vajrasky Kok added the comment:
Here is the preliminary patch.
After patch:
round(1.23, 0) = 1 not 1.0
round(4.67, 0) = 5 not 5.0
--
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file33051/fix_round_with_zero_ndigits.patch
Changes by Vajrasky Kok sky@speaklikeaking.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19933
___
___
Changes by Vajrasky Kok sky@speaklikeaking.com:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19934
___
___
101 - 144 of 144 matches
Mail list logo
