[issue19934] collections.Counter.most_common does not document `None` as acceptable input.

[Vajrasky Kok]

Changes by Vajrasky Kok :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19933] Round default argument for "ndigits"

[Vajrasky Kok]

Changes by Vajrasky Kok :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19933] Round default argument for "ndigits"

[Vajrasky Kok]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19934] collections.Counter.most_common does not document `None` as acceptable input.

[Matthew Gilson]

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, I changed a few *None* to ``None`` for consistency 
with the rest of the documentation.

--
keywords: +patch
Added file: http://bugs.python.org/file33050/mywork.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19934] collections.Counter.most_common does not document `None` as acceptable input.

[Matthew Gilson]

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: 205648
nosy: docs@python, mgilson
priority: normal
severity: normal
status: open
title: collections.Counter.most_common does not document `None` as acceptable 
input.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19933] Round default argument for "ndigits"

[João Bernardo]

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):

>>> round(3.5)
4
>>> round(3.5, 1)
3.5
>>> round(3.5, 0)
4.0
>>> round(3.5, -1)
0.0
>>> round(3.5, None)
Traceback (most recent call last):
  File "", line 1, in 
round(3.5, None)
TypeError: 'NoneType' object cannot be interpreted as an integer


Either the docs are wrong or the behavior is wrong. I think it's easier to fix 
the former...

But also there should be a way to make round return an integer (e.g. passing 
`None` as 2nd argument)

--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 205647
nosy: JBernardo, docs@python
priority: normal
severity: normal
status: open
title: Round default argument for "ndigits"
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3 on Linux

[Sworddragon]

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 race-conditions with no exception.
- The easiest way to fix this is to give the developer the ability to make a 
decision (like sys.use_strict_encoding(), sys.setfilesystemencoding(), 
sys.setdefaultencoding() etc.).
* For example giving the developer control is especially needed if he wants to 
handle multiple different filesystems.


> Why do you think that the issue is specific to Python 3? Try to open a
> terminal with LC_ALL=C and try to type non-ASCII characters with your
> keyboard. You can't because your terminal uses ASCII.

sworddragon@ubuntu:~$ LANG=C
sworddragon@ubuntu:~$ ä
bash: $'\303\244': command not found

- The terminal doesn't pseudo-crash with an exception because it doesn't matter 
about encodings.
- It allows to change the encoding at runtime.


> Did you
> applications written in another language handling Unicode, like Perl?

Compare C: It wouldn't matter like the terminal. For example fopen will simply 
return NULL if it can't open the file 'ä' because the filesystem is endoded 
with ISO-8859-1 and we wanted to open the utf-8 counterpart.


> Can you explain the "various reasons" why users explictly force the
> encoding to ASCII?

For example I'm using this for testcases to set the language uncomplicated to 
english.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

python-bugs-list@python.org

[Tim Peters]

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)

?  It doesn't make sense to me to accept any number of arguments following 
`key`.  Perhaps it's just an obscure way to avoid doing:

_noarg = object()  # unique sentinel

def pop(self, key, default=_noarg):

?

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[Tim Peters]

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 interesting at this point).
5. After that's all ready, seek consensus on Python-Dev.

The good news:  this is too minor to require a PEP ;-)

--
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[Tim Peters]

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 later; bit-level gibberish like

i & ~((~0) << 52)

or

i & ((1 << 52) - 1)

or ... is painful to write and to read.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3 on Linux

[Nick Coghlan]

Nick Coghlan added the comment:

On 9 December 2013 12:08, STINNER Victor  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 
>> folks to the nosy list.
>
> Sorry, I'm not aware of such issue. Do you have examples?

Armin's travails with remote shell access and Python 3 are just as
likely today as they were a couple of years ago:
http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/

(although technically that was a terminal ending up with the POSIX
locale, rather than specifically LANG=C)

>> - the main problem is on Linux (but potentially other *nix systems as well), 
>> where people set "LANG=C" for a variety of reasons, but this has the side 
>> effect of Python 3 choosing an inappropriate encoding (ASCII rather than 
>> UTF-8) when talking to the OS APIs.
>
> Why do you think that the issue is specific to Python 3? Try to open a
> terminal with LC_ALL=C and try to type non-ASCII characters with your
> keyboard. You can't because your terminal uses ASCII. Did you
> applications written in another language handling Unicode, like Perl?
> (Perl with Unicode support correctly enabled, it's "use utf8;" if I
> remember correctly).

It's the fact this used to work transparently in Python 2 (since all
these interfaces were just bytes based on the Python side as well)
that's a problem. That makes the new sensitivity to the locale
encoding a usability regression, and that's a concern for distros that
are considering switching their default Python version.

> Can you explain the "various reasons" why users explictly force the
> encoding to ASCII?

- testing applications for POSIX compliance
- default settings on servers where you don't control the environment
- because they never previously had to care, and it's only Python 3
deciding to pay attention to it which makes it relevent for them

> I use LANG=C to get manual pages and error messages in english. But
> "LANG=en_US man ls" would be more correct, or "LC_MESSAGES=en_US man
> ls" to be pedantic. (Env var priority: LC_ALL > LANG > LC_xxx).
>
> IMO if you use LANG=C, you must not complain that Unicode stopped
> working, but you should learn how to configure locales. Trivial
> examples like the one which can be found in the initial message
> (msg204849) are wrong: why would you force all locales to C and use
> non-ASCII characters?

And yet, in Python 2, people could do that, and Python didn't care.
*That's* the regression I'm worried about. If it hadn't round-tripped
cleanly in Python 2, I wouldn't care here either.

>> Given the initialisation problems, this may be something that PEP 432 (the 
>> initialisation process rewrite) can help with (since it changes the 
>> initialisation order to create a more complete Python runtime before it 
>> starts to configure the OS interfaces).
>
> I don't see how it would help to solve my point (b).

Having a Python runtime available makes things that are currently
tediously painful to deal with during startup easier to tweak. I'm not
sure it *will* help in this particular case, but it's now one I'm
going to keep an eye on.

> Technically, this issue cannot be fixed. Or to be more specific, I
> don't want to fix it, it's a waste of time. So I don't understand what
> do you expect from this open issue?

A way to get Python 3 to cope as well with a misconfigured OS
environment as Python 2 did.

> I would prefer to close it as invalid or wontfix to be clear.

It's a usability regression from Python 2, so I don't want to give up
on it. It may be that we just implement a "ignore what the OS claims,
it's misconfigured, just use UTF-8 for everything" flag. But OS
configuration errors shouldn't cripple the Python runtime.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16099] robotparser doesn't support request rate and crawl delay parameters

[Berker Peksag]

Berker Peksag added the comment:

I left a few comments on Rietveld.

--
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3 on Linux

[STINNER Victor]

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 on Linux (but potentially other *nix systems as well), 
> where people set "LANG=C" for a variety of reasons, but this has the side 
> effect of Python 3 choosing an inappropriate encoding (ASCII rather than 
> UTF-8) when talking to the OS APIs.

Why do you think that the issue is specific to Python 3? Try to open a
terminal with LC_ALL=C and try to type non-ASCII characters with your
keyboard. You can't because your terminal uses ASCII. Did you
applications written in another language handling Unicode, like Perl?
(Perl with Unicode support correctly enabled, it's "use utf8;" if I
remember correctly).

Can you explain the "various reasons" why users explictly force the
encoding to ASCII?

I use LANG=C to get manual pages and error messages in english. But
"LANG=en_US man ls" would be more correct, or "LC_MESSAGES=en_US man
ls" to be pedantic. (Env var priority: LC_ALL > LANG > LC_xxx).

IMO if you use LANG=C, you must not complain that Unicode stopped
working, but you should learn how to configure locales. Trivial
examples like the one which can be found in the initial message
(msg204849) are wrong: why would you force all locales to C and use
non-ASCII characters?

> Given the initialisation problems, this may be something that PEP 432 (the 
> initialisation process rewrite) can help with (since it changes the 
> initialisation order to create a more complete Python runtime before it 
> starts to configure the OS interfaces).

I don't see how it would help to solve my point (b).

Technically, this issue cannot be fixed. Or to be more specific, I
don't want to fix it, it's a waste of time. So I don't understand what
do you expect from this open issue?

I would prefer to close it as invalid or wontfix to be clear.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

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 patches:

1. Do the refactoring *within* test_runpy to make the helper API a bit cleaner 
(this should also use types.SimpleNamespace where appropriate rather than a 
custom alternative)

2. Move the helper API out to a documented test.support.package_helper module 
without altering the test.support API

3+. Refactor other test modules to use the now shared API (there may be some 
pkg related functionality to move out of script_helper as well).

--
dependencies: +Rename and document test.script_helper as 
test.support.script_helper, Update runpy for PEP 451

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18576] Rename and document test.script_helper as test.support.script_helper

[Nick Coghlan]

Changes by Nick Coghlan :


--
assignee: docs@python -> ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18576] Rename and document test.script_helper as test.support.script_helper

[Nick Coghlan]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3 on Linux

[Nick Coghlan]

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 alone, since they ignore the locale when 
choosing the OS API encoding anyway

- the main problem is on Linux (but potentially other *nix systems as well), 
where people set "LANG=C" for a variety of reasons, but this has the side 
effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) 
when talking to the OS APIs.

Given the initialisation problems, this may be something that PEP 432 (the 
initialisation process rewrite) can help with (since it changes the 
initialisation order to create a more complete Python runtime before it starts 
to configure the OS interfaces).

Tangentially related, we may want to consider aliasing 
sys.getfilesystemencoding, os.fsencode and os.fsdecode as something like 
sys.getosapiencoding, os.apiencode and os.apidecode, since the current naming 
is misleading (the value is based on the platform and environment, not any 
particular filesystem, and is used for almost all bytes-based OS APIs, not just 
filesystem metadata)

--
nosy: +a.badger, bkabrda
title: Setting LANG=C breaks Python 3 -> Setting LANG=C breaks Python 3 on Linux

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19771] runpy should check ImportError.name before wrapping it

[Nick Coghlan]

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 
reporting a misleading error message - that's the bug to be fixed.

As far as the testing goes, if you look at the existing runpy tests, the usual 
approach is to create a temporary directory, write out a package with the 
desired behaviour, and then run it from there. So, for this test, it's a matter 
of copying the general structure of the existing package execution test in 
test_runpy, but replacing the body of the __main__.py file with something like 
"raise ImportError('This should not be replaced')"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18576] Rename and document test.script_helper as test.support.script_helper

[Fotis Koutoulakis]

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 the changes on the default branch. Will do 3.3 tomorrow.

2. When it came to the documentation, I had to break the 80 characters limit, 
as going by it was resulting in weird rendering or wrong information depicted 
from sphinx (for example, when showing that script_helper functions belonged to 
test.support instead of the correct location, test.support.script_helper).

Last but not least, this is one of my first contributions to Python, so I would 
appreciate your input.

--
keywords: +patch
nosy: +Fotis.Koutoulakis
Added file: http://bugs.python.org/file33049/script_helper-default.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19904] Add 128-bit integer support to struct

[Fil Mackay]

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 
ctypes) support is required for data types that are common within C structures. 
The fact that 128-bit ints are now appearing within these structures is due to 
the fact that CPU support has dramatically improved, and are supported natively 
in register types. So it was kind of an indirect connection.

So the question I guess is whether you think these types are "common enough" in 
C structs, which for me they certainly are for my data processing 
applications.. (pretty please :)

> So IMHO the question is whether there is an use case for 128-bit
> integers; *not* for arrays of four 32-bit integers packed in a 128-bit
> register.

Agree completely - just stick to thinking about atomic 128-bit integers. A 
pack/unpack function should do the conversion, and have nothing to do with this 
struct support.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets

[STINNER Victor]

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 epoll_except.patch, the current "except 
OSError: pass" is correct.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets

[STINNER Victor]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets

[Roundup Robot]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19880] unittest: on failure, TestCase.run() keeps a reference to the exception

[Roundup Robot]

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:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19905] Add 128-bit integer support to ctypes

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19904] Add 128-bit integer support to struct

[Antoine Pitrou]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19904] Add 128-bit integer support to struct

[Fil Mackay]

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 unpacked).

I'm not saying that Python should necessarily make use of SIMD instructions 
(don't think performance is critical there in py), but that it should at least 
be access to a raw 128/256/512 bit integer within a C structure. Part of this 
is interacting with SIMD'able structures - at least in my use cases :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19904] Add 128-bit integer support to struct

[Antoine Pitrou]

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 unpacker. 128/256/512 bit
> integers are in this category..

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*.

So IMHO the question is whether there is an use case for 128-bit
integers; *not* for arrays of four 32-bit integers packed in a 128-bit
register.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19904] Add 128-bit integer support to struct

[Fil Mackay]

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 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 unpacker. 128/256/512 bit integers are in this category..

Principally this is so that it can be used by ctypes (see #19905).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3

[STINNER Victor]

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 should try to 
workaround the current limitations :-)

If someone is interested to write an huge patch fixing all these issues, I 
would be able to reconsider my opinion on point (a).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19893] Python cApi memory problem. Py_Initialize memory leak

[STINNER Victor]

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 used the 
wrong options or you are still using another Python binary (or shared library). 
Make sure that you are linked to your newly compiled shared library.

"valgrind --leak-check=full --log-file=valgrind.log ./python -c pass" shows me 
"possibly lost: 286,779 bytes in 654 blocks". This is also another known issue: 
Python doesn't release all the memory at exit, they are many "singletons" and 
variables initialized once but never released.

The PEP 3121 helps this issue but the PEP is not fully implemented yet, many 
modules should still be modified.

So what is your question? Do you think that Python leaks memory? Why do you 
think so?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3

[Antoine Pitrou]

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! Well indeed that's a bummer :-)

> asciilocale.patch has many issues. Try to run the Python test suite
> using this patch to see what I mean.

I'm assuming much of this is due to (b) (all those tests seem to spawn
external processes).

It seems there is more work to do to get this right, but I'm not
terribly interested either. Feel free to take over.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19830] test_poplib emits resource warning

[STINNER Victor]

STINNER Victor added the comment:

The patch fixes the ResourceWarning, thanks.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)

[STINNER Victor]

Changes by STINNER Victor :


--
nosy:  -haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19830] test_poplib emits resource warning

[Roundup Robot]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19904] Add 128-bit integer support to struct

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17429] platform.linux_distribution() should decode files from UTF-8, not from the locale encoding

[STINNER Victor]

Changes by STINNER Victor :


--
title: platform.platform() can throw Unicode error -> 
platform.linux_distribution() should decode files from UTF-8, not from the 
locale encoding

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17429] platform.linux_distribution() should decode files from UTF-8, not from the locale encoding

[STINNER Victor]

Changes by STINNER Victor :


--
versions:  -Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17429] platform.platform() can throw Unicode error

[Roundup Robot]

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 import
http://hg.python.org/cpython/rev/209bf9576dc8

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17429] platform.platform() can throw Unicode error

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17429] platform.platform() can throw Unicode error

[STINNER Victor]

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 enough buildbots to test other various locales.

I prefered to only change minor syntax issues (PEP 8) in Python 3.4 to limit 
changes in the stable release.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17429] platform.platform() can throw Unicode error

[Roundup Robot]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19771] runpy should check ImportError.name before wrapping it

[Fotis Koutoulakis]

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 package throws ImportError, runpy will incorrectly report the 
package as not being directly executable (when it actually claims to be 
executable, it's just broken)"

In the above, from what I can understand from the first part of the sentence, 
before the paragraph, if __main__.py is not found in a package, run py will 
report that it won't be directly executable. Along these lines, it's mentioned 
that this behaviour is incorrect, but then the sentence inside the parentheses 
contradicts that position, suggesting that when it does suggest it's actually 
executable, it's just erroneous behaviour (so both behaviours are erroneous?)

The second one is:

"This can be fixed in 3.3+ by checking for an appropriate value in the name 
attribute of the caught exception, and only wrapping it if the failed lookup 
was for the __main__ submodule we're looking for."

Ok this seems to be pretty clear, we are expected to create a new package with 
a __main__.py that all it does is `raise ImportError`. (Disclaimer: I may be 
fairly wrong here). Question is, where should we put the new package? 
Obviously, we shouldn't litter the "real" modules, with the testing one, but if 
I try to use the test folder as a package, I get "ImportError: error while 
finding loader for xxx"

Please be lenient with me, this is one of my very first contributions to 
python. I will gladly accept all feedback.

--
nosy: +Fotis.Koutoulakis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17429] platform.platform() can throw Unicode error

[Roundup Robot]

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) Issue #17429: platform.linux_distribution() now decodes files from
http://hg.python.org/cpython/rev/407f18c8ce8a

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3

[STINNER Victor]

STINNER Victor added the comment:

>> Or said differently, the filesystem encoding is different than the
>> locale encoding.

> Indeed, but the FS encoding and the IO encoding are the same.
> "locale encoding" doesn't really matter here, as we are assuming that
> it's wrong.

Oh, I realized that "FS encoding" term in not clear. When I wrote "FS 
encoding", I mean sys.getfilesystemencoding() which is mbcs on Windows, UTF-8 
on Mac OS X and (currently) the locale encoding on other platforms (UNIX, ex: 
Linux/FreeBSD/Solaris/AIX).

--

IMO there are two different points in this issue:

(a) which encoding should be used when the C locale is used: the encoding 
announced by the OS using nl_langinfo(CODESET) (current choice) or use an 
arbitrary optimistic "utf-8" encoding?

(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"

Before being able to pronounce me on the point (a), I would like to see a patch 
fixing the point (b). I'm not against fixing point (b). I'm just saying that 
it's not trivial and obviously it must be fixed to change the status of point 
(a). I even gave clues to fix point (b).

--

asciilocale.patch has many issues. Try to run the Python test suite using this 
patch to see what I mean. Example of failures:

==
FAIL: test_non_ascii (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_cmd_line.py", line 140, 
in test_non_ascii
assert_python_ok('-c', command)
  File "/home/haypo/prog/python/default/Lib/test/script_helper.py", line 69, in 
assert_python_ok
return _assert_python(True, *args, **env_vars)
  File "/home/haypo/prog/python/default/Lib/test/script_helper.py", line 55, in 
_assert_python
"stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Unable to decode the command from the command line:
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc3' in position 
12: surrogates not allowed

==
FAIL: test_ioencoding_nonascii (test.test_sys.SysModuleTest)
--
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 603, in 
test_ioencoding_nonascii
self.assertEqual(out, os.fsencode(test.support.FS_NONASCII))
AssertionError: b'' != b'\xc3\xa6'

==
FAIL: test_nonascii (test.test_warnings.CEnvironmentVariableTests)
--
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_warnings.py", line 774, 
in test_nonascii
"['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != 
b"['ignore:Deprecaci\xc3\xb3nWarning']"

==
FAIL: test_nonascii (test.test_warnings.PyEnvironmentVariableTests)
--
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_warnings.py", line 774, 
in test_nonascii
"['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != 
b"['ignore:Deprecaci\xc3\xb3nWarning']"


test_warnings is probably #9988, test_cmd_line failure is maybe #9992.

There are maybe other issues, the Python test suite only have a few tests for 
non-ASCII characters.

--

If anything is changed, I would prefer to have more than a few months of test 
to make sure that it doesn't break anything. So I set the version field to 
Python 3.5.

--
versions: +Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

python-bugs-list@python.org

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ah, you're right. We just need to cook up a patch then.

--
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Extracting sign, exponent and significand fields from the binary
> representation of a float is at least one thing I'd use this for.

You don't need special function for bit operations. Float values are short (32 
or 64 bits) and any bit operations are O(1). Special function for bit 
extracting (or modifying) is needed when you process many hundreds or 
thousands of bits. In any case >> and & for 64-bit values are faster than 
method call.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18983] Specify time unit for timeit CLI

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage: needs patch -> patch review
versions: +Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18983] Specify time unit for timeit CLI

[Julian Gindi]

Julian Gindi added the comment:

Just wanted to check to see if there was anything else I should do regarding 
this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] Setting LANG=C breaks Python 3

[STINNER Victor]

Changes by STINNER Victor :


--
title: print() and write() are relying on sys.getfilesystemencoding() instead 
of sys.getdefaultencoding() -> Setting LANG=C breaks Python 3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19846] print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding()

[STINNER Victor]

STINNER Victor added the comment:

"haypo: title: Setting LANG=C breaks Python 3 -> print() and write() are 
relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding()"

Oh, I didn't want to change the title of the issue, it's a bug in Roundup when 
I reply by email :-/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19932] Missing spaces in import.h?

[Ziyuan Lin]

Ziyuan Lin added the comment:

To see the errors, one can install PyCUDA and Theano, and run code at 
http://deeplearning.net/software/theano/tutorial/using_gpu.html#id1 :


import numpy, theano
import theano.misc.pycuda_init
from pycuda.compiler import SourceModule
import theano.sandbox.cuda as cuda

class PyCUDADoubleOp(theano.Op):
def __eq__(self, other):
return type(self) == type(other)
def __hash__(self):
return hash(type(self))
def __str__(self):
return self.__class__.__name__
def make_node(self, inp):
inp = cuda.basic_ops.gpu_contiguous(
   cuda.basic_ops.as_cuda_ndarray_variable(inp))
assert inp.dtype == "float32"
return theano.Apply(self, [inp], [inp.type()])
def make_thunk(self, node, storage_map, _, _2):
mod = SourceModule("""
__global__ void my_fct(float * i0, float * o0, int size) {
int i = blockIdx.x*blockDim.x + threadIdx.x;
if(i

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

python-bugs-list@python.org

[Armin Rigo]

Armin Rigo added the comment:

As you can see in x.py, the underlying question is rather: are weakdicts usable 
in a single thread of a multithreaded program?  I believe that this question 
cannot reasonably be answered No, independently on the answer you want to give 
to your own question.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets

[Guido van Rossum]

Guido van Rossum added the comment:

Then here's a hopeful fix for the Windows situation that relies on the 
socketpair() operation reusing FDs from the lowest value. I'm adding asserts to 
check that this is actually the case. (These are actual assert statements to 
indicate that they are verifying an assumption internal to the test, not 
verifying the functionality under test.)

I'll test it when I next get near a Windows box (Monday in the office) -- or 
someone else with Windows access can let me know.

--
Added file: http://bugs.python.org/file33048/nodup2.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets

[Charles-François Natali]

Charles-François Natali added the comment:

> I will look into the Windows problem, but I suspect the best we can do there 
> is skip the test.

I already took care of that:
http://hg.python.org/cpython/rev/01676a4c16ff

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets

[Guido van Rossum]

Guido van Rossum added the comment:

I don't think we should be more selective about the errno values, the try block 
is narrow enough (just one syscall) and we really don't know what the kernel 
will do on different platforms.  And what would we do about it anyway?

I will look into the Windows problem, but I suspect the best we can do there is 
skip the test.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19932] Missing spaces in import.h?

[Ziyuan Lin]

New submission from Ziyuan Lin:

In Include\import.h, line 89-97:

PyAPI_FUNC(PyObject *)_PyImport_FindBuiltin(
const char *name/* UTF-8 encoded string */
);
PyAPI_FUNC(PyObject *)_PyImport_FindExtensionObject(PyObject *, PyObject *);
PyAPI_FUNC(int)_PyImport_FixupBuiltin(
PyObject *mod,
char *name  /* UTF-8 encoded string */
);
PyAPI_FUNC(int)_PyImport_FixupExtensionObject(PyObject*, PyObject *, PyObject 
*);


Shouldn't they be the following:

PyAPI_FUNC(PyObject *) _PyImport_FindBuiltin(
const char *name/* UTF-8 encoded string */
);
PyAPI_FUNC(PyObject *) _PyImport_FindExtensionObject(PyObject *, PyObject *);
PyAPI_FUNC(int)_PyImport_FixupBuiltin(
PyObject *mod,
char *name  /* UTF-8 encoded string */
);
PyAPI_FUNC(int) _PyImport_FixupExtensionObject(PyObject*, PyObject *, PyObject 
*);

--
messages: 205605
nosy: Ziyuan.Lin
priority: normal
severity: normal
status: open
title: Missing spaces in import.h?
type: compile error
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19915] int.bit_at(n) - Accessing a single bit in O(1)

[anon]

anon added the comment:

Then I think we're in agreement with regards to bits_at. :) What should happen 
next?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

python-bugs-list@python.org

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think the underlying question is: are weak dicts otherwise MT-safe?

--
versions: +Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11299] Allow deepcopying paused generators

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Unless I misunderstood things, and deepcopying a generator would imply
> to also copy its whole source of data?

deepcopying is "deep", and so would have to recursively deepcopy the
generator's local variables...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11299] Allow deepcopying paused generators

[Bastien Montagne]

Bastien Montagne added the comment:

Yes, itertools.tee just keep in memory elements produced by the "most advanced" 
iterator, until the "least advanced" iterator consumes them. It may not be a 
big issue in most cases, but I can assure you that when you have to iter 
several times over a million of vertices, this is not a good solution… ;)

Fortunately, in this case I can just produce several times the same generator, 
but still, would be nicer (at least on the “beauty of the code” aspect) if 
there was a way to really duplicate generators.

Unless I misunderstood things, and deepcopying a generator would imply to also 
copy its whole source of data?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

python-bugs-list@python.org

[Ned Deily]

Changes by Ned Deily :


--
nosy: +fdrake, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11299] Allow deepcopying paused generators

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The issue here is copy.deepcopy will raise an exception whenever it
> encounters a generator. We would like to do better here.
> Unfortunately, using itertools.tee is not a solution here because it
> does not preserve the type of the object.

Indeed, itertools.tee is not a general solution for copy.deepcopy, but
it's a good solution to *avoid* calling copy.deepcopy when you simply
want to "fork" a generator.

IMHO supporting live generators (and therefore frame objects) in
copy.deepcopy would be a waste of effort.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11299] Allow deepcopying paused generators

[Ram Rachum]

Ram Rachum added the comment:

"Instead of copy.deepcopy, why not call itertools.tee?"

It's hard for me to give you a good answer because I submitted this ticket 2 
years ago, and nowadays I don't have personal interest in it anymore.

But, I think `itertools.tee` wouldn't have worked for me, because it just saves 
the value rather than really duplicating the generator.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11299] Allow deepcopying paused generators

[Alexandre Vassalotti]

Alexandre Vassalotti added the comment:

The issue here is copy.deepcopy will raise an exception whenever it encounters 
a generator. We would like to do better here. Unfortunately, using 
itertools.tee is not a solution here because it does not preserve the type of 
the object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19883] Integer overflow in zipimport.c

[Gregory P. Smith]

Gregory P. Smith added the comment:

comments added to the patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11299] Allow deepcopying paused generators

[Antoine Pitrou]

Antoine Pitrou added the comment:

Instead of copy.deepcopy, why not call itertools.tee?

For the record, pickling a live generator implies pickling a frame object. We 
wouldn't be able to guarantee cross-version compatibility for such pickled 
objects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Antoine Pitrou]

Antoine Pitrou added the comment:

I would say it's now closed. If there's some fine tuning needed, separate 
issues should be opened.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19929] subprocess: increase read buffer size

[Gregory P. Smith]

Gregory P. Smith added the comment:

I saw a small regression over 4k when using a 64k buffer on one of my machines 
(dual core amd64 linux).  With 32k everything (amd64 linux, armv7l 32-bit 
linux, 64-bit os x 10.6) showed a dramatic improvement on the microbenchmark.  
approaching 50% less cpu use in many cases.

i doubt applications will notice as much as they're likely to be dominated by 
their own application code rather than the subprocess internals.

re: 3.3 or not, true, but since it doesn't change any APIs and is minor I did 
it anyways.  If you think it doesn't belong there, leave it to the release 
manager to back out.  This and the #19506 change should be invisible to users.

--
resolution:  -> fixed
stage: needs patch -> commit review
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19929] subprocess: increase read buffer size

[Roundup Robot]

Roundup Robot added the comment:

New changeset 03a056c3b88e by Gregory P. Smith in branch '3.3':
Fixes issue #19929: Call os.read with 32768 within subprocess.Popen
http://hg.python.org/cpython/rev/03a056c3b88e

New changeset 4de4b5a4e405 by Gregory P. Smith in branch 'default':
Fixes issue #19929: Call os.read with 32768 within subprocess.Popen
http://hg.python.org/cpython/rev/4de4b5a4e405

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19929] subprocess: increase read buffer size

[Charles-François Natali]

Charles-François Natali added the comment:

> Roundup Robot added the comment:
>
> New changeset 03a056c3b88e by Gregory P. Smith in branch '3.3':
> Fixes issue #19929: Call os.read with 32768 within subprocess.Popen
> http://hg.python.org/cpython/rev/03a056c3b88e

Not that it bothers me, but AFAICT this isn't a bugfix, and as such
shouldn't be backported to 3.3, no?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18430] gzip, bz2, lzma: peek advances file position of existing file object

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5ca6e8af0aab by Nadeem Vawda in branch '3.3':
#18430: Document that peek() may change the position of the underlying file for
http://hg.python.org/cpython/rev/5ca6e8af0aab

New changeset 0f587fe304be by Nadeem Vawda in branch 'default':
Closes #18430: Document that peek() may change the position of the underlying
http://hg.python.org/cpython/rev/0f587fe304be

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora without threads 3.x" buildbot: urllib3 dependency requires the threading module

[Vinay Sajip]

Vinay Sajip added the comment:

This commit in distlib uses uncompressed launcher executables which pass the 
virustotal.com checks:

https://bitbucket.org/pypa/distlib/commits/e23c9e4fd3125fa88063de4dec80367b1ac82aff

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe

[Vinay Sajip]

Vinay Sajip added the comment:

This commit in distlib uses uncompressed launcher executables which pass the 
virustotal.com checks:

https://bitbucket.org/pypa/distlib/commits/e23c9e4fd3125fa88063de4dec80367b1ac82aff

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19856] shutil.move() can't move a directory in non-empty directory on Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Francisco for testing. Here is different bug than I expected.

Looks as shutil.move() can't move a directory in non-empty directory on Windows.

--
nosy: +hynek, tarek
title: Possible bug in shutil.move() on Windows -> shutil.move() can't move a 
directory in non-empty directory on Windows

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16549] regression: -m json.tool module is broken

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

Somehow these errors do not occur today. Maybe they were side effects of other 
failures in test_json. Closing for now.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19923] OSError: [Errno 512] Unknown error 512 in test_multiprocessing

[Charles-François Natali]

Charles-François Natali added the comment:

Looks like a kernel bug.
errno 512 is ERESTARTSYS, which shouldn't leak to user-mode.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19856] Possible bug in shutil.move() on Windows

[Francisco Martín Brugué]

Francisco Martín Brugué added the comment:

Just feedback on windows7. I tried the tests inside IDLE and done 'Run Module' 
(F5) (deleting the directories between tests):

test_A:

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo/', 'bar/')

test_B:

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo', 'bar/')

and finally test_C:

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo\\', 'bar/')


... and got the same traceback:

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on 
win32
Type "copyright", "credits" or "license()" for more information.
>>>  RESTART 
>>> 

Traceback (most recent call last):
  File "D:\temp\test.py", line 4, in 
shutil.move('foo/','bar/')
  File "D:\programs\Python27\lib\shutil.py", line 291, in move
raise Error, "Destination path '%s' already exists" % real_dst
Error: Destination path 'bar/' already exists
>>>

--
nosy: +francismb

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19931] namedtuple docstrings are verbose for no added benefit

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19931] namedtuple docstrings are verbose for no added benefit

[Ned Batchelder]

New submission from Ned Batchelder:

When I make a namedtuple, I get automatic docstrings that use a lot of words to 
say very little.  Sphinx autodoc produces this:

```
class Key

Key(scope, user_id, block_scope_id, field_name)

__getnewargs__()

Return self as a plain tuple. Used by copy and pickle.

__repr__()

Return a nicely formatted representation string

block_scope_id None

Alias for field number 2

field_name None

Alias for field number 3

scope None

Alias for field number 0

user_id None

Alias for field number 1
```
The individual property docstrings offer no new information over the summary at 
the top.   I'd like namedtuple to be not so verbose where it has no useful 
information to offer.  The one-line summary is all the information namedtuple 
has, so that is all it should include in the docstring:

```
class Key

Key(scope, user_id, block_scope_id, field_name)
```

--
components: Library (Lib)
messages: 205584
nosy: nedbat
priority: normal
severity: normal
status: open
title: namedtuple docstrings are verbose for no added benefit
versions: Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16669] Docstrings for namedtuple

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Unhide this discussion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16669] Docstrings for namedtuple

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16669] Docstrings for namedtuple

[Ned Batchelder]

Ned Batchelder added the comment:

I'll add my voice to those asking for a way to put docstrings on namedtuples.  
As it is, namedtuples get automatic docstrings that seem to me to be almost 
worse than none.  Sphinx produces this:

```
class Key

Key(scope, user_id, block_scope_id, field_name)

__getnewargs__()

Return self as a plain tuple. Used by copy and pickle.

__repr__()

Return a nicely formatted representation string

block_scope_id None

Alias for field number 2

field_name None

Alias for field number 3

scope None

Alias for field number 0

user_id None

Alias for field number 1
```

Why are `__getnewargs__` and `__repr__` included at all, they aren't useful for 
API documentation.  The individual property docstrings offer no new information 
over the summary at the top.   I'd like namedtuple not to be so verbose where 
it has no useful information to offer.  The one-line summary is all the 
information namedtuple has, so that is all it should include in the docstring:

```
class Key

Key(scope, user_id, block_scope_id, field_name)
```

--
nosy: +nedbat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19930] os.makedirs('dir1/dir2', 0) always fails

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Vajrasky. Now this check is skipped on Windows.

--
Added file: http://bugs.python.org/file33047/os_makedirs_mode_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19758] Warnings in tests

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Christian and Eric.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19830] test_poplib emits resource warning

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +haypo
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19535] Test failures with -OO

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19700] Update runpy for PEP 451

[Brett Cannon]

Brett Cannon added the comment:

Can you file a separate bug, Nick, for the importlib.find_spec() change you are 
after? I don't want to lose track of it (and I get what you are after but we 
should discuss why importlib.find_loader() was designed the way it was 
initially).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19535] Test failures with -OO

[Roundup Robot]

Roundup Robot added the comment:

New changeset 910b1cb5176c by Serhiy Storchaka in branch '3.3':
Issue #19535: Fixed test_docxmlrpc when python is run with -OO.
http://hg.python.org/cpython/rev/910b1cb5176c

New changeset e71142abf8b6 by Serhiy Storchaka in branch 'default':
Issue #19535: Fixed test_docxmlrpc, test_functools, test_inspect, and
http://hg.python.org/cpython/rev/e71142abf8b6

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19927] Path-based loaders lack a meaningful __eq__() implementation.

[Brett Cannon]

Brett Cannon added the comment:

I'm fine with the suggestions Nick made. While loaders are not technically 
immutable (and thus technically probably shouldn't define __hash__), they have 
not been defined to be mutable and mucked with anyway, so I have no issue if 
someone breaks the hash of a loader by changing an attribute post-hash.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)

[Brett Cannon]

Brett Cannon added the comment:

(c) it is then! I would just take the time to call bool() on the arg to 
coalesce it into a True/False thing (which maybe makes sense in __init__() as 
well).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)

[Brett Cannon]

Brett Cannon added the comment:

Actually, ignore the __init__() part of my last comment since it's set to False 
directly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19904] Add 128-bit integer support to struct

[Francisco Martín Brugué]

Francisco Martín Brugué added the comment:

> If performance is the reason for the feature: My impression is that
> the goal of the struct module is not necessarily top performance.

I'm not sure if it applies but on #19905 (message 205345 [1])
is said its a dependency for that issue


[1] http://bugs.python.org/issue19905#msg205345

--
nosy: +francismb

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19929] subprocess: increase read buffer size

[Antoine Pitrou]

Antoine Pitrou added the comment:

Linux, 64-bit quad core:

With 4K buffer:

$ time ./python test_sub_read.py 
0.25217683400114765

real0m0.296s
user0m0.172s
sys 0m0.183s

With 64K buffer:

$ time ./python test_sub_read.py 
0.0925754177548

real0m0.132s
user0m0.051s
sys 0m0.096s

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19099] struct.pack fails first time with unicode fmt

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Fixed. Thank you Musashi for your report.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19099] struct.pack fails first time with unicode fmt

[Roundup Robot]

Roundup Robot added the comment:

New changeset 42d3afd29460 by Serhiy Storchaka in branch '2.7':
Issue #19099: The struct module now supports Unicode format strings.
http://hg.python.org/cpython/rev/42d3afd29460

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19930] os.makedirs('dir1/dir2', 0) always fails

[Vajrasky Kok]

Vajrasky Kok added the comment:

Fails on Windows Vista.

==
FAIL: test_mode (__main__.MakedirTests)
--
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 907, in test_mode
self.assertEqual(stat.S_IMODE(os.stat(parent).st_mode), 0o775)
AssertionError: 511 != 509

--
Ran 157 tests in 1.865s

FAILED (failures=1, skipped=61)
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 2511, in 
test_main()
  File "C:\Users\vajrasky\Code\cpython\lib\test\support\__init__.py", line 1831,
 in decorator
return func(*args)
  File "Lib\test\test_os.py", line 2507, in test_main
FDInheritanceTests,
  File "C:\Users\vajrasky\Code\cpython\lib\test\support\__init__.py", line 1719,
 in run_unittest
_run_suite(suite)
  File "C:\Users\vajrasky\Code\cpython\lib\test\support\__init__.py", line 1694,
 in _run_suite
raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib\test\test_os.py", line 907, in test_mode
self.assertEqual(stat.S_IMODE(os.stat(parent).st_mode), 0o775)
AssertionError: 511 != 509

The permission of directory on Windows no matter what mode you give or umask 
you give to support.temp_umask, is always 0o777 (or 511). I think this test 
does not make sense in Windows.

>>> os.mkdir('cutecat', 0o555)
>>> os.mkdir('cutecat2', 0o777)
>>> os.stat('cutecat')
os.stat_result(st_mode=16895, st_ino=3940649674207852, st_dev=3960548439, st_nli
nk=1, st_uid=0, st_gid=0, st_size=0, st_atime=1386517061, st_mtime=1386517061, s
t_ctime=1386517061)
>>> os.stat('cutecat2')
os.stat_result(st_mode=16895, st_ino=5066549581050708, st_dev=3960548439, st_nli
nk=1, st_uid=0, st_gid=0, st_size=0, st_atime=1386517067, st_mtime=1386517067, s
t_ctime=1386517067)

Either that, or I am missing something.

--
nosy: +vajrasky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What is the status of this issue?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19878] bz2.BZ2File.__init__() cannot be called twice with non-existent file

[Roundup Robot]

Roundup Robot added the comment:

New changeset 55a748f6e396 by Nadeem Vawda in branch '2.7':
Closes #19878: Fix segfault in bz2 module.
http://hg.python.org/cpython/rev/55a748f6e396

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11299] Allow deepcopying paused generators

[Bastien Montagne]

Changes by Bastien Montagne :


--
nosy: +mont29

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com