[issue15467] Updating __sizeof__ tests

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: http://bugs.python.org/file26543/sizeof_tests-2.7.patch

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Nick Coghlan]

Nick Coghlan added the comment:

I've switched back to being -1 on the PYTHONRUNFIRST idea. There are no ACLs 
for environment variables, so the security implications scare me too much for 
me to support the feature.

The simple -C option doesn't have that problem, though, and could be used as 
infrastructure in a process infrastructure framework to provide enhanced 
configuration of Python subprocesses.

--

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Changes by Nick Coghlan :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

Added patch with test cases for the situations Amaury picked up, as well 
another I noticed (when the from clause refers to a module that fails)

--
Added file: http://bugs.python.org/file26564/issue15425_test_cases.diff

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

I actually did start refactoring a lot of this when I was working on the 
pkgutil changes, but stopped because that patch was already hairy enough.

Maybe I should have kept going...

--

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

I think tuning the "what frames to hide" heuristic is a better bet - I remember 
know that the real reason I stopped messing with which exceptions were thrown 
was that I ended up confusing pkgutil.

--

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

Fixed test case patch - previous one included a comment from when my test was 
buggy.

--
Added file: http://bugs.python.org/file26565/issue15425_test_cases.diff

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Changes by Nick Coghlan :


Removed file: http://bugs.python.org/file26564/issue15425_test_cases.diff

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

I like the concept of "exit points" that Antoine introduced with a special 
method name. Maybe we coule generalize this and have a 
"execute_and_hide_frames(func, *args, **kwargs)" that is recognized by the 
caller in import.c.

--

___
Python tracker 

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

[issue12834] memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

[Stefan Krah]

Stefan Krah added the comment:

Christian's posts and my initial report were about memoryview.tobytes(). It's
good that you changed the title: memoryview.tobytes() is more meaningful than
the slightly obscure PyBuffer_ToContiguous().


BTW, I'm sure that PyBuffer_FromContiguous() and PyObject_CopyData() have the
same problem, but they aren't used in the Python source tree and they are
undocumented.

--

___
Python tracker 

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

[issue15477] test_cmath failures on OS X 10.8

[Mark Dickinson]

Mark Dickinson added the comment:

> These types of run-time tests based on configure-time tests are problematic
> for binary installations of Python, like the OS X installers.

Understood.  I'm wondering how to fix this for Python, given that we're 
unlikely to see an OS-level fix for a while.  There's an easy workaround, 
namely to add an "if (x == 0.0) return x;" before any use of the system log1p;  
the issue is how and when to apply this workaround.

One option is always to apply the workaround, but this feels to me as though 
it's unnecessarily penalising those OSs that get it right;  maybe just always 
apply the workaround on OS X?

--

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

OK, to investigate the failures a bit further, I turned off the traceback 
suppression altogether by sticking an immediate return at the start of 
remove_importlib_frames. For the three failing tests, this is what I got when 
adding a traceback.print_tb call:

test_broken_from (test.test_import.ImportTracebackTests) ...   File 
"/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 890, in 
test_broken_from
from _parent_foo import bar
  File "", line 1572, in _handle_fromlist
  File "", line 1524, in _find_and_load
  File "", line 1491, in _find_and_load_unlocked
  File "", line 571, in _check_name_wrapper
  File "", line 1002, in load_module
  File "", line 983, in load_module
  File "", line 547, in module_for_loader_wrapper
  File "", line 853, in _load_module
  File "", line 860, in _exec_module
  File "./_parent_foo/bar.py", line 1, in 
1/0
FAIL
test_broken_parent (test.test_import.ImportTracebackTests) ...   File 
"/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 902, in 
test_broken_parent
import _parent_foo.bar
  File "", line 1524, in _find_and_load
  File "", line 1475, in _find_and_load_unlocked
  File "", line 1524, in _find_and_load
  File "", line 1491, in _find_and_load_unlocked
  File "", line 571, in _check_name_wrapper
  File "", line 1002, in load_module
  File "", line 983, in load_module
  File "", line 547, in module_for_loader_wrapper
  File "", line 853, in _load_module
  File "", line 860, in _exec_module
  File "./_parent_foo/__init__.py", line 1, in 
1/0
FAIL
test_syntax_error (test.test_import.ImportTracebackTests) ...   File 
"/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 851, in 
test_syntax_error
import foo
  File "", line 1524, in _find_and_load
  File "", line 1491, in _find_and_load_unlocked
  File "", line 571, in _check_name_wrapper
  File "", line 1002, in load_module
  File "", line 983, in load_module
  File "", line 547, in module_for_loader_wrapper
  File "", line 838, in _load_module
  File "", line 960, in get_code
FAIL

And here's what I get with my patched version enabled (which also ignores 
chunks ending with get_code when the failure is a syntax error):

test_broken_from (test.test_import.ImportTracebackTests) ...   File 
"/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 890, in 
test_broken_from
from _parent_foo import bar
  File "", line 1572, in _handle_fromlist
  File "./_parent_foo/bar.py", line 1, in 
1/0
FAIL
test_broken_parent (test.test_import.ImportTracebackTests) ...   File 
"/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 902, in 
test_broken_parent
import _parent_foo.bar
  File "", line 1524, in _find_and_load
  File "", line 1475, in _find_and_load_unlocked
  File "./_parent_foo/__init__.py", line 1, in 
1/0
FAIL
test_syntax_error (test.test_import.ImportTracebackTests) ...   File 
"/home/ncoghlan/devel/py3k/Lib/test/test_import.py", line 851, in 
test_syntax_error
import foo
FAIL

--

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

I realised that it is my test that was wrong in the syntax error case. Attached 
patch includes the test cases, and the fix for that case.

The weird thing that still requires an explanation is why the chunks in the 
first two cases are only being partially stripped. Those blocks end with 
_exec_module, yet a couple of frames are being left in the traceback.

Current patch includes my debugging output from those tests.

--
Added file: http://bugs.python.org/file26566/issue15425_handle_syntax_error.diff

___
Python tracker 

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

[issue15268] curses configure checks fail if only /usr/include/ncursesw/curses.h is installed

[Roumen Petrov]

Roumen Petrov added the comment:

Matthias, do not use hack if cross-build

--
nosy: +rpetrov
Added file: 
http://bugs.python.org/file26567/4-CROSS-avoid-ncursesw-include-path-hack.patch

___
Python tracker 

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

[issue15483] CROSS: initialise include and library paths in setup.py

[Roumen Petrov]

New submission from Roumen Petrov:

In setup.py  inc_dirs and lib_dirs are not initialized in cross-build case.

--
files: 1-CROSS-initialise-include-and-library-paths.patch
keywords: patch
messages: 166733
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: initialise include and library paths in setup.py
Added file: 
http://bugs.python.org/file26568/1-CROSS-initialise-include-and-library-paths.patch

___
Python tracker 

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

[issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig

[Roumen Petrov]

New submission from Roumen Petrov:

Same as sysconfig but now in distutils  _PYTHON_PROJECT_BASE has to be used in 
cross-build environment.

--
components: Build
files: 2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch
keywords: patch
messages: 166734
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig
versions: Python 3.3
Added file: 
http://bugs.python.org/file26569/2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

Ah, it turns out the three problem children are those which accept an "import_" 
callback, which is set to builtins.__import__ when accessed via the import 
statement. This means we end up making a *recursive* call to 
PyImport_ImportModuleLevelObject, which calls remove_importlib_frames. The 
inner section of the trace gets stripped away, thus the "_exec_module" frame is 
already gone by the time the outer frames get added to the traceback.

For the moment, I'm just going to adopt the blunt instrument approach and 
special case those three functions (including them in the "always strip" 
category). If anyone else comes up with a more elegant mechanism to deal with 
the recursion, we can switch to it later.

--

___
Python tracker 

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

[issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig

[Roumen Petrov]

Roumen Petrov added the comment:

Also _PYTHON_PROJECT_BASE should be initialized to build directory by configure 
- low priority as other issue prevent python to be build and tested smoothly 
outside source tree.

--
Added file: 
http://bugs.python.org/file26570/2-CROSS-set-_PYTHON_PROJECT_BASE-to-current-build-dir.patch

___
Python tracker 

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

[issue15485] CROSS: append gcc library search paths

[Roumen Petrov]

New submission from Roumen Petrov:

Currently if cross-build add_gcc_paths use append_dir_to_list but later prepend 
library paths. As result  gcc is multilib 64-bit libraries will be found first 
before 32-bit one.

--
components: Cross-Build
files: 3-CROSS-append-gcc-library-search-paths.patch
keywords: patch
messages: 166737
nosy: rpetrov
priority: normal
severity: normal
status: open
title: CROSS: append gcc library search paths
versions: Python 3.3
Added file: 
http://bugs.python.org/file26571/3-CROSS-append-gcc-library-search-paths.patch

___
Python tracker 

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

[issue15482] __import__() change between 3.2 and 3.3

[Martin v . Löwis]

Martin v. Löwis added the comment:

So should 3.2 be changed to adjust the default value to match the documentation?

--
nosy: +loewis

___
Python tracker 

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

[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

[Nick Coghlan]

Changes by Nick Coghlan :


--
title: memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for 
non-contiguous arrays -> memoryview.to_bytes() and PyBuffer_ToContiguous() 
incorrect for non-contiguous arrays

___
Python tracker 

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

[issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig

[Roumen Petrov]

Changes by Roumen Petrov :


--
components: +Cross-Build -Build
type:  -> compile error

___
Python tracker 

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

[issue15483] CROSS: initialise include and library paths in setup.py

[Roumen Petrov]

Changes by Roumen Petrov :


--
components: +Cross-Build
versions: +Python 3.3

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

I'll at least introduce a "_recursive_import" exit point to simplify handling 
of those three cases. For those, if there isn't another importlib frame on the 
stack below them, odds are pretty good that it has been stripped already.

--

___
Python tracker 

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

[issue3754] cross-compilation support for python build

[Roumen Petrov]

Roumen Petrov added the comment:

I hope that  following separate issues will address remaining part of this 
patch:

required:
- 15483: initialise include and library paths in setup.py
- 15484: use _PYTHON_PROJECT_BASE in distutils sysconfig
- TODO: typo in in configure.in - use ac_cv_pthread instead ac_cv_thread
- 15268: skip "curses configure checks fail if only 
/usr/include/ncursesw/curses.h is installed"

optional:
- 15298: _sysconfigdata is generated in srcdir, not builddir
- 14598: _cursesmodule.c fails with ncurses-5.9 on Linux reported first as 
14438 - _cursesmodule build fails on cygwin
and all other that allow python to be build smoothly outside source directory

--
components: +Cross-Build -Build, Distutils2

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with packaging

[Roumen Petrov]

Roumen Petrov added the comment:

May be patch 20120729 cannot be applied as my source tree contain a number of 
patches related to cross build - see msg166740  from issue 3754 .

--
Added file: http://bugs.python.org/file26572/python-py3k-20120729-MINGW.patch

___
Python tracker 
<http://bugs.python.org/issue3871>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

I think the implementation I just checked in is close to being as simple as we 
can get:

Blocks ending in _exec_module and _recursive_import are trimmed unconditionally
For SyntaxError, it also trims blocks ending in get_code
For ImportError, it trims everything involving importlib

Because the latter two are conditional on the kind of exception thrown, it's 
only the first two that could be unified and I think keeping the two distinct 
checks is actually clearer in that case.

--

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Roundup Robot]

Roundup Robot added the comment:

New changeset 75a30a478dc7 by Nick Coghlan in branch 'default':
Close #15425: Eliminate more importlib related traceback noise
http://hg.python.org/cpython/rev/75a30a478dc7

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

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

On second thought, I realised having a general purpose "hide this" hook means 
that any future unconditional cases can easily be hidden just by changing from 
the normal call to a stripped call. I'll implement that now.

--

___
Python tracker 

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

[issue15486] Standardise the mechanisms for stripping importlib frames

[Nick Coghlan]

New submission from Nick Coghlan:

Thanks to issue #15425, the number of special cases in the importlib frame 
stripping is growing. This patch tweaks the frame stripping mechanism to make 
it easy to selectively strip frames in importlib._bootstrap by creating a 
_call_with_frames_removed helper function.

The rules in remove_importlib_frames then change to remove any sequence of 
importlib frames which ends with that helper and all importlib frames in the 
ImportError case.

--
messages: 166745
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Standardise the mechanisms for stripping importlib frames

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

Seeing as the blocker is dealt with for beta2, see #15486 for the proposed 
refactoring.

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I've switched back to being -1 on the PYTHONRUNFIRST idea. There are
> no ACLs for environment variables, so the security implications scare
> me too much for me to support the feature.

I'm quite sure PYTHONHOME and PYTHONPATH already allow you to mess quite
freely. That's why we have the -E flag.

I'm -0.5 myself, though, for the reason that it complicates the startup
process a little bit more, without looking very compelling. It smells
disturbingly like LD_PRELOAD to me.

> The simple -C option doesn't have that problem, though, and could be
> used as infrastructure in a process infrastructure framework to
> provide enhanced configuration of Python subprocesses.

What do you mean exactly?

--

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Nick Coghlan]

Nick Coghlan added the comment:

In trying to find a new case that wasn't already covered by the test suite, I 
found an error which I'm not even sure should be an error. Doesn't 3.2 suppress 
failures that occur when attempting to implicitly cache the .pyc?

Anyway, given the rest of the patch, trimming this traceback will be easy if we 
decide that's the right thing to do.

--
components: +Interpreter Core, Library (Lib)
keywords: +patch
nosy: +amaury.forgeotdarc, brett.cannon, eric.snow, georg.brandl
priority: normal -> release blocker
stage:  -> patch review
title: Standardise the mechanisms for stripping importlib frames -> 
Standardised mechanism for stripping importlib frames from tracebacks
type:  -> behavior
versions: +Python 3.3
Added file: 
http://bugs.python.org/file26573/issue15486_simplify_importlib_frame_removal.diff

___
Python tracker 

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

[issue15482] __import__() change between 3.2 and 3.3

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue15484] CROSS: use _PYTHON_PROJECT_BASE in distutils sysconfig

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue15295] Import machinery documentation

[Nick Coghlan]

Nick Coghlan added the comment:

Updated the statement docs to accurately describe the from X import Y case.

I also noted that unlike the statement form, importlib.import_module ignores 
module level __import__ overrides.

--

___
Python tracker 

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

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

[Richard Oudkerk]

Richard Oudkerk added the comment:

> Richard, can the issue be closed?

I guess so (although the change could arguably be back ported).

Pickling of Exception classes is still somewhat dodgy because an example like

class Error(Exception):
def __init__(self, x):
Exception.__init__(self)
self.x = x

is still not picklable.

Any further improvements can be discussed in a separate issue, so I will close.

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

___
Python tracker 

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

[issue12288] Python 2.7.1 tkSimpleDialog initialvalue

[Andrew Svetlov]

Andrew Svetlov added the comment:

Add patch for py3k

--
assignee:  -> asvetlov
keywords: +patch
nosy: +asvetlov
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26574/issue12288.diff

___
Python tracker 

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

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[issue12288] tkinter SimpleDialog initialvalue

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
title: Python 2.7.1 tkSimpleDialog initialvalue -> tkinter SimpleDialog 
initialvalue

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Nick Coghlan]

Nick Coghlan added the comment:

Nothing too complicated - just noting that a test suite like ours that launches 
Python subprocesses to test process global state handling could fairly easily 
arrange to pass appropriate -C options to trigger things like recording 
coverage data or profiling options.

I'll also note that if you put a "preinit.py" on sys.path (e.g. in the current 
directory if using -m for invocation), you could easily do "-C 'import 
preinit'" to do arbitrarily complex custom setups, including preconfiguring 
your test framework.

A lot of my thoughts on this come out of looking into migrating the various 
stdlib modules like trace, pdb and profile over to supporting everything that 
runpy (and hence the main executable) supports, and a lot of the complexity 
lies in the mechanics of how to daisy chain the two "__main__" modules 
together. Running a bit of extra code in __main__ as supplied on the command 
line before kicking off the full import process helps avoid a lot of pain.

--

___
Python tracker 

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

[issue15364] sysconfig confused by relative paths

[Richard Oudkerk]

Richard Oudkerk added the comment:

> One example is 'srcdir': this value is only useful in the build tree and 
> there currently is no clean way to signal that you are retrieving a 
> value that is not useful.

In the particular case of 'srcdir', sysconfig.is_python_build() tells you 
whether the value is useful.

Concerns about sysconfig often returning values which are meaningless for the 
current configuration can be discussed in another issue.

Unless there are objections I will close.

--
resolution:  -> fixed
stage: commit review -> committed/rejected

___
Python tracker 

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

[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

[Christian Heimes]

Christian Heimes added the comment:

Thanks Stefan and Nick!

I tried to find the off-by-one bug myself but gave up quickly. Stefan's rewrite 
is a better approach.

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Ned Batchelder]

Ned Batchelder added the comment:

> I'm -0.5 myself, though, for the reason that it complicates the startup
> process a little bit more, without looking very compelling. It smells
> disturbingly like LD_PRELOAD to me.

Antoine, do you have a suggestion for how to solve the coverage.py problem?  To 
re-iterate: imagine you have a large test suite, and it spawns python processes 
during the tests.  Mercurial, for example, is like this.  You want to measure 
the coverage of your test suite.  This means not do you have to invoke the main 
suite with "python coverage.py run tests.py" instead of "python tests.py", but 
all the subprocess invocations need to invoke coverage.py as well.

We are looking for ways to make this as transparent as possible to the tests 
themselves, just as coverage measurement is now for test suites that don't 
spawn python subprocesses.

http://nedbatchelder.com/code/coverage/subprocess.html describes the two 
current hacks people can use to invoke coverage on subprocesses.  I was hoping 
for a cleaner more natural solution.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for C implementation of 
buffered I/O files: io.BufferedReader, io.BufferedWriter and io.BufferedRandom.

--
components: IO, Library (Lib)
messages: 166756
nosy: benjamin.peterson, hynek, pitrou, storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for buffered I/O
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

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

[issue15425] Another strange Tracebacks with importlib

[Chris Jerdonek]

Chris Jerdonek added the comment:

The unit tests added here are another candidate for the refactoring in issue 
15403 ("Refactor package creation support code into a common location").  I'll 
note this in that issue.

--
nosy: +cjerdonek

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Hynek Schlawack]

Hynek Schlawack added the comment:

There is no patch.

--
stage:  -> needs patch

___
Python tracker 

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

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

[Chris Jerdonek]

Chris Jerdonek added the comment:

Lib/test/test_import.py also contains test code that would benefit from this 
(see for example issue 15425).  (Though not all files need to be refactored in 
a single issue.)

--

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Chris Jerdonek]

Chris Jerdonek added the comment:

The test cases uploaded to issue 7559 ("TestLoader.loadTestsFromName swallows 
import errors") a while back contain a number of distinct cases (four, I think) 
in which an import error can be raised.  IIRC, these include a couple recursive 
scenarios (cyclical import from within __init__.py, etc).

Those test cases were designed specifically to cover different scenarios in 
which unittest's loader was swallowing import errors.  Might be worth taking a 
look.

--
nosy: +cjerdonek

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
nosy: +cjerdonek

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
keywords: +patch
Added file: http://bugs.python.org/file26575/bufferedio_sizeof.patch

___
Python tracker 

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

[issue15451] PATH is not honored in subprocess.Popen in win32

[Richard Oudkerk]

Richard Oudkerk added the comment:

> But I observe that the same script(with proper modification of file names) 
> works very well under Linux. After I dive into the source code, I found 
> Python use execvpe to invoke the child process which _will_ use the PATH 
> variable to search the executable.

The posix execvpe function does not use PATH from the passed environment, but 
(surprisingly to me) os.execvpe does.  subprocess in Python 3 no longer uses 
os.execvpe, but still goes out of its way to use envp['PATH'] on posix systems 
when searching for the executable.

So I think you have a legitimate complaint of inconsistency.

However, I don't think your suggested fix is a good idea since it (temporarily) 
changes the environment of the current process which might be problematic in a 
threaded program.

I am sure that Python 2.7 will not be patched to address this, but you might 
want to make a feature request for Python 3.4.

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Chris Jerdonek]

Chris Jerdonek added the comment:

Ned, two questions: in the scenario you just described, is it a requirement 
that your test suite's code need not be modified (even minimally) to support 
coverage of subprocesses?

And can the solution assume that the test suite is spawning the Python 
processes in certain standard ways, or must it address all possible ways (even 
convoluted ones)?  If the former, what are the standard ways?  I am referring 
to things like the path to the Python interpreter invoked and how that is 
obtained, whether the subprocess module is always used, etc.

These questions are meant to help pin down the scope of what needs to be 
satisfied.

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Antoine Pitrou]

Antoine Pitrou added the comment:

> > I'm -0.5 myself, though, for the reason that it complicates the startup
> > process a little bit more, without looking very compelling. It smells
> > disturbingly like LD_PRELOAD to me.
> 
> Antoine, do you have a suggestion for how to solve the coverage.py
> problem?  To re-iterate: imagine you have a large test suite, and it
> spawns python processes during the tests.  Mercurial, for example, is
> like this.  You want to measure the coverage of your test suite.  This
> means not do you have to invoke the main suite with "python
> coverage.py run tests.py" instead of "python tests.py", but all the
> subprocess invocations need to invoke coverage.py as well.

Ok, sorry then, I retract what I said. I agree the use case is
legitimate.

--

___
Python tracker 

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

[issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays

[Stefan Krah]

Stefan Krah added the comment:

Nick, are you talking about a complete backport or just about pulling
in all functions needed by PyBuffer_ToContiguous()?

--

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Ned Batchelder]

Ned Batchelder added the comment:

Chris:

The real problem is that it isn't the "test suite" that spawns the processes, 
the tests invoke product code, and the product code spawns Python.  So 
modifying the Python-spawning really means modifying the product code to do 
something different under coverage, which most developers (rightfully) won't 
want to do.

My preference is not to assume a particular style of spawning subprocesses, 
since coverage.py tried quite hard to be applicable to any Python project.

--

___
Python tracker 

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

[issue15467] Updating __sizeof__ tests

[Roundup Robot]

Roundup Robot added the comment:

New changeset efade142ef01 by Martin v. Löwis in branch '3.2':
Issue #15467: Move helpers for __sizeof__ tests into test_support.
http://hg.python.org/cpython/rev/efade142ef01

New changeset d43ff8eb4cb3 by Martin v. Löwis in branch 'default':
Issue #15467: Merge 3.2
http://hg.python.org/cpython/rev/d43ff8eb4cb3

--
nosy: +python-dev

___
Python tracker 

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

[issue15467] Updating __sizeof__ tests

[Roundup Robot]

Roundup Robot added the comment:

New changeset fa95b04e67fd by Martin v. Löwis in branch '2.7':
Issue #15467: Move helpers for __sizeof__ tests into test_support.
http://hg.python.org/cpython/rev/fa95b04e67fd

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Antoine Pitrou]

Antoine Pitrou added the comment:

Instead of putting this in MiscIOTest, you could use the relevant 
class-specific test cases.

--

___
Python tracker 

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

[issue15467] Updating __sizeof__ tests

[Martin v . Löwis]

Martin v. Löwis added the comment:

I wasn't aware that test_support isn't public API. The patches are fine then; 
committed.

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

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Antoine Pitrou]

Antoine Pitrou added the comment:

This is an elegant solution, +1 from me.

--
nosy: +pitrou

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

Please let's not have something called test.supportlib in addition to 
test.support. If test.support grows too large we can turn it into a package.

--
nosy: +pitrou

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Chris Jerdonek]

Chris Jerdonek added the comment:

I understand that.  Sorry, I meant to say "code under test."

If you make no assumptions about spawning subprocesses, does this mean, for 
example, that the solution must satisfy the case of subprocesses invoking a 
different version of Python, or invoking the same version of Python in a 
different virtual environment?

--

___
Python tracker 

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

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

[Chris Jerdonek]

Chris Jerdonek added the comment:

I feel like it is already too large (it is over 1750 lines), and I did not want 
to create a third sibling test support module (there is also 
test/script_helper.py that overlaps with test.support).  Do you think that the 
community would be open to refactoring test.support into a package for Python 
3.3?  This was meant to assist in increasing test coverage for Python 3.3 bugs.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I feel like it is already too large (it is over 1750 lines), and I did
> not want to create a third sibling test support module (there is also
> test/script_helper.py that overlaps with test.support).  Do you think
> that the community would be open to refactoring test.support into a
> package for Python 3.3?  This was meant to assist in increasing test
> coverage for Python 3.3 bugs.

That's too late for 3.3, IMO. Whether or not test.support is too large
is a matter of taste (we have larger files in the stdlib; what makes
test.support annoying to work with is that it's a hodge-podge of utility
functions with little care for consistency). Unless we can clearly
separate it in thematic areas, making it a package would only make
finding stuff more difficult.

--

___
Python tracker 

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

[issue633930] Nested class __name__

[Cheer Xiao]

Cheer Xiao added the comment:

There is a bigger problem:

>>> class C:
... class D:
... pass
...
>>> repr(C)
""
>>> repr(C.D)
""

Default repr on nested classes produce specious results.

The problem become pratical when you have two nested classes C1.D and C2.D in 
module m, which end up being both "m.D" in exception traceback. 

Classes nested in function are likely to contain some information from the 
function arguments and are thus different on each function call, making it 
impossible to have a general way to name them. Thus I propose embedding the 
resulting class's `id` in __name__, like what i'm doing manually in a hulking 
way:

>>> def factory(foo):
... class C(object):
... bar = foo
... func_name = 'factory'
... C.__name__ = '%s generated classobj at 0x%x' % (func_name, id(C))
... return C
...
>>> factory(0)

>>> factory(0)


Please consider reopening this issue.

--
nosy: +xiaq

___
Python tracker 

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

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

[Chris Jerdonek]

Chris Jerdonek added the comment:

At this point, would you advise me to add even more to the existing hodge 
podge, or to create a third sibling test support module?  My patch adds closely 
related test support functionality.

Incidentally, this discussion relates to the point I was getting at in the 
python-dev thread in the past couple days about how restrictions on refactoring 
test support code for maintenance releases can affect the quality of our test 
code.  I am still struggling with how to approach that.

--

___
Python tracker 

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

[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename

[Atsuo Ishimoto]

Atsuo Ishimoto added the comment:

+1 for keeping the file name unchanged. This solution is not very 
compatible with prior versions, but simple and least-surprise.

I prefer other platforms than Windows to use same method to build OSError.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

I don't mind refactoring test support routines in maintenance release. I
said it was too late for 3.3 because the beta period is closing; but it
could be fine for 3.3.1 ;)

As for the way forward, I see three possibilites:
1) put everying in test.support, as a single module (that includes
folding script_helper into it)
2) make test.support a package of thematic modules
3) refactor test.support into a variety of independent modules
(script_helper, import_helper, socket_helper, etc.); a small
test.support providing fundamental features such as TESTFN could remain

My personal preference would be for 1) or 3). But whatever we choose, we
should do it consistently. Having a large test.support + a supportlib
package + some independent helpers is not a good idea.

--

___
Python tracker 

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

[issue15467] Updating __sizeof__ tests

[Meador Inge]

Changes by Meador Inge :


--
stage:  -> committed/rejected
type:  -> behavior

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Ned Batchelder]

Ned Batchelder added the comment:

Chris, I'm not sure how to answer your questions.  The more powerful and 
flexible, the better.  There is no "must" here.  I'm looking for a way to avoid 
the hacks coverage.py has used in the past to measure coverage in subprocesses. 
 A language feature that allowed me to externally configure the interpreter to 
run some of my code first would allow me to do that.

--

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Patches updated on Meador's remarks. Tests updated to use new test.support 
helpers.

--
Added file: http://bugs.python.org/file26576/itertools_sizeof-3.3-2.patch

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26577/itertools_sizeof-3.2-2.patch

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file26578/itertools_sizeof-2.7-2.patch

___
Python tracker 

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

[issue15475] Correct __sizeof__ support for itertools

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Sorry, on Martin's remarks.

--

___
Python tracker 

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

[issue15436] __sizeof__ is not documented

[Martin v . Löwis]

Martin v. Löwis added the comment:

rhettinger: users frequently need sys.getsizeof. See, for example,

http://stackoverflow.com/questions/1331471/in-memory-size-of-python-stucture
http://stackoverflow.com/questions/449560/how-do-i-determine-the-size-of-an-object-in-python
http://stackoverflow.com/questions/2117255/python-deep-getsizeof-list-with-contents
http://stackoverflow.com/questions/11301295/measure-object-size-accurately-in-python-sys-getsizeof-not-functioning
[and so on]

In what cases, do you think, it generates meaningless results? I find the 
results for the shared-keys dictionary quite meaningful and natural.

sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not just an 
implementation detail of sys.getsizeof, just as __len__ is not an 
implementation detail of len(). Authors of extension types are supposed to 
implement it if object.__sizeof__ is incorrect.

--
nosy: +loewis

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Meador Inge]

Meador Inge added the comment:

Serhiy, I didn't analyze it too in depth, but why aren't the test cases using 
the __sizeof__ support work you implemented for issue15467?  I think these 
tests should be using the more exact method like your other '__sizeof__' 
patches.

--
nosy: +meador.inge
stage: needs patch -> patch review

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Instead of putting this in MiscIOTest, you could use the relevant
> class-specific test cases.

Thank you, good advice. Here is updated patch.

--
Added file: http://bugs.python.org/file26579/bufferedio_sizeof-2.patch

___
Python tracker 

___diff -r d43ff8eb4cb3 Lib/test/test_io.py
--- a/Lib/test/test_io.py   Sun Jul 29 16:38:45 2012 +0200
+++ b/Lib/test/test_io.py   Sun Jul 29 19:30:56 2012 +0300
@@ -802,6 +802,20 @@
 buf.raw = x
 
 
+class SizeofTest:
+
+@support.cpython_only
+def test_sizeof(self):
+bufsize1 = 4096
+bufsize2 = 8192
+rawio = self.MockRawIO()
+bufio = self.tp(rawio, buffer_size=bufsize1)
+size = sys.getsizeof(bufio) - bufsize1
+rawio = self.MockRawIO()
+bufio = self.tp(rawio, buffer_size=bufsize2)
+self.assertEqual(sys.getsizeof(bufio), size + bufsize2)
+
+
 class BufferedReaderTest(unittest.TestCase, CommonBufferedTests):
 read_mode = "rb"
 
@@ -999,7 +1013,7 @@
  "failed for {}: {} != 0".format(n, 
rawio._extraneous_reads))
 
 
-class CBufferedReaderTest(BufferedReaderTest):
+class CBufferedReaderTest(BufferedReaderTest, SizeofTest):
 tp = io.BufferedReader
 
 def test_constructor(self):
@@ -1260,7 +1274,7 @@
 self.tp(self.MockRawIO(), 8, 12)
 
 
-class CBufferedWriterTest(BufferedWriterTest):
+class CBufferedWriterTest(BufferedWriterTest, SizeofTest):
 tp = io.BufferedWriter
 
 def test_constructor(self):
@@ -1650,7 +1664,7 @@
 # You can't construct a BufferedRandom over a non-seekable stream.
 test_unseekable = None
 
-class CBufferedRandomTest(BufferedRandomTest):
+class CBufferedRandomTest(BufferedRandomTest, SizeofTest):
 tp = io.BufferedRandom
 
 def test_constructor(self):
diff -r d43ff8eb4cb3 Modules/_io/bufferedio.c
--- a/Modules/_io/bufferedio.c  Sun Jul 29 16:38:45 2012 +0200
+++ b/Modules/_io/bufferedio.c  Sun Jul 29 19:30:56 2012 +0300
@@ -398,6 +398,17 @@
 Py_TYPE(self)->tp_free((PyObject *)self);
 }
 
+static PyObject *
+buffered_sizeof(buffered *self, void *unused)
+{
+Py_ssize_t res;
+
+res = sizeof(buffered);
+if (self->buffer)
+res += self->buffer_size;
+return PyLong_FromSsize_t(res);
+}
+
 static int
 buffered_traverse(buffered *self, visitproc visit, void *arg)
 {
@@ -1699,6 +1710,7 @@
 {"seek", (PyCFunction)buffered_seek, METH_VARARGS},
 {"tell", (PyCFunction)buffered_tell, METH_NOARGS},
 {"truncate", (PyCFunction)buffered_truncate, METH_VARARGS},
+{"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
 {NULL, NULL}
 };
 
@@ -2079,6 +2091,7 @@
 {"flush", (PyCFunction)buffered_flush, METH_NOARGS},
 {"seek", (PyCFunction)buffered_seek, METH_VARARGS},
 {"tell", (PyCFunction)buffered_tell, METH_NOARGS},
+{"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
 {NULL, NULL}
 };
 
@@ -2470,6 +2483,7 @@
 {"readline", (PyCFunction)buffered_readline, METH_VARARGS},
 {"peek", (PyCFunction)buffered_peek, METH_VARARGS},
 {"write", (PyCFunction)bufferedwriter_write, METH_VARARGS},
+{"__sizeof__", (PyCFunction)buffered_sizeof, METH_NOARGS},
 {NULL, NULL}
 };
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

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

[issue14803] Add feature to allow code execution prior to __main__ invocation

[Chris Jerdonek]

Chris Jerdonek added the comment:

Okay, then in the interest of understanding why various alternatives fail, I'll 
just throw out the suggestion or question that I had in mind because I don't 
see it mentioned above or on the web page.

Why wouldn't it work to define an alias or script that invokes the desired 
"python -m ...", and then when you call your test suite (using a potentially 
different "-m ..."), you set sys.executable to that script so that subprocesses 
in your code under test will invoke it?  (coverage.py could do all of this 
under the hood so that the user need not be aware of it.)  Or would this work 
just fine, but that it's an example of the kind of hack that you're trying to 
avoid?

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Serhiy, I didn't analyze it too in depth, but why aren't the test cases
> using the __sizeof__ support work you implemented for issue15467?  I think
> these tests should be using the more exact method like your other
> '__sizeof__' patches.

Because struct has not codes for Py_off_t and PyThread_type_lock.

--

___
Python tracker 

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

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

[Chris Jerdonek]

Chris Jerdonek added the comment:

Thanks for your thoughts.  For the purposes of this patch, I will change to 
putting the new support functionality in test.support.  Going forward, if we 
could do some of the refactoring for 3.3.1, that would be great. :)

I worry that the third option may make things worse because it would become 
less obvious where all of the different test support functionality is located.

Are you opposed to (2), or is it simply less favorable?  The transition to (2) 
could be a gradual one beginning with two or even one module inside the package.

--

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Are you opposed to (2), or is it simply less favorable?

Less favorable, because it produces longer import strings
("test.support.some_helper" instead of "test.some_helper").

--

___
Python tracker 

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

[issue15436] __sizeof__ is not documented

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not
> just an implementation detail of sys.getsizeof, just as __len__ is not an
> implementation detail of len(). Authors of extension types are supposed to
> implement it if object.__sizeof__ is incorrect.

I think there is one difference between __len__ and __sizeof__. __sizeof__ 
should be overloaded only for C-implemented classes. IMHO, it is a part of C 
API.

--

___
Python tracker 

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

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

[Chris Jerdonek]

Chris Jerdonek added the comment:

> Less favorable, because it produces longer import strings
("test.support.some_helper" instead of "test.some_helper").

This can be addressed by exposing the API in __init__.py though (as does, say, 
the unittest package), no?

--

___
Python tracker 

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

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

[Georg Brandl]

Georg Brandl added the comment:

Please reopen if you think it should be backported.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8a02a93c803a by Antoine Pitrou in branch '3.2':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/8a02a93c803a

New changeset 1d811e1097ed by Antoine Pitrou in branch 'default':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/1d811e1097ed

--
nosy: +python-dev

___
Python tracker 

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

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le dimanche 29 juillet 2012 à 17:00 +, Chris Jerdonek a écrit :
> Chris Jerdonek added the comment:
> 
> > Less favorable, because it produces longer import strings
> ("test.support.some_helper" instead of "test.some_helper").
> 
> This can be addressed by exposing the API in __init__.py though (as
> does, say, the unittest package), no?

Yes, that's right.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1102e86b8739 by Antoine Pitrou in branch '2.7':
Issue #15487: Add a __sizeof__ implementation for buffered I/O objects.
http://hg.python.org/cpython/rev/1102e86b8739

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Antoine Pitrou]

Antoine Pitrou added the comment:

Thanks for the patch :)

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

___
Python tracker 

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

[issue15436] __sizeof__ is not documented

[Martin v . Löwis]

Martin v. Löwis added the comment:

> I think there is one difference between __len__ and __sizeof__. __sizeof__ 
> should be overloaded only for C-implemented classes. IMHO, it is a part of C 
> API.

That is a reasonable point. So documenting it along with the type slots
might be best.

--

___
Python tracker 

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

[issue15452] Eliminate the use of eval() in the logging config implementation

[Vinay Sajip]

Vinay Sajip added the comment:

> As far as your other suggestion goes, don't reinvent crypto badly -
> if you want to provide authentication support in listener(), provide a
> hook that allows the application to decide whether or not to accept
> the configuration before it gets applied.

Well, that's fine. My earlier suggestion keeps the API change to a minimum, but 
I suppose there's no real need to be so minimal.

I suppose the basic approach would be to pass to listen() an optional verify 
callable (defaulting to None) which, if provided, would be called with the 
bytes received over the socket. That allows for e.g. signed or encrypted data. 
The value returned from the verify() call would be processed as the current 
received value is (allowing the verifier to transform the input, e.g. by 
decrypting it).

--

___
Python tracker 

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

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

[Antoine Pitrou]

Antoine Pitrou added the comment:

That said, given the nature of the patch (a cleanup without any functional 
impact), I don't think it should be a release blocker.

--

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Meador Inge]

Meador Inge added the comment:

On Sun, Jul 29, 2012 at 11:50 AM, Serhiy Storchaka  
wrote:

>> Serhiy, I didn't analyze it too in depth, but why aren't the test cases
>> using the __sizeof__ support work you implemented for issue15467?  I think
>> these tests should be using the more exact method like your other
>> '__sizeof__' patches.
>
> Because struct has not codes for Py_off_t and PyThread_type_lock.

Of course it doesn't -- those are Python specific typedefs.  
'PyThread_type_lock'
is just a typedef to 'void *' and something could be figured out for 'Py_off_t'
in the support code.

Anyway, the way you are implementing the tests has the same issue as Martin 
pointed
out for the 'object.__sizeof__' method in issue15402.  I could replace the 
'buffered_sizeof' implementation with:

   static PyObject *
   buffered_sizeof(buffered *self, void *unused)
   {
   Py_ssize_t res;

   res = 1;
   if (self->buffer)
   res += self->buffer_size;
   return PyLong_FromSsize_t(res);
   }

and the tests will still pass.

--
nosy: +loewis

___
Python tracker 

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

[issue15487] Correct __sizeof__ support for buffered I/O

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le dimanche 29 juillet 2012 à 17:45 +, Meador Inge a écrit :
> Anyway, the way you are implementing the tests has the same issue as Martin 
> pointed
> out for the 'object.__sizeof__' method in issue15402.  I could replace the 
> 'buffered_sizeof' implementation with:
> 
>static PyObject *
>buffered_sizeof(buffered *self, void *unused)
>{
>Py_ssize_t res;
> 
>res = 1;
>if (self->buffer)
>res += self->buffer_size;
>return PyLong_FromSsize_t(res);
>}
> 
> and the tests will still pass.

That's true but, OTOH, I don't think it's very important. First, because
it is a rather unlikely mistake. Second, because the important thing is
to check that the internal buffer is part of the returned size, which is
what Serhiy's test checks for.

--

___
Python tracker 

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

[issue15488] Closed files keep their buffer alive

[Antoine Pitrou]

New submission from Antoine Pitrou:

>>> f = open("LICENSE", "rb")
>>> sys.getsizeof(f)
4296
>>> f.close()
>>> sys.getsizeof(f)
4296

Instead of waiting for the file object's deallocation, perhaps we should free 
the buffer when it is closed?

--
components: IO, Library (Lib)
messages: 166801
nosy: pitrou
priority: low
severity: normal
status: open
title: Closed files keep their buffer alive
type: resource usage
versions: Python 3.3, Python 3.4

___
Python tracker 

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

[issue15488] Closed files keep their buffer alive

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +benjamin.peterson, hynek, stutzbach

___
Python tracker 

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

[issue15488] Closed files keep their buffer alive

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

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