[issue6489] Documentation of ElementTree.Element.getiterator implies element will always be included

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee: georg.brandl -> effbot
nosy: +effbot
priority:  -> low

___
Python tracker 

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

[issue6489] Documentation of ElementTree.Element.getiterator implies element will always be included

[Mitchell Model]

New submission from Mitchell Model :

Documentation of ElementTree.Element.getiterator implies element will
always be included, but it is only included if it matches. (It says
"creates a tree iterator with the current element as the root" and also
says, ambiguously, "iterates over this element and all the elements
below it that match the given tag".)

I also feel that it is unclear to leave the term "match" undescribed.
Especially with '*' explicitly mentioned as a possibility, it looks like
one could specify, say, 'Thing*' and get all elements whose tag names
begin with 'Thing', which does not appear to be the case. Also, using
the term "match" is confusing if one understands the term to mean match
an XPath, as (implicitly) used elsewhere in the document, unless match
also means an XPath here too, which I don't think it does. I think
"match" should be reserved for XPath matching in this documentation, and
"equals" for when that is the actual test performed, such as, I think,
in getiterator.

--
assignee: georg.brandl
components: Documentation
messages: 90529
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Documentation of ElementTree.Element.getiterator implies element will 
always be included
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6488] ElementTree documentation refers to "path" with no explanation, and inconsistently

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee: georg.brandl -> effbot
nosy: +effbot
priority:  -> low

___
Python tracker 

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

[issue6488] ElementTree documentation refers to "path" with no explanation, and inconsistently

[Mitchell Model]

New submission from Mitchell Model :

The documentation of ElementTree mentions "path" in describing the
arguments to certain methods. However, "path" is never defined. I
realize that a "path" is (at least a partial implementation of) an
XPath, but there's nothing in the documentation to suggest that to
someone who is not aware of XPath. I also realize that there is a
reference to the external ElementTree documentation, and that
ElementTree support for XPath is documented there. I think "path" should
at least be clarified with a reference that says something like "As used
here the term 'path' refers to ElementTree's support for the XML Path
Language (XPath); see
see http://effbot.org/zone/element-xpath.htm fordetails"

Next, a swarm of nits:

The documentation of the Element methods find, findall, and findtext say
that their arguments can be a tag name or path. (Using the same wording,
which makes it strange that the argument to findtext is called
"condition" while the argument to the other two methods are called
"match". I'm sure there's something important about this distinction,
but I can't figure it out from the documentation.

The documentation of the corresponding methods of ElementTree call the
arguments "path", rather than "tag" or "condition". The real problem is
that these methods are documented with respect to the element(s) "with
the given tag". [The "the" is missing from the documentation of
ElementTree.find and findall.] The documentation says these methods are
the same as calling the corresponding method on getroot(), but whereas
the Element methods refer to tag name or path, the ElementTree methods,
although they call their arguments "path", only mention tag names.
Finally, the ElementTree methods say "path is the [top-level] element to
look for", which, it seems to me, is redundant given the first sentence
of each of each method's documentation.

--
assignee: georg.brandl
components: Documentation
messages: 90528
nosy: MLModel, georg.brandl
severity: normal
status: open
title: ElementTree documentation refers to "path" with no explanation, and 
inconsistently
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6486] Library doc introduction strangely points to "Built-in Objects" as a starting point

[Ezio Melotti]

Ezio Melotti  added the comment:

I agree, the built-in functions page [1] is a good place where to start
and indeed it's the page that follows the introduction [2].
The built-in object page/section [3] should be probably
included/integrated with one of the other pages (and possibly rephrased
too - it's not immediately clear what this "symbol table" is. If it
refers to the __builtins__ namespace it should be stated clearly,
possibly pointing to a glossary entry or to another section).

[1]: http://docs.python.org/library/functions.html
[2]: http://docs.python.org/library/intro.html
[3]: http://docs.python.org/library/objects.html

--
nosy: +ezio.melotti
priority:  -> normal

___
Python tracker 

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

[issue3341] "Suggest a change" link

[Ezio Melotti]

Ezio Melotti  added the comment:

An easier approach would be to open the "create a new issue" page of the
tracker when the user clicks on "suggest a change".
The title can be set automatically to something like "Doc suggestion on
Page XYZ". The "Documentation" component and the version could be set
automatically too, and the "Comment" field could include a link to the page.
If the user is registered to the tracker, he would just have to write
the comment and submit, possibly changing/adjusting the fields.

I don't know if it's actually possible to do something like this, but it
shouldn't be too hard to hack the tracker in order to pass this
information when the users click on the link.

--
nosy: +ajaksu2, ezio.melotti
priority:  -> low

___
Python tracker 

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

[issue6487] Some index entries appear in black

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
assignee:  -> georg.brandl
nosy: +georg.brandl

___
Python tracker 

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

[issue6487] Some index entries appear in black

[Mitchell Model]

New submission from Mitchell Model :

Some index entries appear in black. I think this happens only with
top-level entries. I can't find any pattern to which ones are in black,
so it doesn't look like black has any actual significance. The C general
index page is rich with examples.

--
messages: 90525
nosy: MLModel
severity: normal
status: open
title: Some index entries appear in black
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue6486] Library doc introduction strangely points to "Built-in Objects" as a starting point

[Mitchell Model]

New submission from Mitchell Model :

At the end of the introduction page of the library documentation  there
is a strange suggestion to begin with "Built-in Objects" as a starting
point. The "Built-in Objects" page consists of two paragraphs that will
surely mystify people new to Python. I'm not sure where it was supposed
to point -- built-in functions? built-in types? But surely not "Built-in
Objects"?

Or another interpretation, which on deeper investigation, strikes me as
the correct one: "Built-in Objects", which references tables, operators,
etc. that don't appear on that page, is simply an introduction to
"Built-in Types", or an introduction to all the subsequent chapters. In
that case, I see the challenge for structuring the top-level chapters of
the library documentation, but perhaps these two paragraphs could simply
be moved to the introduction and the "Built-in Objects" eliminated.
Besides, aren't built-in functions and constants, which come before this
page, built-in objects too?

--
assignee: georg.brandl
components: Documentation
messages: 90524
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Library doc introduction strangely points to "Built-in Objects" as a 
starting point
versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2

___
Python tracker 

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

[issue5210] zlib does not indicate end of compressed stream properly

[Ezio Melotti]

Ezio Melotti  added the comment:

Thanks for the patch!
Can you provide tests too?

--
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 2.7, Python 3.2 -Python 3.0

___
Python tracker 

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

[issue6485] is_finished not exported by zlib

[Ezio Melotti]

Changes by Ezio Melotti :


--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> zlib does not indicate end of compressed stream properly

___
Python tracker 

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

[issue6485] is_finished not exported by zlib

[Jean-Paul Calderone]

Jean-Paul Calderone  added the comment:

This is a duplicate of #5210, which has a patch attached.

--
nosy: +exarkun

___
Python tracker 

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

[issue6485] is_finished not exported by zlib

[Travis H.]

New submission from Travis H. :

The zlib C library has the capability to indicate the end of a
compressed stream by returning a Z_STREAM_END from a call to inflate.

This allows uncompressed data to follow some compressed data.  It is
necessary to know when the end of the compressed stream has been reached
so that one can query the "unused_data" attribute.

However, there is no way for python to know that the end of a compressed
stream has been reached.

I will shortly be submitting a small patch that creates a python integer
attribute called "is_finished" which evaluates to 1 when the end of a
compressed stream has been reached.

--
components: Extension Modules
messages: 90521
nosy: solinym
severity: normal
status: open
title: is_finished not exported by zlib
versions: Python 2.6

___
Python tracker 

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

[issue6480] code.runsource() parsing bug

[Sean]

Sean  added the comment:

Seems to me it's probably an issue with the newlines, but from
help(code.compile_command):

Compile a command and determine whether it is incomplete.

Arguments:

source -- the source string; may contain \n characters
filename -- optional filename from which source was read; default
""
symbol -- optional grammar start symbol; "single" (default) or

--

___
Python tracker 

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

[issue6484] No unit test for mailcap module

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Please also identify yourself with your full name.

--
nosy: +loewis

___
Python tracker 

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

[issue6449] Improve/update python.org/dev/

[Ezio Melotti]

Ezio Melotti  added the comment:

Thanks for taking care of it.
There's also a typo ("thissmall") in the first line of
http://www.python.org/dev/faq/#why-should-i-use-svn-switch

--

___
Python tracker 

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

[issue6484] No unit test for mailcap module

[R. David Murray]

R. David Murray  added the comment:

Welcome!

Please read the material at http://www.python.org/dev if you haven't
already, especially the dev FAQ.  At the moment the case can't be
assigned to you in the tracker interface, but your claiming it in the
text is sufficient.

Please write the tests and create a diff-patch as outlined in the FAQ. 
Then upload it here for review.  If you need advice, #python-dev on
Freenode is a good place to get it.

--
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed

___
Python tracker 

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

[issue6484] No unit test for mailcap module

[Greg]

New submission from Greg :

There is currently no test_mailcap or any other standalone unit test for
the mailcap module. The only existing test is a self-test at the end of
the module.

I would like to be assigned to work on this patch.

(Why am I assigning myself to write tests for a small, older module? I'm
a complete noob to the Python-Dev community and I'm getting my feet wet
with this. Let me know if you have any advice or if I'm doing something
wrong.)

--
components: Tests
messages: 90516
nosy: gnofi
severity: normal
status: open
title: No unit test for mailcap module
type: feature request
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

[issue6418] unittest.TestProgram change breaks nose

[Michael Foord]

Michael Foord  added the comment:

Committed to trunk in revision 74007.

--
assignee:  -> michael.foord
resolution:  -> accepted
status: open -> closed

___
Python tracker 

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

[issue5672] Implement a way to change the python process name

[Floris Bruynooghe]

Changes by Floris Bruynooghe :


--
nosy: +flub

___
Python tracker 

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

[issue6483] Modules are not deallocated correctly if m_size = -1

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> loewis
nosy: +loewis

___
Python tracker 

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

[issue6483] Modules are not deallocated correctly if m_size = -1

[Julian Andres Klode]

New submission from Julian Andres Klode :

The documentation states that m_size should be -1 if no additional
memory is needed. But this causes the objects inside the module to not
be deallocated at all.

The attached module (test) stores an object of a type 'Test', which
prints "Deallocation is happening" in it's tp_dealloc. If m_size in the
TestModule is set to -1, this is never reached. If it is 0, it is reached.

--
components: Interpreter Core
files: test.c
messages: 90514
nosy: jak
severity: normal
status: open
title: Modules are not deallocated correctly if m_size = -1
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file14500/test.c

___
Python tracker 

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