[issue20621] Issue with zipimport in 3.3.4 and 3.4.0rc1

[Paul Moore]

Paul Moore added the comment:

I'm afraid I don't have things set up to do a Python build right now. I *might* 
have time later, and if so I'll give it a try, but I can't promise. Also, I 
haven't yet managed to show the issue on 3.4.0rc1, but that may be because my 
check wasn't as complete as Steve's.

--

___
Python tracker 

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

[issue20568] Pass --default-install to ensurepip in the Windows installers

[Nick Coghlan]

Nick Coghlan added the comment:

Martin, the addition of "--default-install" to the ensurepip args is all that 
should be needed (it won't trigger if pip isn't upgraded, but rc2 will contain 
0.15.3 to fix a couple of glitches that remained in rc1)

--
assignee: ncoghlan -> loewis
keywords: +patch
stage: needs patch -> commit review
Added file: 
http://bugs.python.org/file34075/issue20568_install_unversioned_pip_on_Windows.diff

___
Python tracker 

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

[issue20621] Issue with zipimport in 3.3.4 and 3.4.0rc1

[Paul Moore]

Paul Moore added the comment:

OK, I have a build of 3.4 that shows the bug. How do I revert 
http://hg.python.org/cpython/rev/20b77ff040b6 ? hg backout -r 20b77ff040b6 says 
"abort: cannot backout a merge changeset".

--

___
Python tracker 

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

[issue20621] Issue with zipimport in 3.3.4 and 3.4.0rc1

[Paul Moore]

Paul Moore added the comment:

I tried hg backout 2807a5f011e4. It gave errors in the form of dialog boxes 
titled "Microsoft Visual Studio" saying "File '-nosplash' not found". I've no 
idea where these came from and whether they matter, but I tried clicking OK. 
Mercurial then said

merging Lib/test/test_zipimport.py
 output file Lib/test/test_zipimport.py appears unchanged
was merge successful (yn)?

If I say "yes", the backout seems to complete, but building and testing again 
shows the problem still there.

So I'm stuck. That's about as much as I can do without some advice.

--

___
Python tracker 

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

[issue20550] Use specific asserts in collections tests

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Oh, sorry. Here is a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file34076/collections_tests_asserts.patch

___
Python tracker 

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

[issue19744] test_venv and installation fail if SSL/TLS is not available

[Nick Coghlan]

Nick Coghlan added the comment:

Attached patch tweaks the ensurepip CLI to check immediately for ssl support, 
and avoid printing a traceback if it is missing.

However, missing SSL support still fails the call, which fails installation.

--
keywords: +patch
resolution: fixed -> 
stage: committed/rejected -> commit review
Added file: http://bugs.python.org/file34077/issue19744_ensurepip_no_ssl.diff

___
Python tracker 

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

[issue19744] test_venv and installation fail if SSL/TLS is not available

[Nick Coghlan]

Nick Coghlan added the comment:

This patch is probably a better bet - it just prints a message to stderr to say 
that we're ignoring the ensurepip failure during installation.

pip wouldn't work anyway in a Python without ssl built, but at least this way 
that Python can still be installed without the ensurepip invocation complaining.

Ned, if this approach sounds reasonable to you, I'll commit this one.

--
assignee: ncoghlan -> ned.deily
nosy: +ned.deily
Added file: 
http://bugs.python.org/file34078/issue19744_ensurepip_install_ok_without_ssl.diff

___
Python tracker 

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

[issue19744] test_venv and installation fail if SSL/TLS is not available

[Nick Coghlan]

Nick Coghlan added the comment:

Note: I'm deliberately not worrying about ensurepip._uninstall here, since that 
only gets invoked implicitly in the Windows uninstaller, and that should always 
have a valid SSL to play with.

Always, since I worked out how to disable ssl in my local build (just a small 
tweak to setup.py), I was able to verify the correct behaviour of 
test_ensurepip and test_venv with SSL unavailable.

--

___
Python tracker 

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

[issue20624] Clarify recommendation to inherit from Exception

[Mark Dickinson]

New submission from Mark Dickinson:

>From http://docs.python.org/3.4/library/exceptions.html:

"... programmers are encouraged to at least derive new exceptions from the 
Exception class and not BaseException."

This wording had someone I've talked to recently thinking that user-defined 
exceptions should inherit *directly* from Exception.

Suggested rewording, dropping the "at least" qualification that as far as I can 
tell serves no real purpose:

"... programmers are encouraged to derive new exceptions from the Exception 
class or one of its subclasses, and not from BaseException."

--
assignee: docs@python
components: Documentation
messages: 211214
nosy: docs@python, mark.dickinson
priority: normal
severity: normal
status: open
title: Clarify recommendation to inherit from Exception
versions: Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Jonas Wielicki]

New submission from Jonas Wielicki:

Assume I have this code:

class Spam:
def eggs(__some_kwarg:int=None):
print(__some_kwarg)

I can call Spam.bar with keyword arguments as expected from mangling:

>>> Spam.eggs(10)
10
>>> Spam.eggs(_Spam__some_kwarg=10)
10

However, in the __annotations__ field, the argument name is not mangled:

>>> Spam.eggs.__annotations__
{'__some_kwarg': }

This is an inconsistency which makes it difficult to work with function 
annotations in this case.

--
components: Interpreter Core
messages: 211215
nosy: jonasw
priority: normal
severity: normal
status: open
title: Argument names in __annotations__ are not mangled for functions defined 
inside class scope
type: behavior
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

[issue20547] Use specific asserts in bigmem tests

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Additionally, the "more specific tests" introduce some additional opacity
> that is harmful for knowing what methods and operators are specifically
> used internally in test method.  For end users of Python, they don't have
> to worry much about this, but we as developers of core types really care
> whether self.assertLessThan(x, y) really does x < y, or x.__lt__(y), or
> "not y >= x", etc.

If the test explicitly designed to test relation or boolean operations, I 
leave it as is. I try to be very careful.

After more careful reviewing this patch, I have found than some tests 
shouldn't be changed, because they produce utterly large error message in case 
of a failure (even if resulted message is truncated, as in case of 
assertEqual, large intermediate strings are created). Here is corrected patch.

--
Added file: http://bugs.python.org/file34079/test_bigmem_asserts_2.patch

___
Python tracker 

___diff -r 0f357cf011d3 Lib/test/test_bigmem.py
--- a/Lib/test/test_bigmem.py   Thu Feb 13 10:49:30 2014 +0200
+++ b/Lib/test/test_bigmem.py   Fri Feb 14 13:47:49 2014 +0200
@@ -866,7 +866,7 @@
 h1 = hash(t1)
 del t1
 t2 = (0,) * (size + 1)
-self.assertFalse(h1 == hash(t2))
+self.assertNotEqual(h1, hash(t2))
 
 @bigmemtest(size=_2G + 10, memuse=8)
 def test_index_and_slice(self, size):
@@ -992,8 +992,8 @@
 l = [sys.stdout] * size
 l += l
 self.assertEqual(len(l), size * 2)
-self.assertTrue(l[0] is l[-1])
-self.assertTrue(l[size - 1] is l[size + 1])
+self.assertIs(l[0], l[-1])
+self.assertIs(l[size - 1], l[size + 1])
 
 @bigmemtest(size=_2G // 2 + 2, memuse=24)
 def test_inplace_concat_small(self, size):
@@ -1092,13 +1092,13 @@
 l = ['']
 l *= size
 self.assertEqual(len(l), size)
-self.assertTrue(l[0] is l[-1])
+self.assertIs(l[0], l[-1])
 del l
 
 l = [''] * size
 l *= 2
 self.assertEqual(len(l), size * 2)
-self.assertTrue(l[size - 1] is l[-1])
+self.assertIs(l[size - 1], l[-1])
 
 @bigmemtest(size=_2G // 2 + 2, memuse=16)
 def test_inplace_repeat_small(self, size):
@@ -1132,8 +1132,8 @@
 l = [object()] * size
 l.append(object())
 self.assertEqual(len(l), size+1)
-self.assertTrue(l[-3] is l[-2])
-self.assertFalse(l[-2] is l[-1])
+self.assertIs(l[-3], l[-2])
+self.assertIsNot(l[-2], l[-1])
 
 @bigmemtest(size=_2G // 5 + 2, memuse=8 * 5)
 def test_count(self, size):
@@ -1145,8 +1145,8 @@
 l = [object] * size
 l.extend(l)
 self.assertEqual(len(l), size * 2)
-self.assertTrue(l[0] is l[-1])
-self.assertTrue(l[size - 1] is l[size + 1])
+self.assertIs(l[0], l[-1])
+self.assertIs(l[size - 1], l[size + 1])
 
 @bigmemtest(size=_2G // 2 + 2, memuse=16)
 def test_extend_small(self, size):
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10728] argparse.ArgumentParser.print_help uses sys.stdout

[Jan-Philip Gehrcke]

Jan-Philip Gehrcke added the comment:

The version action currently writes to stderr. The _VersionAction(Action)'s 
__call__() method finishes off with 

parser.exit(message=formatter.format_help())

and parser.exit() by default writes to stderr.

Here, Steven says "Help is definitely intended to print to stdout." and I 
expected the same to happen regarding the version information. Why should it go 
to stderr?

I see that this is a minor problem and only if someone here agrees I would open 
an issue for that.

--
nosy: +jgehrcke

___
Python tracker 

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

[issue20547] Use specific asserts in bigmem tests

[Raymond Hettinger]

Raymond Hettinger added the comment:

> I try to be very careful.

It's great to be careful, but it is a smarter move to not change the test suite 
at all (except in cases where there is a known problem).  

There is almost zero benefit to the patch (i.e. the tests are currently not 
failing and have been stable for a long time).  You risk making a mistake, 
leaving an undetected hole in the tests, and increasing chances of future 
regression during normal maintenance.

Further, this patch churns the code away from what the original test case 
authors were thinking about when they were deeply engaged with the code.  That 
is why Guido wants only "holistic" refactorings.

Another issue is that if you make the extensive test suite changes, there is no 
case for backporting those changes (especially for Python 2.7).  But then, if 
the versions don't line up, it makes cross-version maintenance more difficult 
if an actual bug arises (i.e. the patches won't apply cleanly).

In short, I recommend that you please don't do this.  It isn't good for the 
project.   Thank you.

--

___
Python tracker 

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

[issue20621] Issue with zipimport in 3.3.4 and 3.4.0rc1

[Paul Moore]

Paul Moore added the comment:

Note - we're going to have to work around this bug in Virtualenv (even if it's 
just in code specific to 3.3.4) so a workaround for 3.3.4 and an explanation of 
what's going wrong would be useful, as well as a fix.

--

___
Python tracker 

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

[issue20626] Manager documentation unclear about lists and thread safeness

[Irvin Probst]

New submission from Irvin Probst:

In the the Manager's lists documentation one can read:

"""
list()
list(sequence)
Create a shared list object and return a proxy for it.
"""

IMHO it is really unclear whether these lists have something more than 
traditionnal lists or not. 

When you have a look at managers.py it is quite obvious, unless I'm completely 
wrong, that the underlying shared object is a standard list with a basic proxy 
to expose all the "underscore underscore stuff".

"""
BaseListProxy = MakeProxyType('BaseListProxy', (
'__add__', '__contains__', '__delitem__', '__getitem__', '__len__',
'__mul__', '__reversed__', '__rmul__', '__setitem__',
'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove',
'reverse', 'sort', '__imul__'
))

class ListProxy(BaseListProxy):
def __iadd__(self, value):
self._callmethod('extend', (value,))
return self
def __imul__(self, value):
self._callmethod('__imul__', (value,))
return self

[snip a couple of lines]

SyncManager.register('list', list, ListProxy)
"""

That's really confusing because, unless reading managers.py, you have the 
feeling that the manager's lists() are somehow different than standard lists.

The other problem is that, if you don't know what level of thread-safeness the 
GIL guarantees on the lists in the manager's server thread, you have the 
feeling that the safeness comes from some obscure Manager's black magic 
managing concurrent access for you.

May I suggest to add in the documentation:


1/

"""
list()
list(sequence)
Create a shared list (add here a link to 
http://docs.python.org/3.3/library/stdtypes.html#list) object and return a 
proxy for it.
"""

2/ 

Clearly state somewhere in the manager's documentation that it's the 
developper's job to ensure that the proxied methods are thread safe. Write it 
in bold and red please :-) 

3/ 
Perhaps add an example with a custom object like the code I attached to this 
report.


Thanks for your time.

--
files: example.py
messages: 211220
nosy: Irvin.Probst
priority: normal
severity: normal
status: open
title: Manager documentation unclear about lists and thread safeness
Added file: http://bugs.python.org/file34080/example.py

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +larry, ncoghlan, yselivanov

___
Python tracker 

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

[issue20626] Manager documentation unclear about lists and thread safeness

[Irvin Probst]

Changes by Irvin Probst :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 
3.5

___
Python tracker 

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

[issue20627] Add context manager support to xmlrpc.client.ServerProxy

[Brett Cannon]

New submission from Brett Cannon:

Otherwise have to call client('close')() to close a server proxy and that's 
just ugly.

--
components: Library (Lib)
messages: 211221
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add context manager support to xmlrpc.client.ServerProxy
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue20627] Add context manager support to xmlrpc.client.ServerProxy

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
keywords: +easy

___
Python tracker 

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

[issue19744] test_venv and installation fail if SSL/TLS is not available

[Ned Deily]

Ned Deily added the comment:

issue19744_ensurepip_install_ok_without_ssl.diff looks good to me.  Note, 
though, that with it and with ssl support missing, test_ensurepip fails 
somewhat obscurely:

==
FAIL: test_bootstrap_version (test.test_ensurepip.TestBootstrappingMainFunction)
--
Traceback (most recent call last):
  File "/py/dev/3x/root/uxd/lib/python3.4/test/test_ensurepip.py", line 293, in 
test_bootstrap_version
ensurepip._main(["--version"])
AssertionError: SystemExit not raised

--

--

___
Python tracker 

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

[issue20621] Issue with zipimport in 3.3.4 and 3.4.0rc1

[Steve Dower]

Steve Dower added the comment:

I found that using zipimporter('...whl').load_module(pip) directly works fine, 
so you may be able to use that as a workaround. (Forgot to mention it in my 
initial comment, but that's what prompted me to check against the ABC.)

I also backed out that change from the latest 3.3, built and tried again but 
got the same result. That said, I'm not 100% sure my build is reliable, since I 
don't regularly build CPython right now. Here are my results:

Python 3.3.4+ (3.3:4330b3cb7245+, Feb 14 2014, 09:03:52) [MSC v.1800 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path[:] = r"D:\...\pip-1.5.2-py2.py3-none-any.whl"
>>> import pip
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 'pip'


I also tried using zipimporter directly, which got further but still failed 
(probably because of my build - _ssl was not built):

>>> from zipimport import zipimporter
>>> zipimporter(r"D:\...\pip-1.5.2-py2.py3-none-any.whl").load_module('pip')
Traceback (most recent call last):
  File "", line 1, in 
  File "D:\...\pip-1.5.2-py2.py3-none-any.whl\pip\__init__.py", line 10, in 

  File "D:\...\pip-1.5.2-py2.py3-none-any.whl\pip\util.py", line 18, in 
  File "D:\...\pip-1.5.2-py2.py3-none-any.whl\pip\_vendor\distlib\version.py", 
line 14, in 
  File "D:\...\pip-1.5.2-py2.py3-none-any.whl\pip\_vendor\distlib\compat.py", 
line 66, in 
ImportError: cannot import name HTTPSHandler

--

___
Python tracker 

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

[issue20621] Issue with zipimport in 3.3.4 and 3.4.0rc1

[Steve Dower]

Steve Dower added the comment:

Oddly enough, this works with 3.3.4 as released:

>>> import sys, zipfile
>>> with zipfile.ZipFile('test.zip', 'w') as f:
...   f.writestr('test/__init__.py', b'print("Success!")')
...
>>> sys.path[:] = ['test.zip']
>>> import test
Success!

Maybe wheel is creating archives with settings that zipimport doesn't like? 
(Unless you invoke load_module directly...)

--

___
Python tracker 

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

[issue20626] Manager documentation unclear about lists and thread safeness

[Zachary Ware]

Changes by Zachary Ware :


--
stage:  -> needs patch
type:  -> enhancement
versions:  -Python 3.1, Python 3.2, Python 3.5

___
Python tracker 

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

[issue20620] Update the min()/max() docs for the new default argument

[Berker Peksag]

Berker Peksag added the comment:

Here's a patch to update the min() and max() documentations.

--
keywords: +patch
nosy: +berker.peksag
Added file: http://bugs.python.org/file34081/issue20620.diff

___
Python tracker 

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

[issue20628] csv.DictReader

[Roger Erens]

New submission from Roger Erens:

The sections on DictReader and DictWriter do not give information on what the 
type is of the parameter 'fieldnames'. The source code comments that it is a 
'list of keys for the dict'.

--
assignee: docs@python
components: Documentation
messages: 211226
nosy: docs@python, rogererens
priority: normal
severity: normal
status: open
title: csv.DictReader
type: enhancement
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue20601] tracing and tests that raise an exception in a SIGALRM handler

[Xavier de Gaye]

Xavier de Gaye added the comment:

With the previous patch, after the signal arrives and the first call to 
PyErr_CheckSignals, PyErr_CheckSignals is called for each bytecode processed in 
the eval loop
of the tracing function (and the eval loop of functions called by the tracing 
function, and also functions called in the other threads).
This is annoying. The attached patch fixes this and adds a test case.

--
Added file: http://bugs.python.org/file34082/tracing_signals_2.patch

___
Python tracker 

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

[issue20621] Issue with zipimport in 3.3.4 and 3.4.0rc1

[Paul Moore]

Paul Moore added the comment:

Thanks for the workaround. I'm going to try to do some serious testing of all 
this over the weekend, I'll let you know how it goes.

--

___
Python tracker 

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

[issue20627] Add context manager support to xmlrpc.client.ServerProxy

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo
stage: test needed -> needs patch

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue18943] argparse: default args in mutually exclusive groups

[paul j3]

paul j3 added the comment:

This patch corrects the handling of `seen_non_default_action` in another case - 
a positional with '?' and `type=int` (or other conversion).

if

parser.add_argument('badger', type=int, nargs='?', default=2) # or '2'

and the original test 'seen_non_default_actions' is:

if argument_values is not action.default

'argument_values' will be an 'int' regardless of the default.  But it will pass 
the 'is' test with the (small) int default but not the string default.

With the patch proposed here, both defaults behave the same - 'badger' will not 
appear in 'seen_non_default_actions' if it did not occur in the 
argument_strings (i.e. match an empty string).

I may add case like this to `test_argparse.py` for this patch.

--

___
Python tracker 

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

[issue20624] Clarify recommendation to inherit from Exception

[Éric Araujo]

Éric Araujo added the comment:

In my reading “at least” means that exceptions should derive from Exception if 
they don’t derive from a more specific subclass.  IOW the same meaning as your 
proposed wording, but less clear.  +1 to your rewording.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue20622] Python3.3 venv pip fails to run if path contains spaces

[Éric Araujo]

Éric Araujo added the comment:

Due to the way the shell or kernel parses the shebang, you can’t have spaces in 
the path to the interpreter:

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

The solution is to separate your virtualenv from the directory containing your 
code.  (virtualenvwrapper works in that way for example.)  virtualenv’s job is 
to have a copied Python with an isolated site-packages; it does not matter 
whether the Python is in your project directory (./bin/python) or anywhere else 
(~/venvs/strategist/bin/python).

--
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Yury Selivanov added the comment:

It looks like it's a bug.

Spam.eggs.__code__.co_varnames will have '_Spam__some_kwarg' as a name of the 
first parameter. So __annotations__ should have '_Spam__some_kwarg' instead of 
'__some_kwarg'.

--

___
Python tracker 

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

[issue20628] csv.DictReader

[R. David Murray]

R. David Murray added the comment:

Fieldnames is referred to as a sequence, which does define its type.  That 
said, defining the type earlier in that paragraph would probably be a good 
thing.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Yury Selivanov added the comment:

Furthermore:

class Foo:
  def bar(self, *, __kw:'anno'='default'):
pass

>>> Foo.bar.__annotations__
{'__kw': 'anno'}
>>> Foo.bar.__kwdefaults__
{'_Foo__kw': 'default'}

--

___
Python tracker 

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

[issue20606] Operator Documentation Example doesn't work

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo, rhettinger

___
Python tracker 

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

[issue20559] urllib/http fail to sanitize a non-ascii url

[Éric Araujo]

Éric Araujo added the comment:

Even if Python 3’s text model is based on Unicode, some data formats have their 
own rules.  There’s a long debate about whether URIs should be bytes or text; 
it looks like unlike web browsers, urllib/httplib don’t try to be smart with 
the URIs they are given but just require them to be properly formatted, i.e. 
not containing any space or characters that are not %-encoded.

Is the documentation clear about this behaviour?  If not, it would probably be 
simpler to improve the documentation rather than change the behaviour.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue20573] "built-in repr()" function link on the repr module documentation is incorrect

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue20598] argparse docs: '7'.split() is confusing magic

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue20573] "built-in repr()" function link on the repr module documentation is incorrect

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7c47529bda0e by Benjamin Peterson in branch '2.7':
fix links to builtin repr function (closes #20573)
http://hg.python.org/cpython/rev/7c47529bda0e

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Yury Selivanov added the comment:

Patch is attached. Please review.

--
keywords: +patch
nosy: +benjamin.peterson, nnorwitz
Added file: http://bugs.python.org/file34083/issue_20625_01.patch

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Changes by Yury Selivanov :


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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Changes by Yury Selivanov :


--
priority: normal -> high

___
Python tracker 

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

[issue20619] tracemalloc changes col_offset attribute for _ast.arg objects

[STINNER Victor]

STINNER Victor added the comment:

The fix should not be backported?

--

___
Python tracker 

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

[issue20619] tracemalloc changes col_offset attribute for _ast.arg objects

[Benjamin Peterson]

Benjamin Peterson added the comment:

This is a 3.4 only issue.

--

___
Python tracker 

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

[issue11588] Add "necessarily inclusive" groups to argparse

[paul j3]

paul j3 added the comment:

The suggestion in this issue is to add a 'mutually_inclusive_group' mechanism, 
one that would let users specify that certain sets of arguments must occur 
together.  Furthermore there was mention of allowing some sort of nesting.

Modeling it on the mutually_exclusive_group would be straight forward.  But 
should it affect the usage and help display?mutually_exclusive_groups add a 
messy layer to the usage formatting.

The only place such a group would act would be at the end of 
'_parse_known_args', where the current code checks for things like required 
actions (and mxgroups). A test at this point could use 'namespace', 
'seen_actions' and 'seen_non_default_actions' to check whether the required 
group actions were seen.

But the only thing that the argument_group contributes to this test is a list 
of argument names ('dest'?).  Why not provide this list directly?  And what if 
the user wants A to occur together with either B or C, but not both?  Or make 
the inclusivity conditional on the value of A?

Currently users can define argument interactions in a couple of ways.  They can 
define custom Actions. In test_argparse.py there's a custom Actions test that 
does something like this (using '--spam' and 'badger').  But tests in Actions 
depend on the order in which arguments are given.

An alternative is to test for interactions of arguments after `parse_args`.  
However the only information that the user has at this point is the args 
namespace.  Reliably distinguishing between non-occurrence of arguments and 
default values can be difficult.

I am proposing 'cross_test' mechanism that would give the user access to the 
'seen_actions' and 'seen_non_default_actions' sets that 
'mutually_exclusive_groups' use.  Specifically an optional function can be 
called at the end of '_parse_known_args' that has access to these sets as well 
as the parser and the namespace.

The core of the change would be adding

cross_test = getattr(self, 'cross_test', None)
if cross_test:
cross_test(self, namespace, extras, seen_actions, 
seen_non_default_actions)

at the end of 'parser._parse_known_args'.  In addition 'cross_test' (or some 
other name) could be added to the 'ArgumentParser.__init__' arguments.

The feature could be used by defining such a 'cross_test' function and adding 
it to the parser (either instance or subclass)

def foobar(self, namespace, extras, seen_actions, seen_non_default_actions):
...
(raise self.error(...))

parser.cross_test = foobar

The patch proposed http://bugs.python.org/issue18943 should be included
with any changes here since it refines the setting of 
'seen_non_default_actions'.

I am working on tests and examples of such functionality.

--
nosy: +paul.j3

___
Python tracker 

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

[issue20626] Manager documentation unclear about lists and thread safeness

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +sbt

___
Python tracker 

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

[issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux

[Alan Ning]

New submission from Alan Ning:

I am seeing a strange issue with bitfields and BigEndianStructure under Ubuntu 
12.04 x64, Python 2.7.3.

This bug only occurs if I define my bitfields using c_uint. If I switch to 
c_ushort, it goes away.

Below is a simple code that highlights the problem. I have two structures - 
BitField1U and BitField2U. It is a union of a 4 bytes array and a bitfield 
definition.

Under Linux, by simply setting fields.a = 1 twice, it modifies the underlying 
byte array twice in a very different way. This behavior does not occur in 
Windows.

Output: Ubuntu 12.04x64 Python 2.7.3
2000
2020 <- problem
2000
2000

Output: Window 7 x64 Python 2.7.3
2000
2000
2000
2000

This bug was originally reported as a question in StackOverflow. 
http://stackoverflow.com/questions/21785874/python-ctypes-bitfield-windows-vs-linux


Source code:

import ctypes
import binascii

class BitField1(ctypes.BigEndianStructure):
_pack_ = 1
_fields_ = [
('a', ctypes.c_uint, 3),
('b', ctypes.c_uint, 1),
]

class BitField1U(ctypes.Union):
_pack_ = 1
_fields_ = [("fields", BitField1), 
("raw_bytes", ctypes.c_ubyte * 4)]

class BitField2(ctypes.BigEndianStructure):
_pack_ = 1
_fields_ = [
('a', ctypes.c_ushort, 3),
('b', ctypes.c_ushort, 1),
]

class BitField2U(ctypes.Union):
_pack_ = 1
_fields_ = [("fields", BitField2), 
("raw_bytes", ctypes.c_ubyte * 4)]

def printBytes(raw_bytes) :
ba = bytearray(raw_bytes)
print(binascii.hexlify(ba))

def printFields(fields) :
print(fields.a),
print(fields.b),
print

b1 = BitField1U()
b2 = BitField2U()

# Simply set fields.a = 1 twice, and notice how the raw_bytes changes.

b1.fields.a = 1
printBytes(b1.raw_bytes)
b1.fields.a = 1
printBytes(b1.raw_bytes)

b2.fields.a = 1
printBytes(b2.raw_bytes)
b2.fields.a = 1
printBytes(b2.raw_bytes)

--
components: ctypes
messages: 211241
nosy: Alan.Ning
priority: normal
severity: normal
status: open
title: Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux
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

[issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +amaury.forgeotdarc, belopolsky

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Larry Hastings]

Larry Hastings added the comment:

Why would we mangle the names of arguments in the first place?  What possible 
use case is there?

--

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Yury Selivanov added the comment:

> Why would we mangle the names of arguments in the first place?  What possible 
> use case is there?

The use case is multiple inheritance. You can define your methods with keyword 
and keyword-only params starting with '__', put in them some cached default for 
speeding up lookup time, and not being worried that someone can override the 
arg. The second reason is, I believe, is desire to be consistent with mangling 
methods and attributes.

Again, using mangling for function arguments is, probably, not the best 
practice, and that, combined with the fact, that people are just starting to 
play with annotations, explains why this bug was so long unnoticed.

But the semantics of arg names mangling is already there, implemented 
everywhere but __annotations__.

The attached patch is fairly simple, and really is just a bug fix. It would be 
great if we can get this in 3.4 (and even in 3.3 and 3.2).

--

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Benjamin Peterson]

Benjamin Peterson added the comment:

(see review on rietveld)

--

___
Python tracker 

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

[issue20628] csv.DictReader

[Sean Rodman]

Sean Rodman added the comment:

I am new to contributing to python, and I would like to take a shot a creating 
a patch for this.

--
nosy: +sean.rodman

___
Python tracker 

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

[issue8032] Add gdb7 hooks to make it easier to debug Python

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue20628] csv.DictReader

[Sean Rodman]

Sean Rodman added the comment:

I have created a patch for this documentation issue. Could you please review 
this for me and tell me what you think?

--
keywords: +patch
Added file: http://bugs.python.org/file34084/DictReader_DictWriter.patch

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Yury Selivanov]

Changes by Yury Selivanov :


Added file: http://bugs.python.org/file34085/issue_20625_02.patch

___
Python tracker 

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

[issue20601] tracing and tests that raise an exception in a SIGALRM handler

[Xavier de Gaye]

Xavier de Gaye added the comment:

Hum hum, and now with this last patch PyErr_CheckSignals is called for each 
traced line even when no signal is pending, which is worse than the previous 
one as far as performance is concerned.

--

___
Python tracker 

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

[issue20625] Argument names in __annotations__ are not mangled for functions defined inside class scope

[Benjamin Peterson]

Benjamin Peterson added the comment:

lgtm

--

___
Python tracker 

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

[issue19744] test_venv and installation fail if SSL/TLS is not available

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9f76adbac8b7 by Nick Coghlan in branch 'default':
Issue #19744: Handle missing SSL/TLS in ensurepip
http://hg.python.org/cpython/rev/9f76adbac8b7

--

___
Python tracker 

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

[issue19744] test_venv and installation fail if SSL/TLS is not available

[Nick Coghlan]

Nick Coghlan added the comment:

Thanks Ned - I fixed that test to only run if SSL/TLS is available, and added a 
new one to test that the command "succeeds" (with a warning printed to stderr) 
if SSL/TLS is missing.

Larry - over to you to decide whether or not to cherry pick this into the 
release clone. The remaining misbehaviour that was fixed in the last patch only 
affects custom source builds, so the beneficiaries would be people trying to 
build from the source tarball or release tag without SSL/TLS support.

--
assignee: ned.deily -> larry

___
Python tracker 

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

[issue20630] Add sorting helpers for collections containing None values

[Nick Coghlan]

New submission from Nick Coghlan:

Currently, it's a bit annoying to sort collections containing "None" values in 
Python 3. While the default behaviour isn't going to change, it would be good 
to offer standard "none_first" and "none_last" helps (inspired by the SQL NULL 
FIRST and NULL LAST ordering control).

Suggested home: functools (since that is where the total_ordering class 
decorator already lives), but collections would also be a reasonable choice (as 
this feature mostly relates to sorting containers)

The minimal option (suggested by Peter Otten):

def none_first(v):
return v is not None, v

def none_last(v):
return v is None, v

A more complex alternative would be to provide general purpose SortsFirst and 
SortsLast singletons:

@functools.total_ordering
class _AlwaysLesser:
def __eq__(self, other):
return isinstance(other, _AlwaysLesser):
def __lt__(self, other):
return not isinstance(other, _AlwaysLesser):

@functools.total_ordering
class _AlwaysGreater:
def __eq__(self, other):
return isinstance(other, _AlwaysGreater):
def __gt__(self, other):
return not isinstance(other, _AlwaysGreater):

SortsFirst = _AlwaysLesser()
SortsLast = _AlwaysGreater()

def none_first(v):
return SortsFirst if v is None else v
def none_last(v):
return SortsLast if v is None else v

The advantage of the latter more complex approach is that you can embed the 
SortsFirst and SortsLast values inside a tuple as part of a more complex key, 
whereas the simple solution only handles the case where the entire value is 
None.

(Inspired by Chris Withers's python-dev thread: 
https://mail.python.org/pipermail/python-dev/2014-February/132332.html)

--
messages: 211251
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add sorting helpers for collections containing None values
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue20631] python readline module crashing on NULL access

[Todd Fiala]

New submission from Todd Fiala:

Hi all,

In working on the LLVM/LLDB project, I've been hitting a bug in the
embedded interpreter that causes a NULL dereference in the Python
readline module. There is a call to the history_get() function with an
assumption that it returns a non-NULL value. This is not guaranteed to
be true of the history_get function, and causes the readline module to
crash when it hits this condition.

I'm attaching a patch to the Python 2.7.6 source code that addresses
this issue. It adds an explicit NULL test of the history_get() return
value before accessing it.

This issue was discovered in top of tree LLDB (LLVM.org debugger project).  See 
here for details:

http://llvm.org/bugs/show_bug.cgi?id=18841

--
files: python_2.7.6_module_readline_null.diff
keywords: patch
messages: 211252
nosy: tfiala
priority: normal
severity: normal
status: open
title: python readline module crashing on NULL access
versions: Python 2.7
Added file: 
http://bugs.python.org/file34086/python_2.7.6_module_readline_null.diff

___
Python tracker 

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

[issue20631] python readline module crashing on NULL access

[Todd Fiala]

Changes by Todd Fiala :


--
type:  -> crash

___
Python tracker 

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

[issue20632] Define a new __key__ protocol

[Nick Coghlan]

New submission from Nick Coghlan:

This is an idea that would require a PEP, just writing it down here as a 
permanent record in case someone else wants to run with it.

Currently, the *simplest* way to define a non-identity total ordering on an 
immutable object is to define __hash__, __eq__ and __lt__ appropriately, and 
then use functools.total_ordering to add the other comparison methods.

However, many such implementations follow a very similar pattern:

def __hash__(self):
return hash(self._calculate_key())
def __eq__(self, other):
if isinstance(other, __class__):
return self._calculate_key() == other._calculate_key()
return NotImplemented
def __lt__(self, other):
if isinstance(other, __class__):
return self._calculate_key() < other._calculate_key()
return NotImplemented

A "__key__" protocol as an inherent part of the type system could greatly 
simplify that:

def __key__(self):
return self._calculate_key()

The interpreter would then derive appropriate implementations for __hash__ and 
all the rich comparison methods based on that key calculation and install them 
when the type object was created.

If the type is mutable (and hence orderable but not hashable), then setting 
"__hash__ = None" would disable the implicit hashing support (just as it can 
already be used to explicitly disable hash inheritance).

(Inspired by Chris Withers's python-dev thread: 
https://mail.python.org/pipermail/python-dev/2014-February/132332.html)

--
components: Interpreter Core
messages: 211253
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Define a new __key__ protocol
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue20632] Define a new __key__ protocol

[Nick Coghlan]

Nick Coghlan added the comment:

Note: in conjuction with a class decorator (along the lines of 
functools.total_ordering), this idea is amenable to experimentation as a third 
party module. However, any such third party module shouldn't use a reserved 
name like __key__ - a public name like "calculate_key" would be more 
appropriate.

--

___
Python tracker 

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

[issue16361] HTTPS/TLS Problem in Python 3.3

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue18652] Add itertools.first_true (return first true item in iterable)

[Nick Coghlan]

Changes by Nick Coghlan :


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

[issue20622] Python3.3 venv pip fails to run if path contains spaces

[FeralBytes]

FeralBytes added the comment:

Wow that is a very compelling argument that I am hesitant to raise a counter 
point against. But I feel I would at least like to understand better. 
So why does this issue not affect the interpreter in the venv itself, only pip 
and easy_install, or other such tools with-in the venv? It seems to me that the 
activate script gets around this somehow for the interpreter, as it ran fine in 
the directory with a space in the name. Is it possible to apply the same fix 
action to at least pip since it will be included in venv once 3.4 is final, for 
a better user experience, or at least less user complaints?

In the meantime, I will fix my directory to use underscores instead of spaces. 
Thank you for your time.

--
resolution: invalid -> 
status: pending -> open

___
Python tracker 

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

[issue20631] python readline module crashing on NULL access

[koobs]

Changes by koobs :


--
nosy: +koobs

___
Python tracker 

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

[issue20544] Use specific asserts in operator tests

[Terry J. Reedy]

Terry J. Reedy added the comment:

Rietveld's within-line diff highlighting really helps reviewing this sort of 
thing. LGTM.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue20547] Use specific asserts in bigmem tests

[Terry J. Reedy]

Terry J. Reedy added the comment:

Patch2 looks correct, given that the replacement is the right thing to do. The 
assertTrue error message 'False is not true' is definitely not helpful. But I 
see Raymond's point. I think these patches should be discussed on pydev.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

>From what you have said here and on the other issue, reality has outgrown the 
>current customization methods. If Python, Tk, and Idle were to run on Windows 
>RT, I presume a different configuration would be needed than for normal 
>desktop.

Any new scheme used in the config files should allow the config dialog to still 
work sensible. If a current value displaying in the dialog come from a special 
section, then I think user changes should propagate back to that section and 
not the generic setting.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue4431] Distutils MSVC doesn't create manifest file

[Stephen Hansen]

Stephen Hansen added the comment:

FYI. Windows 8.1, Visual Studio 2010 SP1 Pro just installed, Python 3.3.3; a 
random extension did this as a 'test' in its setup.py:

compiler = distutils.ccompiler.new_compiler()
if not compiler.has_function('rand', includes = ['stdlib.h']):
...

And this failed. Further investigation turned brought me here, and adding 
/MANIFEST to my ld_args as this patch does fixed it.

--
nosy: +ixokai

___
Python tracker 

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

[issue16465] dict creation performance regression

[Peter Ingebretson]

Changes by Peter Ingebretson :


--
nosy: +pingebretson

___
Python tracker 

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

[issue20547] Use specific asserts in bigmem tests

[Ezio Melotti]

Ezio Melotti added the comment:

> For end users of Python, they don't have to worry much about this, but
> we as developers of core types really care whether self.assertLessThan(x, y)
> really does x < y, or x.__lt__(y), or "not y >= x", etc.

FWIW the assert methods should guarantee that the corresponding operator is 
used (e.g. < for assertLess), and I think this is already the case.

> After more careful reviewing this patch, I have found than some tests
> shouldn't be changed, because they produce utterly large error 
> message in case of a failure (even if resulted message is truncated, 
> as in case of assertEqual, large intermediate strings are created).

Some of these cases are already fixed, for others there are still open issues.  
If you find cases that are not tracked you should report them.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue11588] Add "necessarily inclusive" groups to argparse

[paul j3]

paul j3 added the comment:

Regarding a usage line like:

(-o FILE | (-O DIR & (-p PATTERN | -s SUFFIX))

The simplest option is to just a custom written 'usage' parameter.

With the existing HelpFormatter, a nested grouping like this is next to 
impossible.  It formats the arguments (e.g.'-O DIR'), interleaves the group 
symbols, and then trims out the excess spaces and symbols.

http://bugs.python.org/issue10984  is a request to allow overlapping 
mutually_exclusive_groups.  It loops on the groups, formatting each.  It would 
be easier with that to format several different types of groups, and to handle 
nested ones.

What would it take to convert a usage string like that into a logical 
expression that tests for the proper occurrence (or non-occurrence) of the 
various arguments.  It might, for example be converted to

exc(file, inc(dir, exc(pattern, suffix)))

where 'exc' and 'inc' are exclusive and inclusive tests, and 'file','dir' etc 
are booleans.  And what would be the error message(s) if this expression fails?

I can imagine a factory function that would take usage line (or other 
expression of groupings), and produce a function that would implement a 
cross_test (as outlined in my previous post).  It would be, in effect, a 
micro-language compiler.

--

___
Python tracker 

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