[issue14182] collections.Counter equality test thrown-off by zero counts

[Mark Dickinson]

Mark Dickinson added the comment:

> Raymond, Stephen's analysis seems correct.  Are we missing something or
> can this issue be closed?

Well, depending on how you think about Counters, the current behaviour of 
equality definitely leads to some surprises.  For example:

>>> Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0)
False

OTOH, if we're consistent about regarding a count of 0 as 'equivalent' to a 
missing element, then __nonzero__ / __bool__ probably needs changing, too.

>>> c = Counter(a = 0)
>>> bool(c)
True
>>> bool(c + c)
False

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue15571] Python version of TextIOWrapper ignores "write_through" arg

[Chris Jerdonek]

Chris Jerdonek added the comment:

The fact that the Python implementation doesn't look at write_through doesn't 
necessarily mean that it's not respected.  It could always write through.  
Indeed, it looks like this is the case and was discussed at one point:

http://bugs.python.org/issue12591#msg141006

Also, it appears that there is a test in both cases (the test class is 
subclassed twice), though I could be wrong:

http://hg.python.org/cpython/file/0eeffeadaa1e/Lib/test/test_io.py#l2453

In any case, this could probably at least use a code comment.

--
nosy: +cjerdonek

___
Python tracker 

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

[issue15571] Python version of TextIOWrapper ignores "write_through" arg

[Nick Coghlan]

Nick Coghlan added the comment:

Ah, thanks. Yes, that could definitely use a comment :)

--
priority: release blocker -> normal
stage: test needed -> needs patch
type: behavior -> enhancement

___
Python tracker 

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

[issue15571] Python version of TextIOWrapper ignores "write_through" arg

[Chris Jerdonek]

Chris Jerdonek added the comment:

Attaching patch.

--
keywords: +patch
Added file: http://bugs.python.org/file26716/issue-15571-1.patch

___
Python tracker 

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

[issue13992] Segfault in PyTrash_destroy_chain

[Francois VISCONTE]

Francois VISCONTE added the comment:

Hi, 

Following Manu's information I complete with what you asked. 
I repeated the bug described by Manu, with the same software in exactly the 
same conditions.

The corrupted object is one of our SQLAlchemy mapped object. Chances are that 
the bug came from SQLAlchemy.

Find joined the "thread all apply bt" output. I will investigate today on this 
bug and will try to find a quicker way to reproduce it in order to use an 
hardware watchpoint on object refcount.

--
nosy: +fvisconte
Added file: http://bugs.python.org/file26717/thread_all_apply_bt.txt

___
Python tracker 

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

[issue15424] __sizeof__ of array should include size of items

[Ludwig Hähne]

Ludwig Hähne added the comment:

Meador, thanks for reviewing. The updated patch is now attached to the bug.

--
Added file: http://bugs.python.org/file26718/array_sizeof_v5.patch

___
Python tracker 

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

[issue11715] Building Python on multiarch Debian and Ubuntu

[Matthias Klose]

Matthias Klose added the comment:

about searching /lib/: adding this directory won't help. all .a and 
.so files are installed in /usr/lib or /usr/lib/.

about the missing dpkg-architecture: see the attached ma.diff patch. the 
Debian/Ubuntu system compilers add an option -print-multiarch, which can be 
used to get the multiarch name without having the dpkg-dev package installed.

--
nosy: +doko
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file26719/ma.diff

___
Python tracker 

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

[issue14330] don't use host python, use host search paths for host compiler

[Matthias Klose]

Matthias Klose added the comment:

these are all extensions, which use headers and libraries installed in 
multiarch paths, which I think are not found in this case. If the dpkg-dev 
package isn't installed, please install it and recheck. So this issue should be 
closed, maybe with the ma.diff patch applies as in issue #15426.

--

___
Python tracker 

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

[issue14330] don't use host python, use host search paths for host compiler

[Matthias Klose]

Matthias Klose added the comment:

and please make sure that other build dependencies are installed as well:

 sudo apt-get build-dep python3.2 (on 12.04/precise)

 sudo apt-get build-dep python3.3 (on 12.10/quantal)

--

___
Python tracker 

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

[issue15560] _sqlite3.so is built with wrong include file on OS X when using an SDK

[Roundup Robot]

Roundup Robot added the comment:

New changeset 59223da36dec by Ned Deily in branch 'default':
Issue #15560: Ensure consistent sqlite3 behavior and feature availability
http://hg.python.org/cpython/rev/59223da36dec

--

___
Python tracker 

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

[issue14330] don't use host python, use host search paths for host compiler

[Matthias Klose]

Matthias Klose added the comment:

afaics, msg166444 doesn't have to do anything with the cross build issue, but a 
missing build dependency (here: dpkg-dev).

--

___
Python tracker 

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

[issue15424] __sizeof__ of array should include size of items

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Patch looks good to me, however tests for 3.2 and 2.7 should be modified 
(change "n" struct format specifier to "P", remove last "i" and use 
test_support instead test.support (or import test_support as support) in 2.7).

--

___
Python tracker 

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

[issue15572] Python2 documentation of the file() built-in function

[Cherniavsky Beni]

New submission from Cherniavsky Beni:

[followup for issue 12642 which only fixed it for open()]

http://docs.python.org/library/functions.html#file
says the arg names are:
  file(filename[, mode[, bufsize]])
but in practice they are:
  file(name[, mode[, buffering]])

--
assignee: docs@python
components: Documentation
messages: 167617
nosy: cben, docs@python
priority: normal
severity: normal
status: open
title: Python2 documentation of the file() built-in function
versions: Python 2.7

___
Python tracker 

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

[issue14870] Descriptions of os.utime() and os.utimensat() use wrong notation

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage:  -> needs patch
type:  -> enhancement

___
Python tracker 

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

[issue15572] Python2 documentation of the file() built-in function

[Eli Bendersky]

Changes by Eli Bendersky :


--
nosy: +eli.bendersky

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Stefan Krah]

New submission from Stefan Krah:

Continuing the discussion from #13072. I hit a snag here:

Determining in full generality whether two format strings describe
identical items is pretty complicated, see also #3132.


I'm attaching a best effort fmtcmp() function that should do the
following:

  - recognize byte order specifiers at the start of the string.

  - recognize if an explicitly specified byte order happens to
match the native byte order.

It won't catch:

  - byte order specifiers anywhere in the string.

  - C types that happen to be identical ('I', 'L' on a 32-bit
platform). I'm also not sure if that is desirable in the
first place.

  - ???


So fmtcmp() will return false negatives (not equal), but should be
correct for *most* format strings that are actually in use.


Mark, Meador: You did a lot of work on the struct module and of
course on issue #3132. Does this look like a reasonable compromise?
Did I miss obvious cases (see attachment)?

--
assignee: skrah
components: Interpreter Core
files: format.c
messages: 167618
nosy: Arfrever, georg.brandl, haypo, mark.dickinson, meador.inge, ncoghlan, 
pitrou, python-dev, skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Support unknown formats in memoryview comparisons
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26720/format.c

___
Python tracker 

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

[issue15570] email.header.decode_header parses differently

[R. David Murray]

R. David Murray added the comment:

This is an intentional change (see issue 1079).  It is entirely possible that 
this bug fix should be reverted, however, because of backward compatibility 
concerns.  I'm open to that argument, but I'd prefer to keep the fixed 
behavior, since the unfixed behavior causes us to violate the RFCs in several 
cases, as you can see from that and the related issues.

Note also the availability in 3.3 of the provisional email policies that will 
do an automatic full decode-to-unicode of such headers.

--
components: +email -Library (Lib)
nosy: +barry, r.david.murray

___
Python tracker 

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

[issue12641] Remove -mno-cygwin from distutils

[Ruben Van Boxem]

Ruben Van Boxem added the comment:

Checking for a compiler's file name is stupid. Native Windows gcc is just 
"gcc.exe", Cygwin native GCC is also "gcc". Some have a lot of toolchains in 
PATH at the same time. That's not the right way to handle this kind of thing.

--

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Nick Coghlan]

Nick Coghlan added the comment:

I confess I was thinking of an even simpler "format strings must be identical" 
fallback, but agree your way is better, since it reproduces the 3.2 behaviour 
in many more cases where ignoring the format string actually did the right 
thing.

The struct docs for the byte order specifier specifically say "the first 
character of the format string can be used to indicate the byte order, size and 
alignment of the packed data", so treating format strings that include byte 
order markers elsewhere in the string as differing from each other if those 
markers are in different locations sounds fine to me.

--

___
Python tracker 

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

[issue15572] Python2 documentation of the file() built-in function

[Daniel Ellis]

Daniel Ellis added the comment:

I've updated the documentation.  This is my first patch, so please let me know 
if I've done something wrong.

--
keywords: +patch
nosy: +Daniel.Ellis
Added file: http://bugs.python.org/file26721/file_update.patch

___
Python tracker 

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

[issue15500] Python should support naming threads

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

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

[issue8800] add threading.RWLock

[Matthew Lauber]

Changes by Matthew Lauber :


--
nosy: +mklauber

___
Python tracker 

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

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Dave Malcolm]

Dave Malcolm added the comment:

On Tue, 2010-11-02 at 17:25 +, Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
> 
> I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to 
> support this. Also, why do you allow any arguments to sys._breakpoint()?
Agreed about _Py_BREAKPOINT.

The reason for allowing arguments to sys._breakpoint() is so that the
developer can pass in arbitrary objects (or collections of objects),
which can then be easily inspected from the debugger.  Does that seem
sane?

Maybe the docs should read:

--
This may be of use when tracking down bugs: the breakpoint can be
guarded by Python-level conditionals, and supply Python-generated data::

   if foo and bar and not baz:
   sys._breakpoint(some_func(foo, bar, baz))

In the above example, if the given python conditional holds (and no
exception is raised calling "some_func"), execution will halt under
the debugger within Python/sysmodule.c:sys_breakpoint, and the result of
some_func() will be inspectable in the debugger as
((PyTupleObject*)args)[0]

   static PyObject *
   sys_breakpoint(PyObject *self, PyObject *args)
   {
 _Py_BREAKPOINT();
 Py_RETURN_NONE;
   }

It can also be useful to call when debugging the CPython interpreter: if
you add a call to this function immediately before the code of interest,
you can step out of sys_breakpoint and then step through subsequent
execution.
--

I thought about it making it METH_O instead (to make it easier to look
at a single object), but then you'd be forced to pass an object in when
using it, I think (though None should work).

--

___
Python tracker 

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

[issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12

[Leon Maurer]

New submission from Leon Maurer:

I'm getting crashes with IDLE like those that have been reported before (e.g. 
by trying to copy using Command-C), but I followed (or at least tried to 
follow) the directions at

http://www.python.org/getit/mac/tcltk/

and have installed Python 2.7.3 64-bit/32-bit and ActiveTcl 8.5.12.

I've attached the crash log. I believe the following lines shows that I am 
using Tk 8.5.12 and not Apple's buggy version:

0x671000 -   0x76fff7 +Tk 8.5.12 (8.5.12) 
 
/Library/Frameworks/Tk.framework/Versions/8.5/Tk

Thanks.

--
components: IDLE
files: IDLE crash.rtf
messages: 167624
nosy: Leon.Maurer
priority: normal
severity: normal
status: open
title: IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file26722/IDLE crash.rtf

___
Python tracker 

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

[issue14330] don't use host python, use host search paths for host compiler

[Georg Brandl]

Georg Brandl added the comment:

Ezio?

--

___
Python tracker 

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

[issue14330] don't use host python, use host search paths for host compiler

[Stefan Krah]

Stefan Krah added the comment:

Installing dpkg-dev indeed resolved the issue for me on Debian Wheezy,
but msg166444 said that the problem appeared in 7955d769fdf5. 

So was dpkg-dev already an official dependency before 7955d769fdf5
or not?

--
nosy: +skrah

___
Python tracker 

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

[issue14330] don't use host python, use host search paths for host compiler

[Stefan Krah]

Stefan Krah added the comment:

With ma.diff from #11715 dpkg-dev is indeed not required (checked
on Wheezy).

--

___
Python tracker 

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

[issue15575] Tutorial is unclear on multiple imports of a module.

[Roy Smith]

New submission from Roy Smith:

Opening this bug at Ben Finney's request.  See 
https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/wmDUrpW2ZCU 
for the full thread discussing the problem.  Here's a significant excerpt:

-
The tutorial is misleading on this. It it says plainly: 

A module can contain executable statements as well as function 
definitions. […] They are executed only the *first* time the module 
is imported somewhere. 

http://docs.python.org/tutorial/modules.html> 

but it doesn't make clear that a module can exist in the ‘sys.modules’ 
list multiple times under different names. 
-


Also note:

--
The footnote to that is wrong too: 

> [1]In fact function definitions are also ‘statements’ that are 
> ‘executed’; the execution of a module-level function enters the function name 
> in the module’s global symbol table. 

I think what it's supposed to say is "... the execution of a module-level def 
statement ..." 
---

--
assignee: docs@python
components: Documentation
messages: 167628
nosy: docs@python, roysmith
priority: normal
severity: normal
status: open
title: Tutorial is unclear on multiple imports of a module.
type: enhancement
versions: Python 2.7

___
Python tracker 

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

[issue15575] Tutorial is unclear on multiple imports of a module.

[R. David Murray]

R. David Murray added the comment:

Well, I don't think a full discussion of the subtlety about a module appearing 
under multiple names belongs in the tutorial, but I think the sentence could be 
amended to say "Statements in a module are executed only the *first* time the 
module name is encountered in an import statement".

The other is indeed a bug (IMO the sentence is missing the word 'definition', 
as in 'execution of a function definition').

--
nosy: +r.david.murray

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[Stefan Behnel]

New submission from Stefan Behnel:

The new importlib shows a regression w.r.t. previous CPython versions. It no 
longer recognises an "__init__.so" file as a package. All previous CPython 
versions have always tested first for an extension file before testing for a 
.py/.pyc file. The new importlib explicitly excludes the ExtensionFileLoader 
from loading packages. See importlib/_bootstrap.py, line 1579 onwards:

   1579 def _get_supported_file_loaders():
   1580 """Returns a list of file-based module loaders.
   1581 
   1582 Each item is a tuple (loader, suffixes, allow_packages).
   1583 """
   1584 extensions = ExtensionFileLoader, _imp.extension_suffixes(), False  
  # <== bug here
   1585 source = SourceFileLoader, SOURCE_SUFFIXES, True
   1586 bytecode = SourcelessFileLoader, BYTECODE_SUFFIXES, True
   1587 return [extensions, source, bytecode]

(BTW, I'm not sure what to file this bug against - "Interpreter Core" or 
"Library"?)

--
components: Library (Lib)
messages: 167630
nosy: scoder
priority: normal
severity: normal
status: open
title: importlib: ExtensionFileLoader not used to load packages from 
__init__.so files
type: behavior
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

[issue15501] Document exception classes in subprocess module

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
stage:  -> patch review

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[Eric Snow]

Changes by Eric Snow :


--
nosy: +brett.cannon

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue15572] Python2 documentation of the file() built-in function

[Roundup Robot]

Roundup Robot added the comment:

New changeset db1b4aab53eb by Benjamin Peterson in branch '2.7':
make documented file() kw names and actual ones agree (closes #15572)
http://hg.python.org/cpython/rev/db1b4aab53eb

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

[issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12

[Roger Serwy]

Changes by Roger Serwy :


--
nosy: +ned.deily

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[Stefan Behnel]

Stefan Behnel added the comment:

Additional info: working around this bug from user code is fairly involved 
because some FileLoader instances are already created early at initialisation 
time and the overall configuration of the FileLoaders is kept in the closure of 
a path hook.

--

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[R. David Murray]

R. David Murray added the comment:

I wouldn't worry about working around it from user code...finding and fixing 
regressions is what the beta period is for, after all.

As for which component, that's a good question with importlib ;)  Both, I 
suppose.  Not that components are used for much other than auto-nosy, and 
there's no auto-nosy for either interpreter core or library.

--
components: +Interpreter Core
nosy: +r.david.murray
priority: normal -> release blocker
stage:  -> needs patch

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[Brett Cannon]

Brett Cannon added the comment:

So this was on purpose. At some point over the past five years I was working on 
importlib I think I was told I shouldn't support it (or something) as I 
explicitly remember making the decision to not support __init__.so on purpose. 
Plus the package specification never suggested anything but __init__.py to be 
used to begin with, so it isn't a bug as much as a design oversight (as is a 
large portion of import semantics unfortunately). But I take it Cython has been 
relying on this for years so that kind of kills treating this as part of import 
semantics cleanup.

Now to reverse this several things need to happen. First the whole third item 
in the tuples passed to PathFinder is unneeded (it existed purely to block 
extension module __init__ files) and thus should be removed where necessary. 
Second, the tests for extensions (test.test_importlib.extension.test_finder) 
need to be updated, but that gets messy as there is no __init__.so in the 
stdlib to test against to verify everything works. Tests could cheat and muck 
with PathFinder's file cache, but that is definitely not a blackbox test 
anymore. Don't know how best to deal with this short of an xx/__init__.so 
module being added to the stdlib.

And just for future reference, Stefan, since this is a direct import issue and 
not something to do with importlib's API I consider it an Interpreter Core bug.

And I'm glad we cache directory stat results now as changing this will have 
minuscule overhead compared to adding another stat call per package search 
without the cache.

--
components:  -Library (Lib)

___
Python tracker 

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

[issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12

[Ned Deily]

Ned Deily added the comment:

Ouch! That appears to be a major regression in the newly released ActiveTcl 
8.5.12.  I can easily reproduce a crash just using wish8.5 so the problem is 
strictly in Tcl/Tk itself, not Python.  If you have an older version of 
ActiveTcl 8.5 available, you can revert to that.  Unfortunately, ActiveState's 
policy is to only make the most recent Community Edition release openly 
available on their website.  I've raised this issue on the Mac Tcl mailing list:

http://dir.gmane.org/gmane.comp.lang.tcl.mac

--
assignee:  -> ned.deily

___
Python tracker 

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

[issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12

[Leon Maurer]

Leon Maurer added the comment:

Thanks for the quick response. I don't have access to an older version of 
ActiveTcl, but in truth, I'm mostly relieved that it's not just me. (I spent a 
long time trying to figure out why some Tkinter code I had written would work 
on Linux and Windows but not OS X...)

--

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[Stefan Behnel]

Stefan Behnel added the comment:

Hi, thanks for bringing in the 'historical details'. It's not so much that 
"Cython has been relying on it" - it's entirely up to users what they compile 
and what not. It's more that I don't see anything being wrong with it as a 
feature and that it worked before.

The reason why I found it was that I'm trying to make Python benchmark suite 
run better in Cython, and that requires compiling all code, some of which is 
often hidden in the package file.

I understand that this is probably a rare real-world requirement because things 
can usually be made to work by moving code into a separate extension module and 
reimporting it from there into an __init__.py module. I guess that's why people 
told you to drop the feature.

There's also issue13429, which still restricts the init time compatibility of 
binary extensions with normal Python modules. Arguably, to make __init__.so 
work correctly, the "__path__" attribute would have to be set at module 
creation time as well, otherwise, relative imports won't work during 
initialisation. I guess I should update my patch in that ticket to reflect that.

--
components: +Library (Lib) -Interpreter Core

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

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

[issue15576] importlib: ExtensionFileLoader not used to load packages from __init__.so files

[Brett Cannon]

Brett Cannon added the comment:

That's another thing that would need to be changed; ExtensionFileLoader would 
need to work for is_package() and would need to set __path__ as needed.

--

___
Python tracker 

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

[issue15577] Real Argc Argv in embeded interpreter

[nordaux]

New submission from nordaux:

I have found out certain peculiarity of interpreter in case it is embedded.
There is no way to reference to the real parameters argv, argc of main process 
from embedded python's C extensions.
When python is not embedded, it is task of function Py_Main, which sets the 
value of variables orig_argv, orig_argc.
These variables keep references to the original values of  argv, argc and give 
opportunity to manage them from the python C extensions if necessary.
I understand that the function Py_GetArgcArgv is rarely used, and this is true, 
but still believe that ability to manipulate these variables should be exist in 
any form of python from its C extension modules.
I tried different modules of C-extensions with such functional in embedded 
environment, but they all causes Segmentation Fault. The problem is not only in 
their implementation quality without any additional inspections, but also the 
function Py_GetArgcArgv doesn't additionally reported that its returned, and 
just ruturn null pointer in self argv parameter when used in embedded 
environment.
The following quote all the code that refers to this functionality in Python 
2.7-3.3 at the moment:

/* For Py_GetArgcArgv(); set by main() */
static char **orig_argv;
static int  orig_argc;

..
/* Main program */

int
Py_Main(int argc, char **argv)
{
..
orig_argc = argc;   /* For Py_GetArgcArgv() */
orig_argv = argv;
..
}

void
Py_GetArgcArgv(int *argc, char ***argv)
{
*argc = orig_argc;
*argv = orig_argv;
}

Thats why I would like to suggest something similar to such function and use it 
in Py_Main and probably make it available from Python C API.
And also extend Py_GetArgcArgv with more detailed null pointer handling if 
variables orig_argv, orig_argc had not been initialized.

void
Py_InitArgcArgv(int *argc, char ***argv)
{
if(! *argv) return -1;

orig_argc = *argc;   /* For Py_GetArgcArgv() */
orig_argv = *argv;

return 0;   
}

Would like to see other suggestions.
Thanks.

--
components: Extension Modules, Interpreter Core
messages: 167639
nosy: nordaux
priority: normal
severity: normal
status: open
title: Real Argc Argv in embeded interpreter
type: crash
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

[issue15577] Real Argc Argv in embedded interpreter

[nordaux]

Changes by nordaux :


--
title: Real Argc Argv in embeded interpreter -> Real Argc Argv in embedded 
interpreter

___
Python tracker 

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

[issue15578] Crash when modifying sys.modules during import

[Thomas Wouters]

New submission from Thomas Wouters:

In a submodule of a package, replacing the parent package in sys.modules during 
import of the package (meaning the only reference to it is in sys.modules) and 
then importing itself (or something from itself) crashes the interpreter:

centurion:~/python/crasher > cat sa/__init__.py
import v1
centurion:~/python/crasher > cat sa/v1/__init__.py
import sys
sys.modules['sa'] = sys.modules[__name__]
import sa
centurion:~/python/crasher > python -c 'import sa'
Segmentation fault (core dumped)

It seems the crash is not entirely deterministic, as we've had the original 
code this was reduced from run in Python 2.4 and 2.6 for years, and only 
discovered the crash when switching to 2.7. However, running the reduced 
testcase crashes for me in all of Python 2.7, 2.6, 2.4 and 2.2, in debug builds 
and opt builds. Given the nature of the bug I expect debug builds to crash 
reliably.

I haven't found the actual source of the problem, but what seems to happen is 
that the import mechanism has a borrowed reference to the 'sa' module around, 
assuming it'll stay alive while the submodules are imported because it's also 
stored in sys.modules. This assumption is incorrect. However, changing the 
import in sa/__init__.py into an absolute or explicit relative import seems to 
fix the problem, which means this probably won't affect Python 3.

--
components: Interpreter Core
messages: 167640
nosy: twouters
priority: normal
severity: normal
status: open
title: Crash when modifying sys.modules during import
type: crash
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue9890] Visual C++ Runtime Library Error is there a fix?

[Karen KarenL]

Karen KarenL added the comment:

Yes. It is the same bug. And changing pythonhome path from c:\python26 to
c:\python32 fixes the problem. My initial google search found bug 9890, but
not 11288. Let me know if there is anything I can do.

Karen

On Mon, Aug 6, 2012 at 8:27 PM, Roger Serwy  wrote:

>
> Roger Serwy added the comment:
>
> Karen, thank you for your reply and your cooperation. This issue may
> take some time to resolve.
>
> It looks like the error you are receiving has been addressed in
> issue11288. Can you check it out?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue15578] Crash when modifying sys.modules during import

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue15578] Crash when modifying sys.modules during import

[R. David Murray]

R. David Murray added the comment:

If I remember correctly there were non-trivial improvements made to the way 
modules are finalized in 2.7 compared to earlier versions.  That could be what 
exposed the bug.  The pre-2.7 code might have been leaving another reference 
alive because of your more complex real world example, whereas the simplified 
example doesn't.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue14330] don't use host python, use host search paths for host compiler

[Ezio Melotti]

Ezio Melotti added the comment:

On another Ubuntu 12.04 machine with dpkg-dev installed I didn't have any 
issue.  Once I removed dpkg-dev I was able to reproduce the issue again.
Applying ma.diff from #11715 solves the issue, with and without dpkg-dev 
installed.

--

___
Python tracker 

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

[issue15574] IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12

[Ned Deily]

Ned Deily added the comment:

The Mac Tcl community has jumped on the problem and there is now a tentative 
patch for Tk:

http://permalink.gmane.org/gmane.comp.lang.tcl.core/14173

I've opened a formal issue on the Tcl/Tk bug tracker here:

https://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&a
tid=112997

I'll leave this issue in pending status until the fix has been released and 
verified in a version of ActiveTcl.  Thanks for the report!

--
resolution:  -> out of date
status: open -> pending

___
Python tracker 

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

[issue15579] some unicode keys not found using in dictionary.keys()

[axw]

New submission from axw:

This simple snippet demonstrates the misbehaviour. Confirmed on two amd64 
machines, python 2.7.3. 

###

import copy

uzlist = [u'abc', u'def', u'ghj', u'klm', u'zxc']
utzdict = {u'abc':1, u'def':2, u'ghj':3, u'klm':4, u'zxc':5}

utemplist = copy.copy(uzlist)
for m in utemplist:
if m in utzdict.keys(): utemplist.remove(m)

# utemplist should be empty now - it is not!
>>> utemplist
[u'def', u'klm']

utemplist = copy.copy(uzlist)
for i in range(len(uzlist)):
   try: 
 if utzdict[ uzlist[i] ]: utemplist.remove( uzlist[i] )
   except KeyError: pass

# utemplist should be empty now. This time it is:
>>> utemplist
[]

--
components: Interpreter Core, Unicode
messages: 167645
nosy: axw, ezio.melotti
priority: normal
severity: normal
status: open
title: some unicode keys not found using in dictionary.keys()
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue15574] IDLE crashes using clipboard copy command on OS X with ActiveTcl 8.5.12

[Ned Deily]

Changes by Ned Deily :


--
status: pending -> open
title: IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12 -> IDLE crashes 
using clipboard copy command on OS X with ActiveTcl 8.5.12

___
Python tracker 

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

[issue15574] IDLE crashes using clipboard copy command on OS X with ActiveTcl 8.5.12

[Ned Deily]

Changes by Ned Deily :


--
status: open -> pending
versions: +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

[issue15579] some unicode keys not found using in dictionary.keys()

[R. David Murray]

R. David Murray added the comment:

In the first example you are shrinking the list you are iterating over, so not 
all of the items in the list are going to be tested.  Try doing for m in uzlist 
instead.

--
nosy: +r.david.murray
resolution:  -> invalid
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

[issue15579] some unicode keys not found using in dictionary.keys()

[axw]

axw added the comment:

Thanks, I did not realize that. The behaviour is obviously correct.

--
resolution: invalid -> 

___
Python tracker 

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

[issue15579] some unicode keys not found using in dictionary.keys()

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> invalid

___
Python tracker 

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

[issue15580] fix True/False/None reST markup

[Chris Jerdonek]

New submission from Chris Jerdonek:

The Dev Guide says not to markup True, False, and None in the documentation in 
a way that generates a link (e.g. ":const:`True`") because "they’re fundamental 
to the language and should be known to any programmer":

http://docs.python.org/devguide/documenting.html#documenting

Rather, it says to use "``True``" (and similarly for False and None):

This issue is to update the documentation to conform to this guidance.

While working on the documentation, I noticed many occurrences of 
":const:`True`", for example.  See here for some examples, where you can see 
the hyperlinks:

http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.add

--
assignee: docs@python
components: Documentation
messages: 167648
nosy: cjerdonek, docs@python
priority: normal
severity: normal
status: open
title: fix True/False/None reST markup

___
Python tracker 

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

[issue15424] __sizeof__ of array should include size of items

[Meador Inge]

Meador Inge added the comment:

Georg, yet another __sizeof__ fix.  OK for 3.3?

--
nosy: +georg.brandl
stage:  -> commit review

___
Python tracker 

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

[issue15580] fix True/False/None reST markup

[Chris Jerdonek]

Chris Jerdonek added the comment:

Here is a command to find the file names of all occurrences:

find Doc -type f -name *.rst | xargs grep -ERl ":const:\`(True|False|None)\`"

The occurrences are in the following directories:

Doc/c-api/
Doc/library/
Doc/reference/
Doc/whatsnew/

And here are commands to do the replacement on a branch.

# Replace the occurrences inside tables, to preserve table alignment.
find Doc/c-api/ Doc/library/ Doc/reference/ -type f -name *.rst | \
  xargs sed -i '' \
-e 's/\(\|.*\):const:`True`/\1``True`` /g' \
-e 's/\(\|.*\):const:`False`/\1``False`` /g' \
-e 's/\(\|.*\):const:`None`/\1``None`` /g'

# Replace the rest of the occurrences.
find Doc/c-api/ Doc/library/ Doc/reference/ -type f -name *.rst | \
  xargs sed -i '' \
-e 's/:const:`True`/``True``/g' \
-e 's/:const:`False`/``False``/g' \
-e 's/:const:`None`/``None``/g'

I left out Doc/whatsnew/ because the What's New is historical and because it 
includes entries describing the introduction of True/False, which may be 
considered special.

Incidentally, the constants documentation of True/False/None link to the 
descriptions using ":data:`True`", etc, so they are not affected by this change:

http://docs.python.org/dev/library/constants.html#built-in-constants

To commit, the commands above could be run on a branch and committed, then 
merged forward to newer branches, and then the scripts re-run on the next newer 
branch to catch new introductions of True/False/None, and so on.

For illustration purposes only, I'm attaching the patch that results from 
running the script on the default branch.

--
keywords: +patch
Added file: http://bugs.python.org/file26723/script-result-default-branch.patch

___
Python tracker 

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

[issue15510] textwrap.wrap('') returns empty list

[Greg Ward]

Greg Ward added the comment:

Random comments from original author of textwrap.py, in case anyone cares at 
this point...

* This is a pretty obscure edge case, and I admit that it never occurred to me 
when writing the code. (If it had, I would have tested it!)

* One can debate endlessly about whether this is a bug or not -- witness the 
recent discussion on this bug. Meh. Not interesting. IMHO it's better described 
as undefined behaviour. If you want it defined, write tests to enforce the 
status quo and improve the docs.

* If there is a consensus to change the current behaviour, IMHO it should NOT 
be done on 2.7. Even if the new behaviour is better by some definition, it's 
still a behaviour change that could bite someone. Those changes should happen 
when you make a major upgrade (3.2 to 3.3, say), not when you make a bug fix 
upgrade (2.7.3 to 2.7.4). IOW: keep it on trunk. Or default, whatever we're 
calling it these days. ;-)

--

___
Python tracker 

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

[issue15510] textwrap.wrap('') returns empty list

[Chris Jerdonek]

Chris Jerdonek added the comment:

Thanks for weighing in, Greg!

At least for me, this edge case was important because it determines how the 
canonical advice or recipe for handling multiple paragraphs behaves when the 
input string has line breaks in between paragraphs.  That advice, of course, is 
to call splitlines(), pass the individual paragraphs to wrap(), and then join 
on newlines.

Here is an example on a paragraph with line breaks between paragraphs:

>>> def wrap_paras(text, width=70, **kwargs):
... lines = [line for para in text.splitlines()
...   for line in wrap(para, width, **kwargs)]
... return "\n".join(lines)
...
>>> text = """\
... abcd abcd
...
... abcd abcd"""
>>> print(wrap_paras(text))
abcd abcd
abcd abcd

The edge case we're discussing determines whether line breaks between 
paragraphs are preserved in the result.  (With current behavior, they are not.)

> If you want it defined, write tests to enforce the status quo and improve the 
> docs.

Given the discussion so far (and in particular, opposition to changing 
behavior), this is the route I'm hoping we can go.  Interesting or not, I think 
it's good that we at least had this discussion before setting the behavior in 
stone. :)

--

___
Python tracker 

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

[issue15581] curses: segfault in addstr()

[hut]

New submission from hut:

Under certain circumstances, the curses function addstr() will cause a segfault 
in python3.2.3 and python2.7.3.

Necessary, but not sufficient conditions are:
1. the window has been resized while curses was running
2. addstr() attempts to write a string that doesn't fit into the window, 
resulting in the cursors y-position being outside of the boundaries (which 
would normally only raise a _curses.error)

Instead of the "Segmentation Fault" message, I also sometimes get one of these 
two messages when python crashes:
*** glibc detected *** python2.7: corrupted double-linked list: 0x0949cc98 ***
python2.7: malloc.c:3964: _int_free: Assertion 
`nextchunk->fd_nextsize->bk_nextsize == nextchunk' failed.

To my shame, I didn't try to debug python myself, and I can't offer a minimal 
program to reproduce this bug, but I did find a way to reproduce it in the 
python program "ranger":

Link to the bug in rangers bug tracker with steps to reproduce:
https://github.com/hut/ranger/issues/45

Download link to the affected version of ranger:
https://github.com/hut/ranger/tarball/5ee1e874cc5f9136af3a9a835b76076a85693bd0

--
components: Extension Modules
messages: 167653
nosy: hut
priority: normal
severity: normal
status: open
title: curses: segfault in addstr()
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue15582] Enhance inspect.getdoc to follow inheritance chains

[Nick Coghlan]

New submission from Nick Coghlan:

Currently, if you override a method from a base class, the docstring is not 
inherited, even if it remains accurate.

This issue proposes an enhancement to inspect.getdoc() that allows the 
docstring to be retrieved from the inheritance hierarchy in the case where it 
is not overridden in the subclass by providing an explicit docstring.

Specifically, in the case where obj.__doc__ is None, and either the first 
parameter is a bound method, or a class object is passed in as the second 
parameter, inspect.getdoc will search the MRO based on obj.__name__ until it 
finds an attribute with a non-None __doc__ value.

(In Python 2, this could have been automatic for both bound and unbound 
methods. Unfortunately, there are no unbound methods in Python 3, so the second 
parameter is needed to handle the unbound method case)

--
components: Library (Lib)
messages: 167654
nosy: eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Enhance inspect.getdoc to follow inheritance chains
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue15573] Support unknown formats in memoryview comparisons

[Meador Inge]

Meador Inge added the comment:

I agree that the general case is complicated.  It will get even more 
complicated if the full of PEP 3118 gets implemented since it turns into a tree 
comparison.  In general, I think you will probably have to compute some 
canonical form and then compare the canonical forms.

Here are a few more cases that don't work out in the attached algorithm:

  1. Repeat characters - '2c' == 'cc'
  2. Whitespace - 'h   h' == 'hh' 

Also, currently the byte order specifiers are always at the beginning of the 
string.  We discussed in issue3132 scoping them per the nested structures, but 
decided to drop that unless somebody barks about it since it is fairly 
complicated without a clear benefit.  So, I wouldn't worry about them being 
scattered through the string.

This seems like sort of a slippery slope.  I need to think about it more, but 
my first impression is that coming up with some way to compare format strings 
is going to be nasty.

--

___
Python tracker 

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

[issue15580] fix True/False/None reST markup

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
stage:  -> patch review
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

[issue14182] collections.Counter equality test thrown-off by zero counts

[Meador Inge]

Meador Inge added the comment:

Ah, good examples Mark.  So, why is it ever useful keep a key with a value of 
zero?  In other words, why:

>>> Counter(a=0)
Counter({'a': 0})

instead of:

>>> Counter(a=0)
Counter()

?

The latter seems more consistent to me.

--

___
Python tracker 

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

[issue15583] Provide examples in Python doc for usage of various modules

[Sarbjit singh]

New submission from Sarbjit singh:

For beginners who are learning Python, it would be very helpful if Python doc 
could provide examples on usage of various methods/attributes of different 
modules.

For eg: If you look at ElementTree XMl module or take any other standard 
module, examples which are provided are very limited making it hard for new 
users to learn those modules and have to search internet for its usage. 
Providing examples on usage of module attributes/methods will help users to 
quickly understand it.

--
assignee: docs@python
components: Documentation
messages: 167657
nosy: Sarbjit.singh, docs@python
priority: normal
severity: normal
status: open
title: Provide examples in Python doc for usage of various modules
type: enhancement

___
Python tracker 

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

[issue15561] update subprocess docs to reference io.TextIOWrapper

[Chris Jerdonek]

Chris Jerdonek added the comment:

io module experts: Can one of you review this minor change to the subprocess 
documentation to make it reference the newly added io.TextIOWrapper 
documentation changes?

For background purposes, digging back, it looks like the original change to 
subprocess was made here: 9ce8fa0a0899

--
nosy: +benjamin.peterson, hynek, pitrou, stutzbach
versions: +Python 3.2

___
Python tracker 

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

[issue15583] Provide examples in Python doc for usage of various modules

[Ezio Melotti]

Ezio Melotti added the comment:

> If you look at ElementTree XMl module or take any other
> standard module, examples which are provided are very limited

We already try to provide examples where/when appropriate, and several modules 
have examples showing the basic usage.  Often, documenting all the methods will 
only make the documentation less readable, so only the most important/common 
functions/methods have examples.  Some modules also have separate howtos that 
contain extensive examples.

If you think some specific module (like ElementTree) needs more examples, feel 
free to open specific reports.

--
nosy: +eli.bendersky, ezio.melotti

___
Python tracker 

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

[issue15580] fix True/False/None reST markup

[R. David Murray]

R. David Murray added the comment:

I think changing these is unnecessary churn.  Change them when you change 
surrounding text, just like we refrain from refactoring for PEP 8 compliance, 
etc, unless we are changing the code for other reasons.  There is nothing 
*wrong* with these being links, it just isn't necessary.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue15583] Provide examples in Python doc for usage of various modules

[R. David Murray]

R. David Murray added the comment:

I'm closing this with no specific resolution because the real resolution is 
"this issue is too general" :)

As Ezio said, specific suggestions are welcome, but should be in separate 
issues limited to the module/example proposed.

--
nosy: +r.david.murray
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

[issue15584] os.popen deprecation warning not in Python 3 docs

[Ramchandra Apte]

New submission from Ramchandra Apte:

The os.popen deprecation warning is not in the Python 3 docs!

--
assignee: docs@python
components: Documentation
messages: 167662
nosy: docs@python, ramchandra.apte
priority: normal
severity: normal
status: open
title: os.popen deprecation warning not in Python 3 docs

___
Python tracker 

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

[issue15585] usage of os.popen in standard library

[Ramchandra Apte]

New submission from Ramchandra Apte:

The following standard library modules use os.popen which is deprecated.
These calls should be replaced with calls to subprocess.Popen .
Ironically, even the subprocess module uses os.popen!
webbrowser.py:osapipe = os.popen("osascript", "w")
webbrowser.py:osapipe = os.popen("osascript", "w")
pydoc.py:pipe = os.popen(cmd, 'w')
uuid.py:with os.popen(cmd) as pipe:
uuid.py:pipe = os.popen(os.path.join(dir, 'ipconfig') + ' /all')
platform.py:#to cover up situations where platforms don't have 
os.popen
platform.py:This is mostly needed in case os.popen() is not available, 
or
platform.py:# over os.popen over _popen
platform.py:popen = os.popen
platform.py:f = os.popen('uname %s 2> %s' % (option, DEV_NULL))
platform.py:f = os.popen('file -b "%s" 2> %s' % (target, DEV_NULL))
idlelib/IOBinding.py:pipe = os.popen(command, "r")
os.py:# Supply os.popen()
subprocess.py:Execute the string 'cmd' in a shell with os.popen() and 
return a 2-tuple
subprocess.py:Execute the string 'cmd' in a shell with os.popen() and 
return a 2-tuple
subprocess.py:pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
multiprocessing/__init__.py:with os.popen(comm) as p:
pipes.py:for the built-in function open() or for os.popen().
pipes.py:return os.popen(cmd, 'r')
pipes.py:return os.popen(cmd, 'w')
ctypes/util.py:f = os.popen(cmd)
ctypes/util.py:with contextlib.closing(os.popen(cmd)) as f:
ctypes/util.py:f = os.popen(cmd)
ctypes/util.py:with contextlib.closing(os.popen(cmd)) as f:
ctypes/util.py:with contextlib.closing(os.popen('/sbin/ldconfig -r 
2>/dev/null')) as f:
ctypes/util.py:with contextlib.closing(os.popen('LC_ALL=C LANG=C 
/sbin/ldconfig -p 2>/dev/null')) as f:
distutils/command/bdist_rpm.py:out = os.popen(q_cmd)
distutils/emxccompiler.py:out = os.popen(gcc_exe + ' -dumpversion','r')

--
components: Library (Lib)
messages: 167663
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: usage of os.popen in standard library
versions: Python 3.2

___
Python tracker 

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

[issue15585] usage of os.popen in standard library

[Ramchandra Apte]

Ramchandra Apte added the comment:

Sorry, os.py:# Supply os.popen() should not be in the list.

--

___
Python tracker 

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

[issue15577] Real argc and argv in embedded interpreter

[Ramchandra Apte]

Changes by Ramchandra Apte :


--
title: Real Argc Argv in embedded interpreter -> Real argc and argv in embedded 
interpreter

___
Python tracker 

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

[issue15580] fix True/False/None reST markup

[Georg Brandl]

Georg Brandl added the comment:

Agreed with David.

--
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue15424] __sizeof__ of array should include size of items

[Georg Brandl]

Georg Brandl added the comment:

LGTM.

--

___
Python tracker 

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

[issue15580] fix True/False/None reST markup

[Chris Jerdonek]

Chris Jerdonek added the comment:

Yes, I can see the trade off.  However, is there a sense in which the situation 
for documentation could be different from the situation for code?

With code, style and refactoring changes cause churn without directly 
benefiting the end user (because code is just a means and not the end).  We can 
hold off on refactoring without impacting the end user.

With documentation though, these are visible, albeit small changes that will 
directly improve the user's experience.  We would be holding off on improving 
the pages for the sake of internal churn.  (If it was refactoring reST in a way 
that didn't change the HTML output, it would be a different story.)

--

___
Python tracker 

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

[issue14182] collections.Counter equality test thrown-off by zero counts

[Stephen Webber]

Stephen Webber added the comment:

Hmm, that is odd behavior indeed.

I think having keys that point to zero values is important for iterating over a 
set. For example:

>>> x = Counter(a=10, b=0)
>>> for k in set(x):
... x[k] += 1
... 
>>> x
Counter({'a': 11, 'b': 1})

is probably preferable to

>>> x = Counter(a=10, b=0)
>>> for k in set(x):
... x[k] += 1
... 
>>> x
Counter({'a': 11})

Perhaps to ensure intuitive behavior we could ensure that

>>> Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0)
True

by aggregating all keys into the new Counter object, even those with zero 
values? I would be happy to make such a patch, as it would be good experience 
for me to learn. Would this be an acceptable solution, and is there other odd 
behavior at work here?

--

___
Python tracker 

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

[issue15580] fix True/False/None reST markup

[Georg Brandl]

Georg Brandl added the comment:

We have to draw the line somewhere.  Otherwise there will be dozens of issues 
like this, introducing potential breakage and costing developer time that can 
better be spent elsewhere.

The rule in the devguide is mostly there so that developers don't bother 
writing more than they have to (since None/True/False occur so often typing the 
link every time will feel painful after a few times).  If the link is already 
written, it does absolutely no harm, as David said.  Therefore, there is no 
actual improvement as you claim.

This is nothing against you and your efforts, Chris -- you've already helped 
improve the docs quite a lot.

--

___
Python tracker 

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

[issue15586] Provide some examples for usage of ElementTree methods/attributes

[Ezio Melotti]

Changes by Ezio Melotti :


--
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

___
Python tracker 

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

[issue15586] Provide some examples for usage of ElementTree methods/attributes

[Sarbjit singh]

New submission from Sarbjit singh:

Please provide some basic usage examples for ElementTree module documentation. 
While parsing an xml, most common scenarios will be reading elements from xml, 
modifying elements, removal of elements. Though there are few examples given 
for modification of xml element. 

But if you look from beginners learning point of view, its very hard to just 
get any idea from the example that is currently provided. There is lot of text 
there, but what would be more helpful is some small examples for each function 
so that user can quickly understand its usage there only.  I myself is learning 
Python, but in order to start using this module, i had to search lot of 
articles on internet on usage of this module. If we could have provided some 
basic use cases in Python doc itself, user would not have to rely on external 
sources for learning its usage.

Some Basic Scenarios:
1) Parsing an xml and finding some elements of xml
2) deletion of an element from an xml and writing back
3) Modification of an xml element
4) Usage of XPath queries (some basic usage)

--
assignee: docs@python
components: Documentation
messages: 167670
nosy: Sarbjit.singh, docs@python, eli.bendersky
priority: normal
severity: normal
status: open
title: Provide some examples for usage of ElementTree methods/attributes
type: enhancement

___
Python tracker 

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