From report at bugs.python.org  Sat Jan  1 00:34:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 23:34:40 +0000
Subject: [docs] [issue10787] [random.gammavariate] Add the expression of
	the	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293838480.78.0.794511656666.issue10787@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>From reading the Wikipedia article, I might conclude that beta = 1/theta, but from reading random.py, beta=theta. I think this much should be clarified, but without giving the formula in a hard to read text form. Perhaps the random doc should give reference to the much more complete numpy.random (and Wikipedia and/or Mathworld) entries rather than merely 'any statistics text' (many of which will not describe all).

----------
nosy: +terry.reedy
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10787>
_______________________________________

From report at bugs.python.org  Sat Jan  1 01:37:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 00:37:41 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293842261.45.0.624055406573.issue10789@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since threading is written in Python, one might expect Lock to be written in Python and its methods to accept keywords. However, threading.py (3.2) has
  _acquire_lock = _thread.acquire_lock
  Lock = _aquire_lock
so threading.Lock objects are C-coded _thread.lock objects and hence *might* not accept keyword args.

In 3.1:
lock.acquire([waitflag]) # same 2.7
Lock.acquire(blocking=True) # [blocking=1] in 2.7
Indeed the first is correct.

>>> from threading import Lock
>>> l=Lock()
>>> l.acquire(blocking=True)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    l.acquire(blocking=True)
TypeError: acquire() takes no keyword arguments
>>> l.acquire(True)
True

r87596, r87596

In 3.2:
lock.acquire(waitflag=1, timeout=-1) 
Lock.acquire(blocking=True, timeout=-1)
The edit in 3.2 is actually correct 

>>> from threading import Lock
>>> l=Lock()
>>> l.acquire(blocking=True)
True
>>> l.acquire(timeout=1)
False

_thread.lock.acquire now accepts keywords.

----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Sat Jan  1 01:59:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 01 Jan 2011 00:59:58 +0000
Subject: [docs] [issue9370] Add reader redirect from test package docs to
	unittest	module
In-Reply-To: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>
Message-ID: <1293843598.89.0.0766859295765.issue9370@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, I think I wrote this issue based on the diff that added the new note at the top, rather than looking at the existing intro text that already references unittest and doctest.

No need to change anything after all.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9370>
_______________________________________

From report at bugs.python.org  Sat Jan  1 12:33:48 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 01 Jan 2011 11:33:48 +0000
Subject: [docs] [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1293881628.22.0.198995502027.issue8626@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

That's interesting: do we have a place where we explain how to read the doc? I mean, a place were we can provide example/explain how we write docs, so f.e.:

  str.rsplit([sep[, maxsplit]])  

is a description for a method that could accept 2 optional arguments, none of them keyargs or

  str.encode(encoding="utf-8", errors="strict")

is a description for a method that could take 2 optional args, and they are also keyargs (yeah, I know it's kinda bad-worded, but just to give the idea).

If you think it's overkill, let's just close this bug (after all, we have all the doc written our way ;)).

Cheers,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8626>
_______________________________________

From report at bugs.python.org  Sat Jan  1 18:07:35 2011
From: report at bugs.python.org (David Kremer)
Date: Sat, 01 Jan 2011 17:07:35 +0000
Subject: [docs] [issue10787] [random.gammavariate] Add the expression of
	the	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293901655.08.0.506373781301.issue10787@psf.upfronthosting.co.za>


David Kremer <david.kremer.dk at gmail.com> added the comment:

Yes I agree. Actually the parameters in the python code alpha, beta are corresponding respectively to k, theta in the first equation of [http://en.wikipedia.org/wiki/Gamma_distribution].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10787>
_______________________________________

From report at bugs.python.org  Sat Jan  1 18:52:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 01 Jan 2011 17:52:22 +0000
Subject: [docs] [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1293904342.23.0.658929935891.issue8626@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The description for the function directive is at http://docs.python.org/dev/documenting/markup.html  However, I?m not sure whether the doc is accurate, since there was a switch from spam([style]) to spam(style=None) some time ago, for example in r73291.

Let?s continue the discussion on the other bug.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Document lack of support for keyword arguments in C functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8626>
_______________________________________

From report at bugs.python.org  Sat Jan  1 19:01:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 01 Jan 2011 18:01:44 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293904904.38.0.978898695015.issue10789@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this commit should be reverted:  Arguments with default values no longer use brackets, see for example r73291.  More info on #8350.

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Sat Jan  1 19:21:47 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 18:21:47 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293906107.6.0.891329430459.issue10789@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, that's not true.  Arguments that can't be given as kwargs are presented with brackets.

However, the default value now isn't indicated anywhere; it should be added to the main text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Sat Jan  1 22:31:38 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Jan 2011 21:31:38 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293917498.3.0.576268153405.issue10789@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

OK, I will add defaults in the texts and condense them a bit at the same time. Will post patches for review.

"Arguments that can't be given as kwargs are presented with brackets."
I think this should be stated in the introduction to the Lib manual, along with any other conventions a reader should know. If you agree, one of us can open an issue for this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Sun Jan  2 00:59:45 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 01 Jan 2011 23:59:45 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926385.15.0.881737245563.issue8350@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, it may indeed be the best option to add a new directive option to say "this function does not take keyword args".  It would result in some form of unobtrusive but noticeable output in HTML.

It is a bit of an effort to add it everywhere it's necessary, but the most important instances (e.g. string methods) can be covered quickly, and it's fairly easy to grep the other instances (namely, grepping for METH_O and METH_VARARGS without METH_KEYWORDS).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun Jan  2 01:01:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Jan 2011 00:01:13 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1293926385.15.0.881737245563.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926467.3701.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hmm, it may indeed be the best option to add a new directive option to
> say "this function does not take keyword args".  It would result in
> some form of unobtrusive but noticeable output in HTML.

Isn't it kind of a CPython-specific detail, though?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun Jan  2 01:03:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 00:03:44 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926624.39.0.129138863842.issue8350@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes.  It's still an important detail; the explanation could say, "In CPython, this function does not take keyword args" and furthermore it's not really clear to me how much of the library reference applies to all Python implementations anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun Jan  2 01:08:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Jan 2011 00:08:58 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293926938.36.0.888630162651.issue8350@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is an implementation detail specific to CPython and subject to change.  I'm -1 on documenting it for every function/method and thereby making it part of the language spec. We've lived without this spec for almost twenty years, so I'm inclined to think it is truly unimportant.

It is sufficient to mention just once in the docs that CPython functions/methods sometimes don't take keywords.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun Jan  2 01:51:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 02 Jan 2011 00:51:20 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293929480.52.0.473662913898.issue10789@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the correction Georg.

In msg104113 (on #8350), I quoted http://docs.python.org/dev/reference/expressions#calls :

?An implementation may provide built-in functions whose positional parameters do not have names, even if they are ?named? for the purpose of documentation, and which therefore cannot be supplied by keyword.?

Previous consensus seemed to be that this warning was enough, but recent bugs such as this one show that it does trip up users, so there is further discussion about how best to document this CPython limitation (hence the dependency I?m adding).

----------
dependencies: +Document lack of support for keyword arguments in C functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Sun Jan  2 02:16:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Jan 2011 01:16:49 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293931009.13.0.0888653862015.issue10789@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur that the one warning is enough.  Implementations have been given wide latitude in this regard.  Even within CPython there is not much uniformity -- some funcs/methods don't accept keywords, some will disregard keywords, and others may have keywords that are different from the name in the docs.  

I believe it would be a mistake to make to lock in the present state of accidental implementation details by documenting them in the main docs.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Sun Jan  2 02:52:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Jan 2011 01:52:50 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293933170.17.0.558341957765.issue8350@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think that the warning that things are not always as they seem should be repeated in the front of the library manual where the pseudo-arg names are actual used, so the library manual stands on its own. In any case, I believe a lot of people use the lib ref without reading and remembering every detail of the language ref.

----------
nosy: +terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun Jan  2 03:22:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Jan 2011 02:22:56 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1293934976.62.0.544219256812.issue8350@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If there is no indication in the lib manual as to which parameter names and defaults are real and which are fake, then the safe guideline is to never use keywards for library functions and methods and always pass everything positionally.

Slightly more complicated is to be aware of which classes and modules are Python versus C coded. (If needed, change for module.py in /Lib.) For some modules, one can take a cue from doc examples that use keywords.

Otherwise, each person has to experiment for himself and  check each TypeError messages to determine whether it arises from a misspelling or a hidden limitation. And maybe go through the same process a year later after forgetting.

>"We've lived without this spec for almost twenty years,"
Yes, and people have been stumbling on this and complaining for probably just as long. Since []s are no longer used in the doc to indicate 'optional', they can and are being used to indicate 'position-only'. Specify in the introduction, where notation should be explained, that the limitation is only for current CPython and may be changed in the future or be different for other implementations. However....

In my opinion, the real solution is to remove the limitation. Since the language spec says args can be passed by keyword as well as by position, make it be that way for everything we distribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun Jan  2 03:23:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Jan 2011 02:23:36 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293935016.92.0.573125693841.issue10789@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I responded to the general questions on #8350.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________

From report at bugs.python.org  Sun Jan  2 09:25:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 02 Jan 2011 08:25:24 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in	C	functions
In-Reply-To: <1293926467.3701.0.camel@localhost.localdomain>
Message-ID: <4D203670.9070109@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Isn't it kind of a CPython-specific detail, though?

If other implementations do provide proper keyword arguments,
I'd be skeptical that they all settled on the names that the
library documentation gives to the arguments.

----------
title: Document lack of support for keyword arguments in C functions -> Document lack of support for keyword arguments in C	functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8350>
_______________________________________

From report at bugs.python.org  Sun Jan  2 10:58:25 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 02 Jan 2011 09:58:25 +0000
Subject: [docs] [issue1665333] Documentation missing for OptionGroup class
	in optparse
Message-ID: <1293962305.61.0.142664864609.issue1665333@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Could someone give a look to this patch? I can work on fixing the missing stuff (if any :)).

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Sun Jan  2 15:23:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 14:23:58 +0000
Subject: [docs] [issue1665333] Documentation missing for OptionGroup class
	in optparse
Message-ID: <1293978238.06.0.271526754194.issue1665333@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good, applied in r87627 (after removing stray tabs).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From kristoffer.lundgren at gmail.com  Sun Jan  2 01:43:40 2011
From: kristoffer.lundgren at gmail.com (Kristoffer Lundgren)
Date: Sun, 2 Jan 2011 01:43:40 +0100
Subject: [docs] http://docs.python.org/library/random.html
Message-ID: <AANLkTikAqZn5S8ri=htD14pSw=yBUvVidXwLB7r5KzVJ@mail.gmail.com>

Hi,

I suspect I've found a documentation error in the above mentioned link (
http://docs.python.org/library/random.html); regarding random.randint(a, b),
the documentation says "Return a random integer N such that a <= N <= b",
however when actually using the function, it does seem to be a <= N < b.

Running Python 2.6, the built-in help returns

Type:           builtin_function_or_method
Base Class:     <type 'builtin_function_or_method'>
String Form:    <built-in method randint of mtrand.RandomState object at
0x01466
340>
Namespace:      Interactive
Docstring:
    randint(low, high=None, size=None)
Return random integers from `low` (inclusive) to `high` (exclusive).
Return random integers from the "discrete uniform" distribution in the
"half-open" interval [`low`, `high`). If `high` is None (the default),
then results are from [0, `low`).

which kind of hints that it should be "<".

Best regards
Kristoffer Lundgren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110102/89524aec/attachment.html>

From georg at python.org  Sun Jan  2 17:13:04 2011
From: georg at python.org (Georg Brandl)
Date: Sun, 02 Jan 2011 17:13:04 +0100
Subject: [docs] http://docs.python.org/library/random.html
In-Reply-To: <AANLkTikAqZn5S8ri=htD14pSw=yBUvVidXwLB7r5KzVJ@mail.gmail.com>
References: <AANLkTikAqZn5S8ri=htD14pSw=yBUvVidXwLB7r5KzVJ@mail.gmail.com>
Message-ID: <4D20A410.9010906@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 02.01.2011 01:43, schrieb Kristoffer Lundgren:
> Hi,
>  
> I suspect I've found a documentation error in the above mentioned link
> (http://docs.python.org/library/random.html); regarding random.randint(a, b),
> the documentation says "Return a random integer N such that a <= N <= b",
> however when actually using the function, it does seem to be a <= N < b.
>  
> Running Python 2.6, the built-in help returns
>  
> Type:           builtin_function_or_method
> Base Class:     <type 'builtin_function_or_method'>
> String Form:    <built-in method randint of mtrand.RandomState object at 0x01466
> 340>
> Namespace:      Interactive
> Docstring:
>     randint(low, high=None, size=None)
> Return random integers from `low` (inclusive) to `high` (exclusive).
> Return random integers from the "discrete uniform" distribution in the
> "half-open" interval [`low`, `high`). If `high` is None (the default),
> then results are from [0, `low`).
>  
> which kind of hints that it should be "<".

Hi,

it seems your randint is not Python's randint, but the randint from scipy's
"mtrand" module, which indeed defines randint differently.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0gpBAACgkQN9GcIYhpnLBWnwCgpuR1uO8u6N6PW2BRNQThHbgp
sPgAn3kcTFUKyUOjb5dYN0ico2bePGKh
=4ybp
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sun Jan  2 22:21:24 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 02 Jan 2011 21:21:24 +0000
Subject: [docs] [issue10772] Several actions for argparse arguments missing
	from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1294003284.23.0.637126214999.issue10772@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

action="help" definitely needs to be documented

action="count" probably should be, though I think it's pretty useless (I just copied it from optparse)

action="parsers", nargs="..." and nargs="A..." I'm not so sure about. These are currently kind of implementation details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Sun Jan  2 22:21:32 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Sun, 02 Jan 2011 21:21:32 +0000
Subject: [docs] [issue10809] complex() comments wrongly say it supports NaN
	and inf
In-Reply-To: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>
Message-ID: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>


New submission from Andrew Dalke <dalke at dalkescientific.com>:

complex("nan") raises "ValueError: complex() arg is a malformed string"  while complex(float("nan")) returns (nan+0j). This was reported in http://bugs.python.org/issue2121 with the conclusion "wont fix".

complex("inf") has the same behaviors.

The implementation in complexobject.c says 


    /* a valid complex string usually takes one of the three forms:

         <float>                  - real part only
         <float>j                 - imaginary part only
         <float><signed-float>j   - real and imaginary parts

       where <float> represents any numeric string that's accepted by the
       float constructor (including 'nan', 'inf', 'infinity', etc.), and
       <signed-float> is any string of the form <float> whose first
       character is '+' or '-'.

This comment is wrong and it distracted me for a while as I tried to figure out why complex("nan") wasn't working. It should be fixed, with the word "including" replaced by "excluding".

I don't have a real need for complex("nan") support - this was of intellectual interest only. Also of intellectual interest, PyPy 1.4 does accept complex("nan") but converts complex("nan+nanj") to (nannanj), so it suffers from the strange corner cases which Raymond points out when advocating for "wont fix."

Because

----------
assignee: docs at python
components: Documentation
messages: 125104
nosy: dalke, docs at python
priority: normal
severity: normal
status: open
title: complex() comments wrongly say it supports NaN and inf
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10809>
_______________________________________

From report at bugs.python.org  Mon Jan  3 02:31:44 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 03 Jan 2011 01:31:44 +0000
Subject: [docs] [issue10809] complex() comments wrongly say it supports NaN
	and inf
In-Reply-To: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>
Message-ID: <1294018304.1.0.227364194166.issue10809@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

Well that's ... interesting. While I compiled 2.7 and was looking at the 2.7 code my tests were against 2.6. 


Python 2.7 (trunk:74969:87651M, Jan  2 2011, 21:58:12) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> complex("nan-nanj")
(nan+nanj)
>>> 

This means that the comments are correct and the error was in my understanding, as influenced by issue2121.

I therefore closed this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10809>
_______________________________________

From eliben at gmail.com  Mon Jan  3 07:30:31 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Mon, 3 Jan 2011 08:30:31 +0200
Subject: [docs] http://docs.python.org/library/random.html
In-Reply-To: <AANLkTikAqZn5S8ri=htD14pSw=yBUvVidXwLB7r5KzVJ@mail.gmail.com>
References: <AANLkTikAqZn5S8ri=htD14pSw=yBUvVidXwLB7r5KzVJ@mail.gmail.com>
Message-ID: <AANLkTimT6fw93bjs7nM04zb5xphO4+TehpdeJLaZKciH@mail.gmail.com>

>
>
> I suspect I've found a documentation error in the above mentioned link (
> http://docs.python.org/library/random.html); regarding random.randint(a,
> b), the documentation says "Return a random integer N such that a <= N <=
> b", however when actually using the function, it does seem to be a <= N < b.
>
> Running Python 2.6, the built-in help returns
>
> Type:           builtin_function_or_method
> Base Class:     <type 'builtin_function_or_method'>
> String Form:    <built-in method randint of mtrand.RandomState object at
> 0x01466
> 340>
> Namespace:      Interactive
> Docstring:
>     randint(low, high=None, size=None)
> Return random integers from `low` (inclusive) to `high` (exclusive).
> Return random integers from the "discrete uniform" distribution in the
> "half-open" interval [`low`, `high`). If `high` is None (the default),
> then results are from [0, `low`).
>
>
randint indeed includes both endpoints:

>>> for i in range(10):
...   print random.randint(0, 1)
...
1
1
1
1
0
0
1
0
0
0

Its help string agrees:

>>> help(random.randint)
Help on method randint in module random:

randint(self, a, b) method of random.Random instance
    Return random integer in range [a, b], including both end points.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110103/19e6097c/attachment.html>

From report at bugs.python.org  Mon Jan  3 13:58:07 2011
From: report at bugs.python.org (Carsten Grohmann)
Date: Mon, 03 Jan 2011 12:58:07 +0000
Subject: [docs] [issue10813] Suppress adding decimal point for places=0 in
	moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>


New submission from Carsten Grohmann <carstengrohmann at gmx.de>:

Hi,

the documentation of the decimal module contains a small recipe called moneyfmt() for format decimal values. It's very usefull.

I'd like to suggest a small improvement because the output is incorrect with given dp="." (default) and places=0.

Example:
>>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=1)
'<0.0>'
>>> moneyfmt(decimal.Decimal('-0.02'), neg='<', trailneg='>', places=0)
'<0.>'

Change:
--- moneyfmt.py 2011-01-03 13:56:32.774169788 +0100
+++ moneyfmt.py.new     2011-01-03 13:56:58.130165330 +0100
@@ -33,7 +33,8 @@
         build(trailneg)
     for i in range(places):
         build(next() if digits else '0')
-    build(dp)
+    if places:
+        build(dp)
     if not digits:
         build('0')
     i = 0

What do you think about the change?

Regrads,
Carsten

----------
assignee: docs at python
components: Documentation
messages: 125164
nosy: cgrohmann, docs at python
priority: normal
severity: normal
status: open
title: Suppress adding decimal point for places=0 in moneyfmt()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Mon Jan  3 17:17:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 16:17:21 +0000
Subject: [docs] [issue10818] pydoc: refactorize duplicate DocHandler and
	DocServer	classes
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The pydoc module has two DocHandler classes and two DocServer classes. I think that they can be easily factorized.

DocServer may also use serve_forever()+shutdown() instead of serve_until_quit()+quit flag, to be able to wait the server (with shutdown()).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 125190
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: pydoc: refactorize duplicate DocHandler and DocServer classes
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10818>
_______________________________________

From report at bugs.python.org  Mon Jan  3 17:17:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jan 2011 16:17:49 +0000
Subject: [docs] [issue10818] pydoc: refactorize duplicate DocHandler and
	DocServer	classes
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1294071468.98.0.987096342866.issue10818@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened this issue because I had to fix a bug twice in pydoc: r87687 (fix a ResourceWarning(unclosed socket)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10818>
_______________________________________

From report at bugs.python.org  Mon Jan  3 19:29:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Jan 2011 18:29:18 +0000
Subject: [docs] [issue10813] Suppress adding decimal point for places=0 in
	moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294079358.79.0.610301285398.issue10813@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From alexander.belopolsky at gmail.com  Mon Jan  3 19:35:42 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 3 Jan 2011 13:35:42 -0500
Subject: [docs] tuple or struct_time
Message-ID: <AANLkTi=ujTPHUPrFyUGvZxq+fSKu6JdjB_6Rj0+xb3id@mail.gmail.com>

Functions in the time module that expect broken down time are
currently documented as accepting "tuple or struct_time".  For
example,

http://docs.python.org/py3k/library/time.html#time.strftime

However, in recent versions, ".. or struct_time" is redundant because

>>> issubclass(time.struct_time, tuple)
True

I think it would be more informative for a reader to change "tuple or
struct_time" to "9-tuple".

From georg at python.org  Mon Jan  3 19:40:35 2011
From: georg at python.org (Georg Brandl)
Date: Mon, 03 Jan 2011 19:40:35 +0100
Subject: [docs] tuple or struct_time
In-Reply-To: <AANLkTi=ujTPHUPrFyUGvZxq+fSKu6JdjB_6Rj0+xb3id@mail.gmail.com>
References: <AANLkTi=ujTPHUPrFyUGvZxq+fSKu6JdjB_6Rj0+xb3id@mail.gmail.com>
Message-ID: <4D221823.2030002@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 03.01.2011 19:35, schrieb Alexander Belopolsky:
> Functions in the time module that expect broken down time are
> currently documented as accepting "tuple or struct_time".  For
> example,
> 
> http://docs.python.org/py3k/library/time.html#time.strftime
> 
> However, in recent versions, ".. or struct_time" is redundant because
> 
>>>> issubclass(time.struct_time, tuple)
> True
> 
> I think it would be more informative for a reader to change "tuple or
> struct_time" to "9-tuple".

I don't think so -- the reader may not be aware of that subclass
relationship, and the repr() of struct_time also doesn't make that
clear (which is anyway not its job).  It certainly doesn't hurt to
be a little helpful here.

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0iGCMACgkQN9GcIYhpnLDmKQCePKov8SmLcA1zs1TXXiBNqD+O
A1oAnie+elSLWddJK4HYVx0M9hL2tP0j
=MjyU
-----END PGP SIGNATURE-----

From alexander.belopolsky at gmail.com  Mon Jan  3 19:57:30 2011
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 3 Jan 2011 13:57:30 -0500
Subject: [docs] tuple or struct_time
In-Reply-To: <4D221823.2030002@python.org>
References: <AANLkTi=ujTPHUPrFyUGvZxq+fSKu6JdjB_6Rj0+xb3id@mail.gmail.com>
	<4D221823.2030002@python.org>
Message-ID: <AANLkTikJcddBrTWA9H93O=HLXndWWacXjb-a7HpiW7aj@mail.gmail.com>

On Mon, Jan 3, 2011 at 1:40 PM, Georg Brandl <georg at python.org> wrote:
..
> I don't think so -- the reader may not be aware of that subclass
> relationship, and the repr() of struct_time also doesn't make that
> clear (which is anyway not its job). ?It certainly doesn't hurt to
> be a little helpful here.
>

How far would you go?  We cannot list any possible subclass of tuple:

>>> tm = collections.namedtuple('tm', 'a b c d e f g h i')
>>> time.asctime(tm(*[0]*9))
'Mon Jan  1 00:00:00 2000'

I cannot imagine that someone would want to create a struct_time
instance to pass to time.asctime or time.strftime and it is rather
obvious that these functions should accept what say time.localtime()
produces.  Given that struct_time repr is currently not eval-friendly,
I think the longer a user can get without learning about it, the
happier she will be. :-)

From georg at python.org  Mon Jan  3 19:41:16 2011
From: georg at python.org (Georg Brandl)
Date: Mon, 03 Jan 2011 19:41:16 +0100
Subject: [docs] tuple or struct_time
In-Reply-To: <4D221823.2030002@python.org>
References: <AANLkTi=ujTPHUPrFyUGvZxq+fSKu6JdjB_6Rj0+xb3id@mail.gmail.com>
	<4D221823.2030002@python.org>
Message-ID: <4D22184C.4010302@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 03.01.2011 19:40, schrieb Georg Brandl:
> Am 03.01.2011 19:35, schrieb Alexander Belopolsky:
>> Functions in the time module that expect broken down time are
>> currently documented as accepting "tuple or struct_time".  For
>> example,
> 
>> http://docs.python.org/py3k/library/time.html#time.strftime
> 
>> However, in recent versions, ".. or struct_time" is redundant because
> 
>>>>> issubclass(time.struct_time, tuple)
>> True
> 
>> I think it would be more informative for a reader to change "tuple or
>> struct_time" to "9-tuple".
> 
> I don't think so -- the reader may not be aware of that subclass
> relationship, and the repr() of struct_time also doesn't make that
> clear (which is anyway not its job).  It certainly doesn't hurt to
> be a little helpful here.

Ah -- changing tuple to 9-tuple is fine of course.

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEUEARECAAYFAk0iGEwACgkQN9GcIYhpnLBizwCglhL2y1DrZzGoucxxjv9/vOFi
8eIAmPuPwKfwEOHdBBGnBTEF8sQtGQI=
=mYM5
-----END PGP SIGNATURE-----

From report at bugs.python.org  Mon Jan  3 22:01:18 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Jan 2011 21:01:18 +0000
Subject: [docs] [issue10809] complex() comments wrongly say it supports NaN
	and inf
In-Reply-To: <1294003292.33.0.779224851357.issue10809@psf.upfronthosting.co.za>
Message-ID: <1294088478.32.0.55748422424.issue10809@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10809>
_______________________________________

From report at bugs.python.org  Tue Jan  4 02:03:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Jan 2011 01:03:42 +0000
Subject: [docs] [issue10001] ~Py_buffer.obj field is undocumented,
	though not hidden
In-Reply-To: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>
Message-ID: <1294103022.53.0.110824813833.issue10001@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10001>
_______________________________________

From report at bugs.python.org  Tue Jan  4 15:56:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 04 Jan 2011 14:56:26 +0000
Subject: [docs] [issue10001] ~Py_buffer.obj field is undocumented,
	though not hidden
In-Reply-To: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>
Message-ID: <1294152986.17.0.101948520227.issue10001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Closing as a dupe of 10181, but transferring Lenard's comments over there.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Problems with Py_buffer management in memoryobject.c (and elsewhere?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10001>
_______________________________________

From report at bugs.python.org  Tue Jan  4 20:18:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 04 Jan 2011 19:18:38 +0000
Subject: [docs] [issue9738] Document the encoding of functions bytes
	arguments of the	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1294168718.02.0.32371139578.issue9738@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor,

Here is an interesting case for your collection: PyDict_GetItemString.  Note that it is documented as not setting error, but in fact it may if encoding fails.  This rarely an issue because most uses of PyDict_GetItemString are with an ASCII string literal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:32:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 00:32:18 +0000
Subject: [docs] [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The docs for "s*" and friends should mention that contiguity of the buffer is automatically enforced.

----------
assignee: docs at python
components: Documentation
messages: 125488
nosy: docs at python, exarkun, mark.dickinson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pyarg_parsetuple docs and py_buffer
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:33:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:33:08 +0000
Subject: [docs] [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294273988.0.0.553587330774.issue10840@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:35:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:35:53 +0000
Subject: [docs] [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294274153.1.0.720018261144.issue10840@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8991.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:36:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:36:49 +0000
Subject: [docs] [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294274209.22.0.797938303688.issue10840@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #8215.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 01:44:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jan 2011 00:44:43 +0000
Subject: [docs] [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294274683.55.0.453917649776.issue10840@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah ok, now I remember the story. I cleaned up getargs.c recently. r83197 (#8991) removes the support of discontinious buffers. I guess that most developers don't know what a discontinious buffer is and so they don't support this kind of buffer. Moreover, most PyArg_Parse*() formats don't provide information about the buffer (how it is stored in memory), and so the caller cannot handle discontinious anyway.

I think that even Python code developers don't know what a discontinious buffer is... I think that today there is just no program or library using Python discontinious buffer. And maybe the authors of the PEP forgot it too :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 06:42:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Jan 2011 05:42:54 +0000
Subject: [docs] [issue10813] Suppress adding decimal point for places=0 in
	moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294292574.84.0.285281580082.issue10813@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think I prefer the code as-is.  If you need to blank out the decimal point, set dp to the empty string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Thu Jan  6 08:22:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 07:22:02 +0000
Subject: [docs] [issue10840] pyarg_parsetuple docs and py_buffer
In-Reply-To: <1294273938.78.0.510835761549.issue10840@psf.upfronthosting.co.za>
Message-ID: <1294298522.3.0.0123027788531.issue10840@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done in 3.2 and 3.1. For 2.7 the structure of the doc page would lead to too much repetition IMO.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10840>
_______________________________________

From report at bugs.python.org  Thu Jan  6 17:40:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Jan 2011 16:40:52 +0000
Subject: [docs] [issue6269] threading documentation makes no mention of the
	GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1294332052.54.0.22079259565.issue6269@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, done in r87792, r87793 and r87794, thank you.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:15:47 2011
From: report at bugs.python.org (Vladimir Rutsky)
Date: Thu, 06 Jan 2011 19:15:47 +0000
Subject: [docs] [issue10846] typo in threading doc's: "size of the resource
	size"
In-Reply-To: <1294341347.62.0.125412301486.issue10846@psf.upfronthosting.co.za>
Message-ID: <1294341347.62.0.125412301486.issue10846@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky <altsysrq at gmail.com>:

I think there is a typo in threading documentation:
> In any situation where the size of the resource size is fixed, 
> you should use a bounded semaphore.
 - "size of the resource size", see attached patch for proposed fix.

(Based on official http://svn.python.org/projects/python/branches/py3k/ repository.)

----------
assignee: docs at python
components: Documentation
files: threading_typo_size_of_size.patch
keywords: patch
messages: 125580
nosy: docs at python, rutsky
priority: normal
severity: normal
status: open
title: typo in threading doc's: "size of the resource size"
versions: Python 3.3
Added file: http://bugs.python.org/file20293/threading_typo_size_of_size.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10846>
_______________________________________

From report at bugs.python.org  Thu Jan  6 20:28:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Jan 2011 19:28:25 +0000
Subject: [docs] [issue10846] typo in threading doc's: "size of the resource
	size"
In-Reply-To: <1294341347.62.0.125412301486.issue10846@psf.upfronthosting.co.za>
Message-ID: <1294342105.26.0.715954419883.issue10846@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r87807.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10846>
_______________________________________

From report at bugs.python.org  Fri Jan  7 07:49:50 2011
From: report at bugs.python.org (Carsten Grohmann)
Date: Fri, 07 Jan 2011 06:49:50 +0000
Subject: [docs] [issue10813] Suppress adding decimal point for places=0 in
	moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294382990.2.0.624045018816.issue10813@psf.upfronthosting.co.za>


Carsten Grohmann <carstengrohmann at gmx.de> added the comment:

Setting dp to an empty string is only a workaround from my perspective.

I get the value of the places parameter from a configuration instance and have to implement an additional check "places == 0" every time I call the original moneyfmt(). To reduce this effort I've changed my moneyfmt() function and applied the patch above.

I see only a valuable posibilities from my perspective: apply the patch. Because it would simplify life a little bit :-)

At end it's up to you because the current documentation stated "dp: ... only specify as blank when places is zero".

Regards,
Carsten

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Fri Jan  7 11:11:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 10:11:51 +0000
Subject: [docs] [issue10813] Suppress adding decimal point for places=0 in
	moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294395111.18.0.060130339647.issue10813@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Fri Jan  7 17:23:48 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 16:23:48 +0000
Subject: [docs] [issue10856] documentation for ImportError parameters and
	attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Need documentation for ImportError parameters and exception instance attributes.

----------
assignee: docs at python
components: Documentation
messages: 125655
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: documentation for ImportError parameters and attributes
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 18:43:46 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 17:43:46 +0000
Subject: [docs] [issue10856] documentation for ImportError parameters and
	attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294422226.1.0.476435349909.issue10856@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

What is there to document?  ImportError has no special attributes or parameters.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From youcheng.t.lin at gmail.com  Fri Jan  7 17:27:03 2011
From: youcheng.t.lin at gmail.com (Youcheng Lin)
Date: Fri, 7 Jan 2011 10:27:03 -0600
Subject: [docs] A probable bug in The Python Tutorial
Message-ID: <AANLkTi=bWG9zxtVkXTJL=7KfpJ7vPkPCuXq5=y-ps0d-@mail.gmail.com>

Hi,

In the section
3.2. First Steps Towards Programming

This example introduces several new features.

   -

   The first line contains a *multiple assignment*: the variables a
and b simultaneously
   get the new values 0 and 1. On the last line this is used again,
   demonstrating that the expressions on the right-hand side are all evaluated
   first before any of the assignments take place. The right-hand side
   expressions are evaluated from the* left to the right.*

   *
   *

   I think the red underscored part should be *right to the left*




-- 
Sincerely,

Youcheng Lin

Email:  youcheng.t.lin at gmail.com
Cellphone:  312.823.0653

________________________________________________________________
________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110107/60504c2c/attachment.html>

From sromero at sromero.org  Fri Jan  7 17:46:03 2011
From: sromero at sromero.org (Santiago Romero)
Date: Fri, 7 Jan 2011 17:46:03 +0100
Subject: [docs] Docs in epub or single-html (without the left menu) format
Message-ID: <AANLkTikE+Ezaw1uKb_JVKs64-c+0nXR=Q6C=2ddRUA-V@mail.gmail.com>

 Hi all.

 First of all, sorry for my poor english.

 I've recently purchased a nice 9 inches e-ink ebook reader and I wanted to
read all python 2.7 documentation by using it, but I've been unable to found
python.org's documents in .epub format. PDF is not usable in ebook readers
because is intended for printing and the "blank" page margins make the
documents almost unreadable.

 On other websites/projects, when I can't find a document in epub format, I
usually download and use the "single html" versions. Unfortunatelly, python
html documentation includes a "left menu" that takes almost 35-40% of the
reading space in my ebook.

 Are the docs going to be "converted" (if possible) to epub or is there a
way to get a single-html version without the left menu?

 Thanks a lot.

-- 
Santiago Romero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110107/aabb83a6/attachment.html>

From report at bugs.python.org  Fri Jan  7 19:09:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 18:09:30 +0000
Subject: [docs] [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Reading library source code will only be enlightening to expert users, since most modules are not academic but real-world implementations, with all the complications it entails. Therefore, putting a link at the top of module sections is only confusing for most people. I would like to shift these links to the bottom of doc pages, where we already have "see also" links to RFCs and the like.

----------
assignee: docs at python
components: Documentation
messages: 125669
nosy: docs at python, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: Make source code links less proeminent
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:19:09 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 07 Jan 2011 18:19:09 +0000
Subject: [docs] [issue10856] documentation for ImportError parameters and
	attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294424349.55.0.916313024677.issue10856@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

ImportError has args and message attributes containing failed module name.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:23:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 18:23:25 +0000
Subject: [docs] [issue10856] documentation for ImportError parameters and
	attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294424605.47.0.860492938967.issue10856@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No it doesn't.  It has an arbitrary message string.  That's the same as all other exceptions that don't have special attributes.

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 19:30:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 07 Jan 2011 18:30:51 +0000
Subject: [docs] [issue10856] documentation for ImportError parameters and
	attributes
In-Reply-To: <1294417428.74.0.78747071216.issue10856@psf.upfronthosting.co.za>
Message-ID: <1294425051.49.0.613182325099.issue10856@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You are right, however, that the "args" argument is not really well documented.  Fixed that in r87820.

----------
resolution: works for me -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10856>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:37:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 19:37:32 +0000
Subject: [docs] [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294429052.98.0.809602115334.issue10858@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:40:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Jan 2011 19:40:10 +0000
Subject: [docs] [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294429210.14.0.148028461308.issue10858@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

+1

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:51:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jan 2011 19:51:39 +0000
Subject: [docs] [issue10858] Make source code links less proeminent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294429899.15.0.256101038794.issue10858@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Please leave these alone for the time being. I put them high on the page so that people would have a consistent and easy to find view-source link.  It is an experiment and time will tell whether it was a good choice.  For the time being, I don't want it buried.  

The goal is to reacquaint people with the source as an adjunct to the docs.  The phrase use-the-source-luke used to be common in the python community but now many devs don't seem to be able to readily access the source (with it tucked away in a library directory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 20:56:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 19:56:47 +0000
Subject: [docs] [issue10858] Make source code links less proeminent
In-Reply-To: <1294429899.15.0.256101038794.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294430201.3823.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The goal is to reacquaint people with the source as an adjunct to the
> docs.  The phrase use-the-source-luke used to be common in the python
> community but now many devs don't seem to be able to readily access
> the source (with it tucked away in a library directory).

I don't think someone "not able to readily access the source" from a
link at the *bottom* of a doc page would be able to understand (or even
be motivated to understand) the stdlib's source code.

While I understand the motivation to encourage reading of the source
code, this should not disrupt the sequential reading of documentation
pages, or make it seem more important than the API docs themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 21:02:51 2011
From: report at bugs.python.org (Jose-Luis Fernandez-Barros)
Date: Fri, 07 Jan 2011 20:02:51 +0000
Subject: [docs] [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>


New submission from Jose-Luis Fernandez-Barros <jlfbarros at gmail.com>:

On "The Python Tutorial", section 10.9. Data Compression
  http://docs.python.org/py3k/tutorial/stdlib.html#data-compression

>>> import zlib
>>> s = 'witch which has which witches wrist watch'
...
>>> t = zlib.compress(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be bytes or buffer, not str

Possible solution (sorry, newbie) are:
>>> s = b'witch which has which witches wrist watch'
or
>>> s = 'witch which has which witches wrist watch'.encode("utf-8")


At "The Python Standard Library", secction 12. Data Compression and Archiving
  http://docs.python.org/py3k/library/zlib.html#module-zlib
apparently example is correct:
  zlib.compress(string[, level])

----------
assignee: docs at python
components: Documentation
messages: 125702
nosy: docs at python, joseluisfb
priority: normal
severity: normal
status: open
title: zlib.compress() fails with string
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:18:00 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 21:18:00 +0000
Subject: [docs] [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294435080.29.0.970097612809.issue10858@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As Raymond explained, he added these links as a kind of social experiment and this issue itself shows that it works. :-)

I have a few suggestions on how to make these links more useful:

1. A ViewVC link is the simplest solution to present the source, but the way it presents the source code looks foreign to sphinx docs.  It would be better if the source was formatted similarly to the source examples embedded in doc pages.

2. It would be great to have at least module names hyperlinked in the source views to aid code navigation.

3. I would rather see source links appear consistently for each module and not just for an ad-hoc selection.

4. The side bar already has a "Show Source" link which takes to the reST source of the page.  I don't think this is very useful.  Maybe this link should point to the Python source or a separate "python source" link should appear next to it.

----------
nosy: +belopolsky
title: Make source code links less proeminent -> Make source code links less prominent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:30:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Jan 2011 21:30:56 +0000
Subject: [docs] [issue10858] Make source code links less prominent
In-Reply-To: <1294435080.29.0.970097612809.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294435848.3823.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have a few suggestions on how to make these links more useful:

The question is not how they could be more useful, but *whether* they
are useful at all. An user skilled enough to read the source code is
probably skilled enough not to require a prominently displayed link at
the top of each doc page.

I agree that visual appearance of the ViewVC pages could be better but
that's a separate issue altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:32:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 Jan 2011 21:32:23 +0000
Subject: [docs] [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294435943.46.0.999211081532.issue10858@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1: I hope this will just be a matter of using the same Pygments theme in Sphinx and hgweb.

2: I don?t think hgweb can do that.  Mercurial being extensible, this addition may be a fun project.

3: Not all modules are good examples (see threading for some unelegant code), so I support ad-hoc selection.  I also support the real fix of improving the quality of every module, but that?s longer-term. :)

4: ?Show Source? is a link that is easily overlooked IMO, a seealso section makes me think people will actually see the link.  There is also the minor concern of breaking expectations of people accustomed to Sphinx.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Fri Jan  7 22:52:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 07 Jan 2011 21:52:01 +0000
Subject: [docs] [issue10858] Make source code links less prominent
In-Reply-To: <1294435943.46.0.999211081532.issue10858@psf.upfronthosting.co.za>
Message-ID: <AANLkTinjsCjNkuGENAe3YXJ-mjyc-g3mCeVUxTAZcCxy@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Jan 7, 2011 at 4:32 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> 3: Not all modules are good examples (see threading for some unelegant code), so I support ad-hoc selection.

The problem with ad-hoc selection is that it adds maintenance burden
(someone has to make a call) and it is inherently subjective.  For
example, I find dis.py source code rather uninspiring while
pickletools.py has a trove of valuable information about pickle
opcodes that is not available elsewhere.

> ?I also support the real fix of improving the quality of every module, but that?s longer-term. :)

Having the sources on "public display" may help achieving this goal.

> 4: ?Show Source? is a link that is easily overlooked IMO, a seealso section makes me think people
> will actually see the link.

A side-bar link may be in addition to the more prominent but less
common "See also" links.  If the source navigation becomes available,
we can also add inconspicuous links to function sectoins that would
take you directly to the function source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:06:52 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 09:06:52 +0000
Subject: [docs] [issue10813] Suppress adding decimal point for places=0 in
	moneyfmt()
In-Reply-To: <1294059487.44.0.656415691247.issue10813@psf.upfronthosting.co.za>
Message-ID: <1294477612.8.0.941696409319.issue10813@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r87856

----------
resolution:  -> accepted
status: open -> closed
type:  -> feature request
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10813>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:17:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 09:17:54 +0000
Subject: [docs] [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294478274.16.0.107017237624.issue10863@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is already fixed in dev docs, just needs backporting.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sat Jan  8 10:37:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 09:37:07 +0000
Subject: [docs] [issue10533] Need example of using __missing__
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1294479427.85.0.824834844627.issue10533@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r87858.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Sat Jan  8 11:28:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 10:28:01 +0000
Subject: [docs] [issue9717] operator module - "in place" operators
	documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1294482481.74.0.233201108452.issue9717@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r87862.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9717>
_______________________________________

From report at bugs.python.org  Sat Jan  8 20:50:54 2011
From: report at bugs.python.org (Jose-Luis Fernandez-Barros)
Date: Sat, 08 Jan 2011 19:50:54 +0000
Subject: [docs] [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294516254.79.0.993658947887.issue10863@psf.upfronthosting.co.za>


Jose-Luis Fernandez-Barros <jlfbarros at gmail.com> added the comment:

Thanks for your answer.

Error remains at development "The Python Standard Library", secction 12. Data Compression and Archiving
  http://docs.python.org/dev/py3k/library/zlib.html#module-zlib
zlib.compress(string[, level])

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sat Jan  8 22:04:42 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 21:04:42 +0000
Subject: [docs] [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294520682.9.0.395942635509.issue10863@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Quite right, this is now fixed in r87870.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sat Jan  8 22:04:48 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 Jan 2011 21:04:48 +0000
Subject: [docs] [issue10863] zlib.compress() fails with string
In-Reply-To: <1294430571.2.0.193589316262.issue10863@psf.upfronthosting.co.za>
Message-ID: <1294520688.18.0.12003503074.issue10863@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10863>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:15:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 Jan 2011 23:15:33 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1294528533.26.0.115575543099.issue9264@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sun Jan  9 00:52:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jan 2011 23:52:10 +0000
Subject: [docs] [issue10357] ** and "mapping" are poorly defined in python
	docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1294530730.29.0.128466220805.issue10357@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Clarified what it means to be a mapping in r87871 and r87872.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10357>
_______________________________________

From report at bugs.python.org  Sun Jan  9 01:06:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 00:06:08 +0000
Subject: [docs] [issue10533] Need example of using __missing__
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1294531568.31.0.28956473134.issue10533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great, thanks.

We?ll see later if more cross-links are needed.

----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Sun Jan  9 04:16:49 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 09 Jan 2011 03:16:49 +0000
Subject: [docs] [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294543009.44.0.97018842923.issue10858@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm curious as to how the experiment is being carried out and how conclusions will be drawn.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Sun Jan  9 09:59:46 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 09 Jan 2011 08:59:46 +0000
Subject: [docs] [issue10870] Last line of argparse code samples can not be
	read on	Windows
In-Reply-To: <1294563586.16.0.961055405371.issue10870@psf.upfronthosting.co.za>
Message-ID: <1294563586.16.0.961055405371.issue10870@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

When the code samples from the CHM documentation are displayed, if the lines are too long, a scroll bar is added at the bottom which prevents reading the last line of the code sample.

Usually this can be worked-around by making the windows larger, but some examples in the documentation of the argparse are so wide that even in full screen, the window is not wide enough.

I attached a screen capture to illustrate the issue (taken from section 14.4.3.3. nargs of Python 3.2b2). This is even worth with one-liner code sample when not browsing full screen (e.g. with the index on the side).

Environment: Windows XP SP3, resolution: 1024x768, python 3.2b2.

I don't know if it is possible, but adding a blank line at the end of code sample that are more than 80 characters wide would likely work-around the issue.

----------
assignee: docs at python
components: Documentation
files: argparse-codesample-unreadable.png
messages: 125832
nosy: blep, docs at python
priority: normal
severity: normal
status: open
title: Last line of argparse code samples can not be read on Windows
versions: Python 3.2
Added file: http://bugs.python.org/file20321/argparse-codesample-unreadable.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10870>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:07:41 2011
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 09 Jan 2011 09:07:41 +0000
Subject: [docs] [issue10871] argparse example use "file" instead of "open"
In-Reply-To: <1294564060.95.0.807361745459.issue10871@psf.upfronthosting.co.za>
Message-ID: <1294564060.95.0.807361745459.issue10871@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur <blep at users.sourceforge.net>:

In section "14.4.3.6. type" of the argparse module, the following code sample is given:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', type=int)
>>> parser.add_argument('bar', type=file)
>>> parser.parse_args('2 temp.txt'.split())
Namespace(bar=<open file 'temp.txt', mode 'r' at 0x...>, foo=2)

The built-in "file" used for argument 'bar' no longer exists in python 3.2.

----------
assignee: docs at python
components: Documentation
messages: 125834
nosy: blep, docs at python
priority: normal
severity: normal
status: open
title: argparse example use "file" instead of "open"
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10871>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:18:56 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 09:18:56 +0000
Subject: [docs] [issue10870] Last line of argparse code samples can not be
	read on	Windows
In-Reply-To: <1294563586.16.0.961055405371.issue10870@psf.upfronthosting.co.za>
Message-ID: <1294564736.82.0.249594019549.issue10870@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've shortened the examples in r87890.  I'll also investigate why the scrollbar isn't shown below the code.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10870>
_______________________________________

From report at bugs.python.org  Sun Jan  9 10:31:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 09:31:27 +0000
Subject: [docs] [issue10871] argparse example use "file" instead of "open"
In-Reply-To: <1294564060.95.0.807361745459.issue10871@psf.upfronthosting.co.za>
Message-ID: <1294565487.78.0.278609120496.issue10871@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, this is now fixed in r87891.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10871>
_______________________________________

From georg at python.org  Sun Jan  9 10:35:52 2011
From: georg at python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 10:35:52 +0100
Subject: [docs] A probable bug in The Python Tutorial
In-Reply-To: <AANLkTi=bWG9zxtVkXTJL=7KfpJ7vPkPCuXq5=y-ps0d-@mail.gmail.com>
References: <AANLkTi=bWG9zxtVkXTJL=7KfpJ7vPkPCuXq5=y-ps0d-@mail.gmail.com>
Message-ID: <4D298178.2070109@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 07.01.2011 17:27, schrieb Youcheng Lin:
> Hi,
> 
> In the section 
> 
> 
>     3.2. First Steps Towards Programming
> 
> This example introduces several new features.
> 
>     *
> 
>       The first line contains a /multiple assignment/: the
>       variables a and b simultaneously get the new values 0 and 1. On the last
>       line this is used again, demonstrating that the expressions on the
>       right-hand side are all evaluated first before any of the assignments take
>       place. The right-hand side expressions are evaluated from the_left to the
>       right._
> 
>       _
>       _
> 
>       I think the red underscored part should be _right to the left_

Hi Youcheng,

the text seems correct as written.  What makes you think otherwise?

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0pgXgACgkQN9GcIYhpnLA2VgCePBuNWGLuBkKV1LU+oh9fdJYZ
hU8An0AFN9drwv2XTf7jluf8kp+/TYIj
=sneT
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jan  9 10:36:29 2011
From: georg at python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 10:36:29 +0100
Subject: [docs] Docs in epub or single-html (without the left menu)
	format
In-Reply-To: <AANLkTikE+Ezaw1uKb_JVKs64-c+0nXR=Q6C=2ddRUA-V@mail.gmail.com>
References: <AANLkTikE+Ezaw1uKb_JVKs64-c+0nXR=Q6C=2ddRUA-V@mail.gmail.com>
Message-ID: <4D29819D.7020608@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 07.01.2011 17:46, schrieb Santiago Romero:
> 
>  Hi all.
> 
>  First of all, sorry for my poor english.
> 
>  I've recently purchased a nice 9 inches e-ink ebook reader and I wanted to read
> all python 2.7 documentation by using it, but I've been unable to found
> python.org <http://python.org>'s documents in .epub format. PDF is not usable in
> ebook readers because is intended for printing and the "blank" page margins make
> the documents almost unreadable.
> 
>  On other websites/projects, when I can't find a document in epub format, I
> usually download and use the "single html" versions. Unfortunatelly, python html
> documentation includes a "left menu" that takes almost 35-40% of the reading
> space in my ebook.
> 
>  Are the docs going to be "converted" (if possible) to epub or is there a way to
> get a single-html version without the left menu?

Hi Santiago,

as of Python 3.2 we're planning to release the docs in epub format.

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0pgZ0ACgkQN9GcIYhpnLD2GQCeLIf++CnwHFwa2RFDd2ITaFnn
UiUAnAjhUqIZ9yGzyfQusSi89fViLA98
=rcy2
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sun Jan  9 13:20:44 2011
From: report at bugs.python.org (Ashwin Purohit)
Date: Sun, 09 Jan 2011 12:20:44 +0000
Subject: [docs] [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>


New submission from Ashwin Purohit <purohit at gmail.com>:

Your example on page http://docs.python.org/tutorial/inputoutput.html is outdated and won't work in Python 2.7:

Basic usage of the str.format() method looks like this:

>>> print 'We are the {} who say "{}!"'.format('knights', 'Ni')
We are the knights who say "Ni!"


Now, all brackets have to have a numeric or keyword argument.

----------
assignee: docs at python
components: Documentation
messages: 125838
nosy: doagie, docs at python
priority: normal
severity: normal
status: open
title: String formatting example invalid
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 14:52:34 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 13:52:34 +0000
Subject: [docs] [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294581154.4.0.521911831004.issue10873@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Works as advertised for me. Unless more information is added, it looks like an invalid issue.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 14:56:51 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 09 Jan 2011 13:56:51 +0000
Subject: [docs] [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294581410.94.0.0853340779128.issue10873@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This feature was added in 2.7 (and 3.1, I think). If the numeric indices are not specified, they take the args in order.

----------
assignee: docs at python -> eric.smith
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:20:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 20:20:09 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

0. Does 'Release 0.05' at the top have any useful current meaning?
or could it be deleted?

1. Introduction:

The history paragraph "The re module was added in Python 1.5, and provides Perl-style regular expression patterns. Earlier versions of Python came with the regex module, which provided Emacs-style patterns. The regex module was removed completely in Python 2.5." might be eliminated in 3.x, or at least the irrelevant-for-py3 reference to regex. This is a policy decision.

2. Performing matches:

"If you have Tkinter available, you may also want to look at Tools/scripts/redemo.py,"

Change 'Tkinter' to 'tkinter' and make it a module reference.
In link, change 'scripts' to 'demo' as redemo.py got moved.

"Phil Schwartz?s Kodos is also an interactive tool for developing and testing RE patterns."

Add the url '(http://kodos.sourceforge.net/)' to the text so that Windows help users can copy and paste it into a browser. (This should be a general policy.)

"Python 2.2.2 (#1, Feb 10 2003, 12:57:01)"
delete

<_sre.SRE_Match object at 80c4f68>

This is correctly updated (for late 2.x and 3.x)

"<re.MatchObject instance at 80c9650>" (7 like this)

Globally replace 're.MatchObject instance' with '_sre.SRE_Match object'

3. Footnote

"[1] Introduced in Python 2.2.2."

remove for 3.x here and wherever footnote reference is in the text.

4. "Not Using re.VERBOSE"

This section is about *using* re.VERBOSE and the benefit thereof, not about not using it. I recommend deleting 'Not' as it gives the impression that the section is a warning about not using, the opposite of the intent.

5. Code example output and doctest:

I ran doctest.testfile("C:/programs/PyDev/py32/Doc/howto/regex.rst", module_relative = False)

After the 're...' to '_sre...' substitution above, all 11 failures would be due to 'at 0x#######' address mismatches. I believe changing all 11 addresses to '0x...' (I took this from the doctest doc) would both fix the failures and remove irrelevant detail for human readers.

The other 87 examples all passed ;-!.

Is there any current doctest-related markup that should be added?

----------
assignee: docs at python
components: Documentation
messages: 125855
nosy: akuchling, docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update Regular Expression HOWTO
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:47:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 20:47:59 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606079.23.0.68208171949.issue10875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Your points 1-5 all sound valid to me.  Would you like to do make a patch? I don't know what to do about the release number.  Probably doesn't hurt anyone to keep it.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:51:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 20:51:11 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606271.65.0.164511298304.issue10875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good points overall.

The only subpoint I disagree with is this one: ?Add the url '(http://kodos.sourceforge.net/)' to the text so that Windows help users can copy and paste it into a browser. (This should be a general policy.)?  IMO, it?s the job of the Sphinx builder to add URIs in plaintext if the format does not have hyperlinks.  -1 on cluttering the source and HTML output with duplicated links.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:52:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 20:52:50 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294606370.8.0.33298496606.issue10225@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As I understand this, your patch would fix numerous errors in the docs, but has not been applied. It would be nice to get the fixes into 3.2. What sort of feedback do you want? Proofreading of text? Recheck of doctest?

Does sphinx suppress doctest comments like
     #doctest: +IGNORE_EXCEPTION_DETAIL
?

doctest.testfile("C:/programs/PyDev/py32/Doc/howto/sorting.rst", module_relative = False) fails 23 of 37 attempts, so improvement is needed ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:55:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 09 Jan 2011 20:55:39 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606539.51.0.962615321739.issue10875@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Oh right, I misread that one.  Can't Windows help users right-click and select "Copy URL"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 21:56:59 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 20:56:59 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294606619.16.0.721316492897.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Here is the patch implementing all but the url suggestion.

Doctest still has 11 failures (changing to '0x...' didn't help).

----------
keywords: +patch
nosy: +SilentGhost
Added file: http://bugs.python.org/file20329/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:12:15 2011
From: report at bugs.python.org (Ashwin Purohit)
Date: Sun, 09 Jan 2011 21:12:15 +0000
Subject: [docs] [issue10873] String formatting example invalid
In-Reply-To: <1294581154.4.0.521911831004.issue10873@psf.upfronthosting.co.za>
Message-ID: <AANLkTikq=0yGxqFfpFhAUQPFZySdY01XPqvFaGg6z-Gw@mail.gmail.com>


Ashwin Purohit <purohit at gmail.com> added the comment:

Yes, apologies (I was using 2.6).

On Jan 9, 2011 5:52 AM, "SilentGhost" <report at bugs.python.org> wrote:

SilentGhost <ghost.adh at gmail.com> added the comment:

Works as advertised for me. Unless more information is added, it looks like
an invalid issue.

----------
nosy: +SilentGhost

_______________________________________ Python tracker <
report at bugs.python.org> <http://bugs.python...

----------
Added file: http://bugs.python.org/file20330/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________
-------------- next part --------------
<p>Yes, apologies (I was using 2.6).</p>
<p><blockquote type="cite">On Jan 9, 2011 5:52 AM, &quot;SilentGhost&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><br>
SilentGhost &lt;<a href="mailto:ghost.adh at gmail.com">ghost.adh at gmail.com</a>&gt; added the comment:<br>
<br>
Works as advertised for me. Unless more information is added, it looks like an invalid issue.<br>
<br>
----------<br>
nosy: +SilentGhost<br>
<p><font color="#500050">
_______________________________________
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;
&lt;<a href="http://bugs.python.">http://bugs.python.</a>..</font></p></blockquote></p>

From report at bugs.python.org  Sun Jan  9 22:17:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 09 Jan 2011 21:17:35 +0000
Subject: [docs] [issue10873] String formatting example invalid
In-Reply-To: <1294575644.02.0.857949444366.issue10873@psf.upfronthosting.co.za>
Message-ID: <1294607855.68.0.787058852289.issue10873@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20330/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10873>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:20:56 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 21:20:56 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294608056.27.0.063936928067.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

A few bits and pieces fixed compared to the previous patch.

>>> doctest.testfile("/home/mischa/pydev/Doc/howto/regex.rst", module_relative = False, optionflags=doctest.ELLIPSIS)
TestResults(failed=0, attempted=98)

----------
Added file: http://bugs.python.org/file20331/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:21:05 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 21:21:05 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294608065.42.0.123567303596.issue10875@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20329/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 22:35:31 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 21:35:31 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294608931.64.0.477348697842.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

It seems that the special sequences description in Matching Characters section need to be updated to incorporate information on unicode and bytes. I don't think, however, that it's a good idea just to copy that information from the Doc/library/re.rst May be the section could be shortened and linked to that RE Syntax section? there aren't any deeper links available unfortunately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:17:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 22:17:53 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294611473.04.0.752121486419.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that the .rst should not have two copies and that any windows.chm specific fixup should be in the tool. Right now, right clicking gives a context menu with one item: Properties. Clicking that brings up a dialog box with a url that can be copied. Good enough for me at the moment but not terribly obvious. A possible separate issue.

Unless A Kuchling says different, I would like to remove the version number. It implies to me that this doc is in pre-alpha condition and it is far beyond that. I see that the patch already does so.

-:file:`Tools/scripts/redemo.py`, a demonstration program included with the
+:file:`Tools/scripts/demo.py`, a demonstration program included with the

should (currently) be
+:file:`Tools/demo/redemo.py`, a demonstration program included with the

Other than that, the patch looks good. Thanks. I am still thinking about Matching Characters. Once the patch is fixed with possible addition, a 2.7 version can easily be made be deleting the 3.x-specific deletions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:29:07 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 22:29:07 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294612146.85.0.529573764226.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

I don't know whether it would be easy to strip down py3k version to 2.7 version.

Seeing how it's just a basic introduction, I would think that a single statement re unicode support might be sufficient. For exhaustive description of special sequences refer the docs and carry on with ascii strings.

Attached patch fixes path issue.

----------
Added file: http://bugs.python.org/file20332/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Sun Jan  9 23:29:27 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 09 Jan 2011 22:29:27 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294612167.09.0.407573581773.issue10875@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20331/regex.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 00:50:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Jan 2011 23:50:32 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294617032.15.0.971529291218.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since I think I know how to do it, easily, I will try to derive the 2.7 patch.

In Matching Characters, I think
"The following predefined special sequences are available:"

should be expanded to 

"The following predefined special sequences are a subset of those available. The equivalent classes are for bytes patterns. For a complete list of sequences and expanded class definitions for Unicode string patterns, see the end of Regular Expression Syntax."
(with section reference markup).

Note to myself. /bytes/byte string/ for 2.7.

While the changes all look innocuous to me with respect to building the docs, I am curious if you have tried to rebuild the HOWTO (if you have the tool chain, which I do not).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 03:20:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 02:20:42 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294626042.4.0.192426886898.issue10875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I agree that the .rst should not have two copies and that any windows.chm specific fixup should be in the tool. Right now, right clicking gives a context menu with one item: Properties. Clicking that brings up a dialog box with a url that can be copied. Good enough for me at the moment but not terribly obvious. A possible separate issue.

I would argue that this is a bug in the CHM viewers, not Python :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 04:26:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Jan 2011 03:26:54 +0000
Subject: [docs] [issue10858] Make source code links less prominent
In-Reply-To: <1294423770.11.0.311474750627.issue10858@psf.upfronthosting.co.za>
Message-ID: <1294630013.94.0.900105904803.issue10858@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Removed the wordy and bright yellow boxes.
Replace with single source link just below the section heading.
Style modeled after that used in the Go language docs http://golang.org/pkg/container/heap/

See r87898.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10858>
_______________________________________

From report at bugs.python.org  Mon Jan 10 06:26:53 2011
From: report at bugs.python.org (Craig McQueen)
Date: Mon, 10 Jan 2011 05:26:53 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1294637213.55.0.545769757806.issue9196@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

I'm attaching a file that I used (in Python 2.x).

It's a little rough--I manually commented and uncommented various lines to see what would change under various circumstances. But at least you should be able to see what I was doing.

----------
Added file: http://bugs.python.org/file20334/class_str_unicode_methods.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________

From report at bugs.python.org  Mon Jan 10 11:09:49 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 10 Jan 2011 10:09:49 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294654189.76.0.833765927726.issue10875@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

> While the changes all look innocuous to me with respect to building the docs, I am curious if you have tried to rebuild the HOWTO (if you have the tool chain, which I do not).

I did rebuild the docs with 'make html'. Build was clean every time. If you meant something else please let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Mon Jan 10 18:37:29 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Jan 2011 17:37:29 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1294606370.8.0.33298496606.issue10225@psf.upfronthosting.co.za>
Message-ID: <AANLkTintK_9ueQ4=632FsqO_TDCNue+qWe7oUB4xFmmJ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Jan 9, 2011 at 3:52 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> .. It would be nice to get the fixes into 3.2.

Yes, it would be nice, but I don't have a 3.2 patch (yet).  As you can
see from my last comment, I ran into a bug in the alpha version of
sphinx that I used to validate py3k docs.

> What sort of feedback do you want? Proofreading of text? Recheck of doctest?
>

All of the above.  Some of the fixes may be at the expense of
readability.   I would appreciate feedback in the instances when human
and computer reader's interests are in conflict.   Some examples are
"fixed" by excluding them from being checked.  Better ideas are
welcome.

> Does sphinx suppress doctest comments like
> ? ? #doctest: +IGNORE_EXCEPTION_DETAIL
> ?

Yes.

>
> doctest.testfile("C:/programs/PyDev/py32/Doc/howto/sorting.rst", module_relative = False)
> fails 23 of 37 attempts, so improvement is needed ;-).

You cannot run documentation examples with a plain doctest.   You have
to use sphinx-build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Mon Jan 10 23:46:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 10 Jan 2011 22:46:20 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294699580.69.0.0480001739558.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I applied patch to 3.2, 3.1 in r87904, r87905. Thanks.
I had to re-edit for 2.7: r87909.

I made a separate small patch for my suggested addition to Matching Characters. Could someone check that it is correct, given that re.rst contains the target directive (or whatever it is called):
.. _re-syntax:

----------
assignee: docs at python -> terry.reedy
stage: needs patch -> commit review
Added file: http://bugs.python.org/file20340/zregex2.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:01:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 10 Jan 2011 23:01:06 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294700466.14.0.679438659325.issue10875@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good, builds without warnings.

Note that you can use :ref:`re-syntax` and Sphinx will substitute the heading for you.  The :role:`some special text <real-target>` form is used when you want to control the text of the link.

(That thing is called an hyperlink target: http://docutils.sourceforge.net/docs/user/rst/quickref.html#hyperlink-targets)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 00:19:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 10 Jan 2011 23:19:19 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294701559.8.0.286674673514.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks. r87911,r87912

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 01:08:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 00:08:20 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294704500.04.0.65307076913.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

and r87918 for 2.7, with bytes -> byte string

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 03:18:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 02:18:26 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294712306.84.0.489073706162.issue7229@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am going to reject this.  None of the proposed changes seem to be better than the current documentation. The time.daylight variable has the same meaning as eponymous C variable defined in time.h header.  The latter is described in widely available and well known C and POSIX standards. Users that find Python manual description confusing or incomplete can easily find clarifications or details in other sources.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 09:37:24 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 08:37:24 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294735043.99.0.987263775581.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

I am sorry, but as an original initiator of the the issue I find the argumentation of Alexander Belopolsky vastly ridiculous. Are you really seriously convinced that an average person responsible for Python application development and maintenance would be aware of a necessity to look for an ANSI C documentation to find a description and definitions of time functions?

You sound like Marie Antoinette who replied to peasants complaining the they do not have any bread to eat that they should eat brioches instead. Maybe in the context of the ?royal programmers family? documentation to ANSI C is wildly known and even memorized, but I do insist that Python documentation should be accessible and understandable even to ordinary peasants of the computer kingdom.

And I keep my case that the current description might trick programmers to think that it holds information whether the summer time currently applies rather than just plain information about current time zone being able to use summer time.

Regards
Tomas

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 10:55:47 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 09:55:47 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294739747.17.0.9995254198.issue7229@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Classic user developer impedance mismatch. =)

I agree that Python should guard its users against crazy standards that creep into standard lib, because nobody had time to think about pythonic API.

I propose the following change:

http://docs.python.org/library/time.html#time.altzone
-  UTC offset of the local DST timezone if one is defined. Only use this if daylight is nonzero.
+  UTC offset of the current timezone with Daylight Savings Time (DST) correction. To check if DST is currently active, use `time.localtime(t).tm_isdst`

http://docs.python.org/library/time.html#time.daylight
-  Nonzero if a DST timezone is defined.
+  Flag indicating that current timezone has Daylight Savings Time (DST) offset. To check if DST is currently active, use `time.localtime(t).tm_isdst`

http://docs.python.org/library/time.html#time.timezone
-  UTC offset of the local (non-DST) timezone
+  UTC offset of the current timezone. It doesn't include Daylight Savings Time (DST) correction. See `time.altzone` for that.


BTW, isn't the following check redundant?
    if time.localtime(t).tm_isdst and time.daylight:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 12:26:10 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 11:26:10 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294745170.59.0.81351156853.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

Hello,

I find this version very clear.

Thanks
Tomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 15:52:57 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 14:52:57 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1294739747.17.0.9995254198.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Zn6tkHZLeyFVnGsd3HpEwNW-Mz=hQtVGxb8cP@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 4:55 AM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> I propose the following change:
..
> http://docs.python.org/library/time.html#time.daylight
> - ?Nonzero if a DST timezone is defined.
> + .. To check if DST is currently active, use `time.localtime(t).tm_isdst`

This is simply wrong. Your time.localtime(t).tm_isdst expression will
return the DST flag for the POSIX time value t, not for the current
time.  This could be fixed by replacing your proposed expression with
time.localtime().tm_isdst, but why do you think someone  reading about
time.daylight actually wants to "check if DST is currently active"?

What can be improved, though, is the documentation of time.tzset().
The current version fails to mention that  time.tzset() resets the
values of tzname, timezone, altzone and daylight.  This would be the
proper place to document the meaning of all three variables in greater
detail.  Individual entries can then refer to it with say "See
time.tzset() for details."

Here is how POSIX tzset() is defined:

"""
The tzset() function sets the external variable tzname as follows:

tzname[0] = "std";
tzname[1] = "dst";

where std and dst are as described in the XBD specification,
Environment Variables .

The tzset() function also sets the external variable daylight to 0 if
Daylight Savings Time conversions should never be applied for the time
zone in use; otherwise non-zero. The external variable timezone is set
to the difference, in seconds, between Coordinated Universal Time
(UTC) and local standard time.
"""  http://pubs.opengroup.org/onlinepubs/007908799/xsh/tzset.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:20:21 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 16:20:21 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294762821.02.0.411400646391.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

>>why do you think someone  reading about
time.daylight actually wants to "check if DST is currently active"?

If you are not familiar with the cryptic names of POSIX but live in normal world, time.daylight sounds like a quite probable place where to check if the daylight savings are active. That's why I think the help text should explicitely note it has other meaning.

You should try to think like a person that does not have any background knowledge of underlying libraries but just looks through the time library trying to solve the question - how can I check if my machine uses daylight savings now.

Regards
Tomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:22:28 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 11 Jan 2011 16:22:28 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294762948.74.0.0194333980949.issue7229@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:26:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 16:26:31 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1294763191.61.0.184014624161.issue9305@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've noticed that the time module docstring handles this issue rather nicely:

>>> help('time')
...
    timezone -- difference in seconds between UTC and local standard time
    altzone -- difference in  seconds between UTC and local DST time

We can use similar language for utcoffset(): "difference between local time and UTC expressed as a timedelta".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:39:50 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 16:39:50 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1294762821.02.0.411400646391.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTimmA=ozOns4BbBsmaT7KOu+Bh3_f5D3vy87yAHT@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 11:20 AM, Tomas Kubes <report at bugs.python.org> wrote:
..
> You should try to think like a person that does not have any background knowledge of underlying libraries but
> just looks through the time library trying to solve the question - how can I check if my machine uses daylight
> savings now.

I think you are confusing the purposes of a reference manual with that
of a tutorial or an FAQ collection.

I will keep this issue open, however, in case someone will come up
with a patch that does not introduce factual mistakes.   As I
suggested, the place to present details about tzname, timezone,
altzone and daylight variables is the section on time.tzset().  It is
currently devoted to a rather useless discussion of the TZ environment
variable syntax.  Instead, it should describe these variables and list
the functions whose behavior depends on the value of TZ
(time.localtime(), time.ctime(), time.mktime() and time.strftime()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:56:39 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 11 Jan 2011 16:56:39 +0000
Subject: [docs] [issue10885] multiprocessing docs
In-Reply-To: <1294742845.68.0.53995604469.issue10885@psf.upfronthosting.co.za>
Message-ID: <1294764999.69.0.234249030619.issue10885@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10885>
_______________________________________

From report at bugs.python.org  Tue Jan 11 17:57:11 2011
From: report at bugs.python.org (Tomas Kubes)
Date: Tue, 11 Jan 2011 16:57:11 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294765031.26.0.216259312364.issue7229@psf.upfronthosting.co.za>


Tomas Kubes <mr_napik at centrum.cz> added the comment:

> I think you are confusing the purposes of a reference manual with that
of a tutorial or an FAQ collection.

There is a fine line between them. Even though reference manual should not be a substitute for a tutorial, I still believe it should try to clarify potential confusions - after all it is the less experienced users who will most likely spend their time with it looking for something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 18:28:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 17:28:15 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294766895.44.0.357887111332.issue10875@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg125954

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 18:46:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 17:46:30 +0000
Subject: [docs] [issue10875] Update Regular Expression HOWTO
In-Reply-To: <1294604409.29.0.577762819836.issue10875@psf.upfronthosting.co.za>
Message-ID: <1294767990.76.0.851522702608.issue10875@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Correction: r87912 and r87913 for 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10875>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:14:06 2011
From: report at bugs.python.org (rurpy the second)
Date: Tue, 11 Jan 2011 18:14:06 +0000
Subject: [docs] [issue1397474] timeit execution enviroment
Message-ID: <1294769646.21.0.3653114015.issue1397474@psf.upfronthosting.co.za>


rurpy the second <rurpy at yahoo.com> added the comment:

I find the changes suggested by T Reedy and refined in the 
patch by E Bendersky an improvement.  However, I found the 
following things confused me when reading it:

"...constructor creates a function..."
the constructor creates a Timeit instance, not a function.  
There is a method on that instance that is the function but 
the way it is phrased in like describing the autos coming off
a Ford production line as "steering wheels".  As written, the 
statement creates an immediate WTF reaction in my mind.

"...that executes the *setup* statement..."
Use of term "statement" here is confusing as that term already
has a well defined meaning in Python docs.  One can't syntactically
use a statement as a function argument.  Only by suspending this
confusion and reading further does one discover that "statement"
here means a string containing text of some python code or a 
callable object.  

Use of "statement" (singular) also directly conflicts with following 
information that states multiple statements are ok.  

Since the synopsis line already refers to "snippets", I think 
continuing to use that is better (having no preexisting conflicting
meanings) than "statement".

"...default to ``'pass'`..." 
The call summary immediately above makes clear what the default
parameter values are.  While fine to repeat it in text, it is not
high priority information so should be moved to later in the
description.

"...or newlines as long as they don???t contain  multi-line string literals..."
What is a multi-line string literal?  The Language Reference -> 
Lexical Analysis -> String Literals section says nothing about 
"multi-line literals".  
Is it "a\nb"?  Or """a
b"""?  Both?
'"a\nb"' actually works.  '"""a
b"""' doesn't of course but it is it is also clearly not valid
python string syntax so I'm not sure that 'multi-line strings need 
even be mentioned.  If it is mentioned then it should be made clear 
that multi-line string literals are not allowed not because timeit
doesn't like them, but because python syntax allows no way to 
embed them in another string.
.
"...pre-defined user objects..."
What does "pre-defined" mean?  Builtin?  Imported from stdlib?
I would use a more explicit description here.

I also think a short explanation of *why* one needs to import 
program objects in 'setup' makes it a little easier and quicker 
to understand what one is doing with the import, particularly if
one is using timeit somewhere other than __main__..  Thus I 
suggest expanding that section slightly.

Here is my attempt to adjust taking the above observations into 
account.  (Sorry, can't supply a patch since I have slow internet
connection and don't have source.  Text below is just my hand edit
of the "+" lines in Eli's patch.)

  Class for timing execution speed of small code snippets.
  A Timeit instance will contain a function (see :meth:`Timer.timeit`)
  that executes a snippet of "setup" code once and then times some 
  number of executions of "stmt" code .  The code snippets, given as
  arguments *setup* and *stmt* when creating the instance, may be 
  either strings or callable objects.

  If a string, it may contain a python expression, statement, or
  multiple statements separated by ";" or newlines.  Whitespace 
  adhering to the usual Python indentation rules must follow any
  newlines.

  If a callable object, (often a function), the object is called 
  with no arguments.  Note that the timing overhead is a little 
  larger in this case because of the extra function calls required.

  The *setup* and *stmt* parameters default to ``'pass'``.
  The *timer* parameter defaults to a platform-dependent 
  timer function (see the module doc string).

  When the *setup* and *stmt* are run, they are run in a 
  different namespace than that of the code that calls timeit(). 
  To give *stmt* (whether it is a callable name or code string) 
  access to  objects defined in the code that calls timeit, 
  *setup* can import any needed objects.  For example, if your
  code defines function testfunc(), *setup* can contain, 
  ``from __main__ import testfunc``, and code in   *stmt* can
  then call testfunc.

  To measure the execution time of *stmt*, use the :meth:`Timer.timeit()` method. 
  The :meth:`Timer.repeat()` method is a convenience to call :meth:`Timer.timeit()` 
  multiple times and return a list of results.

  Changed in version 2.6: The stmt and setup parameters can now
  also take objects.

Notes:
----
Added the line "Whitespace adhering..." because when using backslash-n
in strings it is easy to forget about any needed indentation.  Sentence
could be deleted if deemed too obvious.  There may also be a better 
way to phrase it; currently it might imply that some whitespace
is always neccessary if not enough attention paid to the "usual
indentation rules" phrase.

----
In msg116330 - Eli Bendersky (eli.bendersky) wrote:

> 1) My tests show that passing the callable instead of the string
> 'test()' actually takes longer to run.

Should the documentation promise that?
I take your word that it also takes longer than running the function's
code directly (outside a function) 
     
The original "Changed in version 2.6" section said

| Note that the timing overhead is a little larger in this case 
| [callable objects] because of the extra function calls.

Here, "the other case" is presumably the plain code but could 
also be a string function call (e.g. "test()") so I suppose it
is still vacuously true in that case.  Accordingly I reused the
statement above in in my suggested changes.  Perhaps all three 
cases (string code, string function call, callable object) 
should be distinguished further and compared re overhead?

----------
nosy: +rurpy2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397474>
_______________________________________

From report at bugs.python.org  Tue Jan 11 19:56:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Jan 2011 18:56:54 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1294772214.87.0.0663546786939.issue7229@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It seems to me that the quoted function from bzr

def local_time_offset(t=None):
    """Return offset of local zone from GMT, either at present or at time t."""
    # python2.3 localtime() can't take None
    if t is None:
        t = time.time()

    if time.localtime(t).tm_isdst and time.daylight:
        return -time.altzone
    else:
        return -time.timezone

would be very helpful to add to the `time` module docs as an example.  I have to agree with the OP that the current state of the docs is not as clear as it could be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 20:42:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 19:42:09 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1294772214.87.0.0663546786939.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTinFTkwCLOyn9f6rE2-wKr-iSJ-Pdk1Rd7yKTxmw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 1:56 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> It seems to me that the quoted function from bzr ...
> would be very helpful to add to the `time` module docs as an example.

The problem with this function is the same as with the doc patches
that have been proposed so far.  It is subtly wrong.  See issue
#1647654.  Specifically, see the link to a bug in Hg mentioned in
msg122166.

>?I have to agree with the OP that the current state of the docs is not as clear as it could be.

In some ways the state of the docs is reflective of the state of the
code.  C/POSIX API on which time module design is based is not very
well suited to the age of smart phones and distributed VC systems.
The whole idea that there is a static "system timezone" is absurd when
a "system" is in your pocket or in the cloud.

I agree that the docs can be improved, but I don't see patches that
would constitute an improvement.  I've explained what I would see as
an improvement in my prior comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 22:15:00 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 21:15:00 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <AANLkTi=Zn6tkHZLeyFVnGsd3HpEwNW-Mz=hQtVGxb8cP@mail.gmail.com>
Message-ID: <AANLkTi=t2548FPZQQTYbyyxWGJdoeB4EmYR9Esu=tuea@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Tue, Jan 11, 2011 at 4:52 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> ..
>> http://docs.python.org/library/time.html#time.daylight
>> - ?Nonzero if a DST timezone is defined.
>> + .. To check if DST is currently active, use `time.localtime(t).tm_isdst`
>
> This is simply wrong. Your time.localtime(t).tm_isdst expression will
> return the DST flag for the POSIX time value t, not for the current
> time. ?This could be fixed by replacing your proposed expression with
> time.localtime().tm_isdst, but why do you think someone ?reading about
> time.daylight actually wants to "check if DST is currently active"?

Sorry, I've just copy/pasted this snippet and haven't noticed t argument.

As for your question, I think that someone reading about time.daylight
is reading about it to know how it can be used, and if you're quoting,
please quote without removing words inside the quote, or else I won't
be able to give you the answers that will be appropriate in your
context.

> What can be improved, though, is the documentation of time.tzset().
> The current version fails to mention that ?time.tzset() resets the
> values of tzname, timezone, altzone and daylight. ?This would be the
> proper place to document the meaning of all three variables in greater
> detail. ?Individual entries can then refer to it with say "See
> time.tzset() for details."

How about making it in iterations and keep the steps as small as
possible, i.e. split the big problem into munchable chunks? First we
can accept the version of doc from my previous comment and then open a
new RFE for further work. Considering how much time this issue took
already, I see this approach as the only viable one.

> Here is how POSIX tzset() is defined:
> ...

I am sorry Alexander, but I can't really follow up on this issue. It
is interesting, but unfortunately right now I can only dedicate my
time to things that take don't more than 15 minutes of my attention,
and there are about 50 out of 700 of these in my inbox right now. We
need to split these datetime problems into smaller ones somehow. They
are really too complex for users.

To summarize: What is wrong with my previous proposal if we remove t
from params?

P.S. Looks like we need a PEP for this. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 22:22:24 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 11 Jan 2011 21:22:24 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <AANLkTinFTkwCLOyn9f6rE2-wKr-iSJ-Pdk1Rd7yKTxmw@mail.gmail.com>
Message-ID: <AANLkTi=g0pCiWqmeCuDOUFhf+pAg_0OMuKaQn+G82XOc@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Tue, Jan 11, 2011 at 9:42 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
>
>>?I have to agree with the OP that the current state of the docs is not as clear as it could be.
>
> In some ways the state of the docs is reflective of the state of the
> code. ?C/POSIX API on which time module design is based is not very
> well suited to the age of smart phones and distributed VC systems.
> The whole idea that there is a static "system timezone" is absurd when
> a "system" is in your pocket or in the cloud.
>
> I agree that the docs can be improved, but I don't see patches that
> would constitute an improvement. ?I've explained what I would see as
> an improvement in my prior comments.

Absurd need to be eliminated, but every time I touch datetime issues I
am confused by the complexity of additional information and
incompatibility of low-level C API with user needs. We need datetime
FAQ for a reference and a collection of user stories to see what it
possible (with examples/recipes) and what is impossible (with
proposals/PEP) in current state. If I was in charge - I'd mark all
datetime issues as release blockers for Py3k, so that all who wanted
Py3k released ASAP dedicate their time to this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Tue Jan 11 22:27:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 21:27:26 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <AANLkTi=t2548FPZQQTYbyyxWGJdoeB4EmYR9Esu=tuea@mail.gmail.com>
Message-ID: <AANLkTikYbXX+pm=PRZBRJZkb02kh-2oqvPpFnR2aXF5F@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 4:15 PM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> To summarize: What is wrong with my previous proposal if we remove t
> from params?

Not much is wrong with it.   If it would come in a form of a patch and
without typos or mark-up mistakes, I or another committer would
probably apply it as an incremental improvement.   However, given that
additional effort is needed to apply your suggestion, I would rather
wait until a better solution is available.  Specifically, I don like
the duplication of time.localtime().tm_isdst recipe in daylight and
altzone.  Also, these variables should really be grouped together in
the docs.   I would like this to be done before a committer spends
time proofreading, fixing reST markup and committing the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:10:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Jan 2011 23:10:11 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294787411.16.0.552389169733.issue10225@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Doctest runs on .rst files, which are plain text files, finds and reports errors, and reports no errors when the errors are fixed. See #10875 where is was very helpful. So your last comment puzzles me.

In any case, your patch is too big to digest at once. I extracted the part for howto/sorting.rst and tried to apply to 3.2, but the file has changed too much (at least for TortoiseSVN). So I pasted the '... 's (and adjusted spacing) where needed, and did the two other changes you had. This left just two failures -- for the 2.7 code using 'cmp=xxx' args. With '# doctest: +SKIP' added twice, doctest passes. Patch commited for 3.2 as r87946.

> instances when human and computer reader's interests are in conflict.
What is one (or more) that you were thinking of?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:17:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Jan 2011 23:17:09 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1294787411.16.0.552389169733.issue10225@psf.upfronthosting.co.za>
Message-ID: <AANLkTikiQZGX-NC6wb=cgOrThZYa9efN3=PQ8Pnbw+DQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 6:10 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
> Doctest runs on .rst files, which are plain text files, finds and reports errors, and reports no errors when the errors are fixed.
> See #10875 where is was very helpful. So your last comment puzzles me.
>

Sphinx doctest runner supports doctest fixtures that plain doctest
does not.  Some of the examples in the docs rely on these.

See http://sphinx.pocoo.org/ext/doctest.html .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 00:50:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 11 Jan 2011 23:50:05 +0000
Subject: [docs] [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1294789805.46.0.848504751362.issue7057@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I used 'manN'
FYI, there is a :file:`man{n}` construct where braces mark up replaceable text, like the var element in HTML.

----------
nosy: +docs at python, eric.araujo -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7057>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:12:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 00:12:19 +0000
Subject: [docs] [issue10885] multiprocessing docs
In-Reply-To: <1294742845.68.0.53995604469.issue10885@psf.upfronthosting.co.za>
Message-ID: <1294791139.85.0.46757774653.issue10885@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +asksol, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10885>
_______________________________________

From report at bugs.python.org  Wed Jan 12 01:21:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 00:21:00 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1294791660.27.0.464903946975.issue4395@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python -georg.brandl
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Wed Jan 12 02:02:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 01:02:08 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294794128.41.0.424767788036.issue10225@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Terry, I'm unhappy with the changes to the sorting how-to.  IMO, it was a not a net win (transforming code that already ran fine in something doctest would swallow).  The code snippets now have the visual clutter of the ">>>" and "..." PS1 and PS2 prompts and they can no longer be readily cut and pasted into the interpreter so that people can experiment with them.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 04:03:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Jan 2011 03:03:57 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294801437.06.0.921332361387.issue10225@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There are two reasons I forward ported the changes.

1. Without running doctest on doc examples, they sometimes have errors either originally, after patches to the doc, or after patches to Python. On other issues, I found 4 errors in the json doc (probably original; my fixes were augmented and committed by GB, I believe), and several in the re howto (due to non-update after re changes). There have been other error reports on the tracker and I presume more (other than missing '...') shown in AB's patch. (I just started with the first file changed in the patch.) So I thought it pretty well settled that getting doc examples correct (and test-ready) is be a good idea.

2. Examples with output always start with '>>> ' to differentiate input from output. I thought it pretty standard that continuation lines start with '... '. This is true of all applicable examples in re howto, module chapters for difflib, json, bisect, and 4 of 5 applicable examples in the Built-in Types chapter. Other chapters for binhex, itertools, and tkinter have no multiline interactive examples, so provide no precedent either way.

What is the alternative? The current sorting howto is not consistent:

For some examples, '... ' is just deleted:
>>> student_tuples = [
    ('john', 'A', 15),
    ('jane', 'B', 12),
    ('dave', 'B', 10),
]

For others, '... ' is replaced with '    ':
>>> class Student:
        def __init__(self, name, grade, age):
            self.name = name
            self.grade = grade
            self.age = age

The cmp_to_key function def is a special case: there is no output in the same box with the def and so (normally) should not have prompts. The only reason I followed AB's patch here and added them is because the definition is used in the next box. If the next example were changed for 3.2 to use the new-in-3.2  functools.cmp_to_key(), then the def would not be needed.  (I already planned to suggest thisOr the followup example could just be marked SKIP. With either change, I would remove the prompts added to this function, which are the ones I presume bother you the most.


Summary: according to my current (and subject-to-update ;-) understanding of precedent and policy, the changes other than for cmp_to_key seem correct. The rationale for cmp_to_key changes could easily be negated, in which case they should be reverted.

I will put my thoughts on cut-and-paste in a separate message.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 05:21:55 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 04:21:55 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294806115.86.0.11897022638.issue10225@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

You're welcome to discuss this with me on IRC at some point.  For now, the important thing is that I put a good deal of time and effort working on the sorting howto and I like it as it stands (your notions of precedent or consistency not withstanding).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 05:32:05 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 04:32:05 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1294801437.06.0.921332361387.issue10225@psf.upfronthosting.co.za>
Message-ID: <AANLkTikZo+B4oKs+0GitogNB-nYbKHJEPzZ8gGy-CShQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Jan 11, 2011 at 10:03 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
> What is the alternative?

I am attaching an alternative patch for sorting howto. You can run the
doctests in it as follows:

$ python2.7 tools/sphinx-build.py -b doctest -d build/doctrees .
build/doctest howto/sorting.rst
...

Doctest summary
===============
   34 tests
    0 failures in tests
    0 failures in setup code
build succeeded.

Unfortunately, Sphinx does not support Ramond's preferred style, but
my patch comes close.

----------
Added file: http://bugs.python.org/file20359/sorting-howto.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________
-------------- next part --------------
Index: howto/sorting.rst
===================================================================
--- howto/sorting.rst	(revision 87942)
+++ howto/sorting.rst	(working copy)
@@ -58,30 +58,44 @@
 A common pattern is to sort complex objects using some of the object's indices
 as keys. For example:
 
-    >>> student_tuples = [
+.. testcode::
+
+    student_tuples = [
         ('john', 'A', 15),
         ('jane', 'B', 12),
         ('dave', 'B', 10),
     ]
-    >>> sorted(student_tuples, key=lambda student: student[2])   # sort by age
+
+Sort by age:
+
+.. doctest::
+
+    >>> sorted(student_tuples, key=lambda student: student[2])
     [('dave', 'B', 10), ('jane', 'B', 12), ('john', 'A', 15)]
 
 The same technique works for objects with named attributes. For example:
 
-    >>> class Student:
-            def __init__(self, name, grade, age):
-                self.name = name
-                self.grade = grade
-                self.age = age
-            def __repr__(self):
-                return repr((self.name, self.grade, self.age))
+.. testcode::
 
-    >>> student_objects = [
+    class Student:
+        def __init__(self, name, grade, age):
+            self.name = name
+            self.grade = grade
+            self.age = age
+        def __repr__(self):
+            return repr((self.name, self.grade, self.age))
+
+    student_objects = [
         Student('john', 'A', 15),
         Student('jane', 'B', 12),
         Student('dave', 'B', 10),
     ]
-    >>> sorted(student_objects, key=lambda student: student.age)   # sort by age
+
+Sort by age:
+
+.. doctest::
+
+    >>> sorted(student_objects, key=lambda student: student.age)
     [('dave', 'B', 10), ('jane', 'B', 12), ('john', 'A', 15)]
 
 Operator Module Functions
@@ -210,22 +224,34 @@
 return a negative value for less-than, return zero if they are equal, or return
 a positive value for greater-than. For example, we can do:
 
-    >>> def numeric_compare(x, y):
-            return x - y
+.. testcode::
+
+    def numeric_compare(x, y):
+        return x - y
+
+.. doctest::
+
     >>> sorted([5, 2, 4, 1, 3], cmp=numeric_compare)
     [1, 2, 3, 4, 5]
 
 Or you can reverse the order of comparison with:
 
-    >>> def reverse_numeric(x, y):
-            return y - x
+.. testcode::
+
+    def reverse_numeric(x, y):
+        return y - x
+
+.. doctest::
+
     >>> sorted([5, 2, 4, 1, 3], cmp=reverse_numeric)
     [5, 4, 3, 2, 1]
 
 When porting code from Python 2.x to 3.x, the situation can arise when you have
 the user supplying a comparison function and you need to convert that to a key
-function. The following wrapper makes that easy to do::
+function. The following wrapper makes that easy to do:
 
+.. testcode::
+
     def cmp_to_key(mycmp):
         'Convert a cmp= function into a key= function'
         class K(object):

From report at bugs.python.org  Wed Jan 12 05:36:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 04:36:43 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294807003.65.0.129646895963.issue10225@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: belopolsky -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 11:29:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 12 Jan 2011 10:29:48 +0000
Subject: [docs] [issue10891] Tweak sorting howto to eliminate redundancy
In-Reply-To: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>
Message-ID: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When reading over the sorting howto, I noticed redundancy of the form ?the list.sort() method of a list?.  Raymond, if you approve the attached patch, please assign back to me.  There were no warnings during doc build and no link was broken.

Note that :meth:`list.sort` (or :meth:`~list.sort`) does not trigger a link to the doc of the method, since sort is not marked up with a method directive but listed in a table alongside other list and bytearray methods (http://docs.python.org/dev/library/stdtypes#typesseq-mutable).  This table is preceded by index-generating markup, but it does not create a target for :meth:`list.sort`; that?s a separate issue.  Until it?s solved, the sorting howto could turn the first occurrence of ?list? into a link to the right section, using :ref:`typesseq-mutable <list>`, or continue to live without a link to list or list.sort.

----------
assignee: rhettinger
components: Documentation
files: minor-sorting-changes.diff
keywords: patch
messages: 126083
nosy: docs at python, eric.araujo, rhettinger
priority: normal
severity: normal
stage: commit review
status: open
title: Tweak sorting howto to eliminate redundancy
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20364/minor-sorting-changes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10891>
_______________________________________

From report at bugs.python.org  Wed Jan 12 13:59:56 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 12 Jan 2011 12:59:56 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

The Python documentation uses :func:`staticmethod` to describe staticmethod, while staticmethod is a type.

I want to link to the Python documentation from my project's documentation using Intersphinx, and I wouldn't want to mislead my users by marking static method as a function.

----------
assignee: docs at python
components: Documentation
messages: 126090
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: The docs mark staticmethod as a function
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Wed Jan 12 15:58:27 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 12 Jan 2011 14:58:27 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294844307.79.0.300465389265.issue10893@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

So, is int, str, bool and enumerate. And many others. The preface on functions page (http://docs.python.org/dev/library/functions.html) says: 

"The Python interpreter has a number of functions and types built into it that are always available."

I would think it's clear enough.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:33:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 15:33:42 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294846422.29.0.831272331294.issue10225@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have updated Sphinx and rerun py3k doctests.  It looks like the newest Sphinx does not check examples unless the file has a .. testsetup::  directive somewhere.  This is nice because it focuses on the files that are clearly intended to be doctest-checked.  Of course, there are many perfectly good code examples that are now skipped, but this can be addressed in the next step.

I am attaching a patch that makes the following command succeed in py3k Doc directory:

$ sphinx-build --version
Sphinx v1.1pre
..
$ sphinx-build -b doctest -d build/doctrees . build/doctest
..
Doctest summary
===============
  581 tests
    0 failures ..

Most of the changes in issue10225-py3k.diff are non-controvercial with the exception of code fixes in collections and difflib.

In collections, I removed trailing whitespace from generated namedtuple code and in difflib I changed get_close_matches() return value from map object to a list.   I would appreciate comments on these two changes.

----------
Added file: http://bugs.python.org/file20375/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:38:36 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 15:38:36 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294846716.01.0.148440069992.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file20376/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 16:38:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 15:38:42 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294846722.55.0.00122548863904.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20375/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 17:42:56 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 16:42:56 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294850576.65.0.83039259773.issue10225@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed the simple fixes in r87957.  Updated the patch to include only the remaining changes.

----------
Added file: http://bugs.python.org/file20377/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 17:43:08 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 12 Jan 2011 16:43:08 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1294850587.99.0.312084825378.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20376/issue10225-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Wed Jan 12 20:13:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 12 Jan 2011 19:13:19 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294859599.88.0.145593072436.issue10893@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From mauhfh at live.warwick.ac.uk  Tue Jan 11 11:10:17 2011
From: mauhfh at live.warwick.ac.uk (Mark Bell)
Date: Tue, 11 Jan 2011 10:10:17 +0000
Subject: [docs] itertools.count comment typo
Message-ID: <4D2C2C89.8000707@live.warwick.ac.uk>

Hi,

Just to let you know that there's a small typo in a comment in the 
itertools.count example at 
http://docs.python.org/library/itertools.html#itertools.count

def  count(start=0,  step=1):
     # count(10) -->  10 11 12 13 14 ...
     # count(2.5, 0.5) ->  3.5 3.0 4.5 ...

                                                            ^-- Wrong 
number here

Should be:

def  count(start=0,  step=1):
     # count(10) -->  10 11 12 13 14 ...
     # count(2.5, 0.5) ->  2.5 3.0 4.5 ..


Thanks,
Mark



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110111/6adf22a7/attachment.html>

From dennisonic at gmail.com  Wed Jan 12 16:22:19 2011
From: dennisonic at gmail.com (Dennis Prochniak)
Date: Wed, 12 Jan 2011 15:22:19 +0000
Subject: [docs] http://docs.python.org/_static/basic.css -- line 345 --
 makes the website inaccessible to me and probably other users using
 Hutchison 3G mbb
Message-ID: <4D2DC72B.8040005@gmail.com>

Hi,

For some reason when I try to view any docs.python.org page I am unable 
to do this due to a CSS error, the infrastructure of my ISP seems to be 
buggy. I found this out by wgeting basic.css and the download stopped at 
approx 79%, after I have diffed this with a full basic.css (fetched via 
a proxy) file I found out that it stops just after line 345. (missing 
delimiting semicolon)

This seems to be a problem of my ISP, it may affect other users that are 
using the same broadband service as me, which is 3G Broadband by 
Hutchison 3G UK.

The CSS also is invalid, so I would appreciate if you could fix this 
quickly, so I can comfortably continue coding in Python! Even accessing 
the docs site via proxy is not trivial (there seem to be other problems 
with my ISP)

Thanks,
denysonique



From chloe.henderson at webhostgear.com  Thu Jan 13 07:08:02 2011
From: chloe.henderson at webhostgear.com (Chloe Henderson)
Date: Thu, 13 Jan 2011 07:08:02 +0100
Subject: [docs] Follow up question about your website /extending/index.html
Message-ID: <5391e6cbdd8dc5c234451a6b81c77bf2@localhost.localdomain>

Hi, 

This is Chloe Henderson from web host gear. I am just writing to follow-up
on my first email about the proposal I am offering you. 
I am not sure If you get my email though. Is this the right contact to be
writing? 

Looking forward for your response!

Thanks, 
Chloe 
Web Host Gear



From georg at python.org  Thu Jan 13 08:29:53 2011
From: georg at python.org (Georg Brandl)
Date: Thu, 13 Jan 2011 08:29:53 +0100
Subject: [docs] http://docs.python.org/_static/basic.css -- line 345 --
 makes the website inaccessible to me and probably other users using
 Hutchison 3G mbb
In-Reply-To: <4D2DC72B.8040005@gmail.com>
References: <4D2DC72B.8040005@gmail.com>
Message-ID: <4D2EA9F1.2050309@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 12.01.2011 16:22, schrieb Dennis Prochniak:
> Hi,
> 
> For some reason when I try to view any docs.python.org page I am unable 
> to do this due to a CSS error, the infrastructure of my ISP seems to be 
> buggy. I found this out by wgeting basic.css and the download stopped at 
> approx 79%, after I have diffed this with a full basic.css (fetched via 
> a proxy) file I found out that it stops just after line 345. (missing 
> delimiting semicolon)
> 
> This seems to be a problem of my ISP, it may affect other users that are 
> using the same broadband service as me, which is 3G Broadband by 
> Hutchison 3G UK.
>
> The CSS also is invalid, so I would appreciate if you could fix this 
> quickly, so I can comfortably continue coding in Python! Even accessing 
> the docs site via proxy is not trivial (there seem to be other problems 
> with my ISP)

Hi Dennis,

first, I've added the semicolon, and it will be used in the next daily
rebuild of the docs.

However, I think the problem you're experiencing has another cause.
I cannot see why wget would care for CSS errors; it does not need to
look at the contents of the files it downloads.  It seems improbable
that the ISP would care for CSS errors either.

Also, the semicolon is by no means required by CSS, as you can see if
you enter the URI to basic.css in the W3C CSS validator.  There is one
"error" in the CSS, which is the use of the "overflow-y" property that
is not part of CSS 2.1 but supported on several modern browsers.

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk0uqfAACgkQN9GcIYhpnLCcGgCfb8M6+wvz0FfNYOl4dr3ViJgi
hNMAoJa2oKhynliWZMmIb71b8tN9CRpk
=LBxY
-----END PGP SIGNATURE-----

From georg at python.org  Thu Jan 13 08:31:37 2011
From: georg at python.org (Georg Brandl)
Date: Thu, 13 Jan 2011 08:31:37 +0100
Subject: [docs] itertools.count comment typo
In-Reply-To: <4D2C2C89.8000707@live.warwick.ac.uk>
References: <4D2C2C89.8000707@live.warwick.ac.uk>
Message-ID: <4D2EAA59.50500@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 11.01.2011 11:10, schrieb Mark Bell:
> Hi,
> 
> Just to let you know that there's a small typo in a comment in the
> itertools.count example at
> http://docs.python.org/library/itertools.html#itertools.count
> 
> def count(start=0, step=1):
>     # count(10) --> 10 11 12 13 14 ...
>     # count(2.5, 0.5) -> 3.5 3.0 4.5 ...
> 
>                                                            ^-- Wrong number here
> 
> Should be:
> 
> def count(start=0, step=1):
>     # count(10) --> 10 11 12 13 14 ...
>     # count(2.5, 0.5) -> 2.5 3.0 4.5 ..

Actually 2.5 3.0 3.5 :)

Thanks for the report!
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk0uqlkACgkQN9GcIYhpnLBpaQCglayz4vfqnVzcYNlOrM9vxaNn
dDMAnAzZvomazogTyIPxiJ8k0o/E2HkT
=AJLW
-----END PGP SIGNATURE-----

From auderoseline at yahoo.ca  Thu Jan 13 18:09:25 2011
From: auderoseline at yahoo.ca (Roseline Aude)
Date: Thu, 13 Jan 2011 09:09:25 -0800 (PST)
Subject: [docs] resignation  ?
Message-ID: <400802.69638.qm@web114105.mail.gq1.yahoo.com>

Hi, 
I have requested earlyer an opinion concerning a possible resignation . 
I have not reicived any clear directives.
Exceptionally, if i could be given my entire pension without penality, I would 
be very happy to support myself to university.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110113/7c44a9cc/attachment.html>

From report at bugs.python.org  Thu Jan 13 22:37:51 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 13 Jan 2011 21:37:51 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294954671.21.0.0580434394268.issue10893@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

But why? What's the reason for that? Why mislabel a type as a function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 22:40:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 21:40:21 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294954821.42.0.112491349166.issue10893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

staticmethod being a type or int being a function is really a CPython implementation detail.  If the docs say something is a class, it behaves as a class, you can subclass it and everything, and the other VMs implement it as a class, why would you want to consider the detail that it?s really a C function?

----------
nosy: +eric.araujo
stage:  -> committed/rejected
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 22:47:49 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 13 Jan 2011 21:47:49 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294955269.62.0.461861031932.issue10893@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

I'm really confused by your comment.

"int being a function is really a CPython implementation detail"

I don't understand this. I should be able to do isinstance(x, int) in all implementations of Python, no? So `int` must be a class across all Python implementation, no?

"why would you want to consider the detail that it?s really a C function?"

I don't want to consider the detail that int is a C function, I thought that int is a class and expected it to be marked :class:`int` in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:00:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 22:00:46 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294956046.59.0.992550470772.issue10893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, scratch the comment about int, it?s not been accurate for quite a number of years.  Going back to staticmethod, my point still applies: Follow what the docs say.

staticmethod is a type in CPython probably due to the way descriptors work; contextlib.closing is a class for simplicity and efficiency; both of these examples are irrelevant internal details, they?re marked up as functions, so you should treat them as functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:10:49 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 13 Jan 2011 22:10:49 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294956649.75.0.278266927201.issue10893@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

So if int is officially a class, why not start doing :class:`int` instead of :func:`int`?

"they?re marked up as functions, so you should treat them as functions."

Here, I've treated staticmethod as a function:

    >>> assert isinstance(staticmethod, types.FunctionType)
    Traceback (most recent call last):
      File "<pyshell#1>", line 1, in <module>
        assert isinstance(staticmethod, types.FunctionType)
    AssertionError

I get an error.

So I understand that you are using Sphinx's :func: role in a liberal way; You consider it okay to use it to mark anything that is callable, regardless of whether it's a function or a class. Am I right?

This looks to me like an abuse of Sphinx notation. When I read documentation I don't want to be second-guessing the author's intentions. If someone writes :func:`whatever` I expect `whatever` to be a function and not a class.

Perhaps we need a :callable: role?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:14:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Jan 2011 22:14:37 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294956877.43.0.0305330309263.issue10893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t have enough experience to make a judgment call here.  Raymond or Georg, can you?

----------
nosy: +georg.brandl
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:22:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 13 Jan 2011 22:22:46 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294957366.6.0.837890014617.issue10893@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That's just the way we do our markup.
Sorry, but this is a total non-issue.
You're trying to create finer distinctions
than the markup needs to support.

Besides, the distinction between types,
objects, callables, functions, instances,
descriptors and whatnot are much less
black and white than you might imagine.

----------
nosy: +rhettinger
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Thu Jan 13 23:29:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 13 Jan 2011 22:29:58 +0000
Subject: [docs] [issue10893] The docs mark staticmethod as a function
In-Reply-To: <1294837196.34.0.0437845342766.issue10893@psf.upfronthosting.co.za>
Message-ID: <1294957798.57.0.515667539822.issue10893@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fully agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10893>
_______________________________________

From report at bugs.python.org  Fri Jan 14 07:04:07 2011
From: report at bugs.python.org (Jean Jordaan)
Date: Fri, 14 Jan 2011 06:04:07 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>


New submission from Jean Jordaan <jean.jordaan at gmail.com>:

http://docs.python.org/library/pdb.html states "The run_* functions and set_trace() are aliases" but the functions in question are "run", "runeval" and "runcall": no underscores.

----------
assignee: docs at python
components: Documentation
messages: 126231
nosy: docs at python, neaj
priority: normal
severity: normal
status: open
title: Doc type: "run_*" instead of "run*" on http://docs.python.org/library/pdb.html
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:15:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 07:15:38 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294989338.48.0.782618461074.issue10902@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky
stage:  -> needs patch
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:27:49 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 07:27:49 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294990069.44.0.815747010298.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Here's a patch that fixes it to "run*". 
If it's OK I will commit it and port to py3k where the problem also exists

----------
keywords: +patch
nosy: +ncoghlan
Added file: http://bugs.python.org/file20401/issue10902.py27.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 08:39:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Jan 2011 07:39:16 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294990756.18.0.91958770586.issue10902@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:13:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:13:44 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294992824.52.0.953342287529.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed to release27-maint r87992

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:21:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Jan 2011 08:21:31 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294993291.04.0.199549691092.issue10902@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's the wrong way of porting though... py3k first, then 2.7 and 3.1.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:26:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:26:09 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294993569.31.0.43704152575.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed to py3k r87993

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:30:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Jan 2011 08:30:24 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294993824.12.0.595310216315.issue10902@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, true - I forgot svnmerge for 27-maint was based on the py3k branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:40:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:40:54 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294994454.71.0.541390412309.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg, thanks - will keep that in mind. Here I started with 2.7 since this is what the user reported on. I plan to have it committed to all 3 branches today anyhow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From report at bugs.python.org  Fri Jan 14 09:56:03 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 14 Jan 2011 08:56:03 +0000
Subject: [docs] [issue10902] Doc type: "run_*" instead of "run*"
	on	http://docs.python.org/library/pdb.html
In-Reply-To: <1294985047.82.0.945168102626.issue10902@psf.upfronthosting.co.za>
Message-ID: <1294995363.09.0.83905659896.issue10902@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed to release31 in r87995 (with svnmerge)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10902>
_______________________________________

From reveley at gmail.com  Thu Jan 13 18:19:56 2011
From: reveley at gmail.com (Colin Reveley)
Date: Thu, 13 Jan 2011 17:19:56 +0000
Subject: [docs] chaos
Message-ID: <AANLkTikADOg_z9QO154Pw7VxUk89bH0zVXnSJ2gLZ++j@mail.gmail.com>

here:

http://docs.python.org/library/turtle.html#demo-scripts

you say that chaotic behavior "proves that you cannot trust a computer's
computations"

well, the opposite is the case. it proves you can trust computations
absolutely. the computations are deterministic. they are correct. that's how
the lorenz attractor was discovered.

you do need to know what a computer does (and to what) when it computes, and
what it doesn't, and how to interpret it.

it's misleading to say that computation is untrustworthy. computation is a
particular thing, that's all.

it might seem pedantic but I think it's a much more interesting and
important thing for a student to think about than "untrustworthy".

which is just false anyway. as you know I'm sure. I'm not trying to be
patronising.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110113/4a9f3720/attachment-0001.html>

From will.flanagan at Colorado.EDU  Fri Jan 14 01:03:53 2011
From: will.flanagan at Colorado.EDU (Will Flanagan)
Date: Thu, 13 Jan 2011 17:03:53 -0700 (MST)
Subject: [docs] Section 2.1.2 tutorial question
Message-ID: <20110113170353.AEQ82286@joker.int.colorado.edu>

Hi,

I am reading the second page of your tutorial:
http://docs.python.org/tutorial/interpreter.html

When we arrive at this example in section 2.1.2, it is not clear how to get to the secondary prompt:

>>> the_world_is_flat = 1
>>> if the_world_is_flat:
...     print "Be careful not to fall off!"
...
Be careful not to fall off!

If I type "if the_world_is_flat:" and hit enter, an error is generated. How do I get to the secondary prompt for the next line of the example?

I am this doing this tutorial with a bash shell.

Many thanks in advance,
Will

From davec at adobe.com  Fri Jan 14 00:41:01 2011
From: davec at adobe.com (David Cotter)
Date: Thu, 13 Jan 2011 15:41:01 -0800
Subject: [docs] plistlib doc
Message-ID: <80C1C5FF-B016-43AE-B639-87447D81AEDF@adobe.com>

http://docs.python.org/library/plistlib.html

does not list all the available methods of each new class

please document:

for example:
what are the methods of "Dict" ?
'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update', 'values'
these are not documented

and what about all the other classes?

------------------------------------------------------------------------------
David M. Cotter                                  mailto:david.cotter at adobe.com
Interface Surgeon, After Effects            http://www.adobe.com/aftereffects/
Adobe Systems, Inc.                                             (206) 675-7437

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110113/aa6d36f5/attachment-0001.html>

From report at bugs.python.org  Fri Jan 14 11:27:20 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Fri, 14 Jan 2011 10:27:20 +0000
Subject: [docs] [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>


New submission from Peter Kleiweg <pkleiweg at xs4all.nl>:

The environment variable PYTHONIOENCODING should be documented in de manpage

----------
assignee: docs at python
components: Documentation, IO
messages: 126252
nosy: docs at python, pebbe
priority: normal
severity: normal
status: open
title: PYTHONIOENCODING is not in manpage
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10904>
_______________________________________

From report at bugs.python.org  Fri Jan 14 15:14:36 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 14 Jan 2011 14:14:36 +0000
Subject: [docs] [issue10906] wsgiref should mention that CGI scripts usually
	expect	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/wsgiref.html#wsgiref.util.guess_scheme

The documentation says servers typically set HTTPS variable to a value of ?1? or ?yes?, when a request is received via SSL, but CGI tutorials, IIS and Apache set this to ?on?.

Misleading documentation may be the reason of the bug with mod_wsgi that changes Apache's variable from ?on? to ?1? - https://issues.apache.org/bugzilla/show_bug.cgi?id=50581

The documentation should at least stress that ?on? is the mainstream value for this variable. It will help to mention at least one popular server that returns ?1?.

----------
assignee: docs at python
components: Documentation
messages: 126263
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: wsgiref should mention that CGI scripts usually expect HTTPS variable to be set to 'on'
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From eliben at gmail.com  Fri Jan 14 15:19:46 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Fri, 14 Jan 2011 16:19:46 +0200
Subject: [docs] two spaces after a period
Message-ID: <AANLkTim4W7ji7VGr7DBMaz0NXqbm5xFKPFmUcTQft33B@mail.gmail.com>

An interesting article that was posted on Hacker News today:
http://www.slate.com/id/2281146/pagenum/all/

Inside it links to a Q&A of the esteemed Chicago Manual of Style:
http://www.chicagomanualofstyle.org/CMS_FAQ/OneSpaceorTwo/OneSpaceorTwo03.html

Looks relevant to the way our .rst files are usually written :-)
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110114/fd5cf6a8/attachment.html>

From fdrake at acm.org  Fri Jan 14 15:28:14 2011
From: fdrake at acm.org (Fred Drake)
Date: Fri, 14 Jan 2011 09:28:14 -0500
Subject: [docs] two spaces after a period
In-Reply-To: <AANLkTim4W7ji7VGr7DBMaz0NXqbm5xFKPFmUcTQft33B@mail.gmail.com>
References: <AANLkTim4W7ji7VGr7DBMaz0NXqbm5xFKPFmUcTQft33B@mail.gmail.com>
Message-ID: <AANLkTimt6k3-j45HbWTery0_pT7cAXy1QuunqNYnTZxZ@mail.gmail.com>

On Fri, Jan 14, 2011 at 9:19 AM, Eli Bendersky <eliben at gmail.com> wrote:
> Looks relevant to the way our .rst files are usually written :-)

This is an ancient argument (in computing years), and will never be
resolved satisfactorily.

There are cultural biases and software limitations ("bugs") that
ensure this will be the case for a long time to come.

I don't see a need for this to get argued again.  Consistency within
the docs would be nice, but probably isn't going to happen.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

From georg at python.org  Fri Jan 14 15:33:14 2011
From: georg at python.org (Georg Brandl)
Date: Fri, 14 Jan 2011 15:33:14 +0100
Subject: [docs] two spaces after a period
In-Reply-To: <AANLkTim4W7ji7VGr7DBMaz0NXqbm5xFKPFmUcTQft33B@mail.gmail.com>
References: <AANLkTim4W7ji7VGr7DBMaz0NXqbm5xFKPFmUcTQft33B@mail.gmail.com>
Message-ID: <4D305EAA.90107@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 14.01.2011 15:19, schrieb Eli Bendersky:
> An interesting article that was posted on Hacker News today:
> http://www.slate.com/id/2281146/pagenum/all/
> 
> Inside it links to a Q&A of the esteemed Chicago Manual of Style:
> http://www.chicagomanualofstyle.org/CMS_FAQ/OneSpaceorTwo/OneSpaceorTwo03.html
> 
> Looks relevant to the way our .rst files are usually written :-)

Well, this is mostly irrelevant because our source files are (mostly)
not meant to be read, but to be transformed to some output format.
And in none of the output formats that we have, the exact amount of
whitespace in non-literal text is preserved.

Why I use two spaces is simple: it helps my editor fill the paragraphs,
and it helps me recognize when I've written sentence monsters. I won't
kill anyone who doesn't use this convention, but I won't promise not
to reformat any text I'm working on either.

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEUEARECAAYFAk0wXqoACgkQN9GcIYhpnLAcvQCgmCchb8bATM9f1jwIyrYOHwxw
bxYAmPnNsVMKNXKxQFAF3NkiR2/f+oA=
=Tbqd
-----END PGP SIGNATURE-----

From report at bugs.python.org  Fri Jan 14 19:37:30 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 18:37:30 +0000
Subject: [docs] [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295030250.48.0.797221882548.issue10904@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What "manpage" are you reporting?  In py3k branch,

$ groff -Tascii -man Misc/python.man
..

       PYTHONIOENCODING
              If this is set before running the interpreter, it overrides  the
              encoding  used  for stdin/stdout/stderr, in the syntax encoding-
              name:errorhandler The errorhandler part is optional and has  the
              same meaning as in str.encode. For stderr, the errorhandler
               part is ignored; the handler will always be 'backslashreplace'.
..

There is a missing period after the first sentence, but otherwise LGTM.

It is also documented in the reST manual and python -h help, 

http://docs.python.org/dev/using/cmdline.html#envvar-PYTHONIOENCODING

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10904>
_______________________________________

From sandro.tosi at gmail.com  Fri Jan 14 19:40:18 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 14 Jan 2011 19:40:18 +0100
Subject: [docs] Section 2.1.2 tutorial question
In-Reply-To: <20110113170353.AEQ82286@joker.int.colorado.edu>
References: <20110113170353.AEQ82286@joker.int.colorado.edu>
Message-ID: <AANLkTikn12tYirvBeU9S0VUh4y8WSp36zc7xRiVBqeye@mail.gmail.com>

Hi Will,

On Fri, Jan 14, 2011 at 01:03, Will Flanagan <will.flanagan at colorado.edu> wrote:
> Hi,
>
> I am reading the second page of your tutorial:
> http://docs.python.org/tutorial/interpreter.html
>
> When we arrive at this example in section 2.1.2, it is not clear how to get to the secondary prompt:
>
>>>> the_world_is_flat = 1
>>>> if the_world_is_flat:
> ... ? ? print "Be careful not to fall off!"
> ...
> Be careful not to fall off!
>
> If I type "if the_world_is_flat:" and hit enter, an error is generated. How do I get to the secondary prompt for the next line of the example?
>
> I am this doing this tutorial with a bash shell.

Ok, the problem is that example is expected to be executed inside a
python interpreter, so from your bash prompt type 'python' and you'll
have the interpreter waiting for your commands.

As a general rule, when you see the '>>>' prompt, that means you're
inside a running python interpreter.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Fri Jan 14 19:41:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Jan 2011 18:41:41 +0000
Subject: [docs] [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295030501.64.0.646040559636.issue10904@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the second thought, maybe "de manpage" is not a misspelling of "the manpage", but a reference to a German locale manpage?  I don't think python.org releases include manpage translations.  You may need to report it to your system vendor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10904>
_______________________________________

From report at bugs.python.org  Fri Jan 14 20:23:29 2011
From: report at bugs.python.org (Peter Kleiweg)
Date: Fri, 14 Jan 2011 19:23:29 +0000
Subject: [docs] [issue10904] PYTHONIOENCODING is not in manpage
In-Reply-To: <1295000840.3.0.0583509737047.issue10904@psf.upfronthosting.co.za>
Message-ID: <1295033009.45.0.545947806979.issue10904@psf.upfronthosting.co.za>


Peter Kleiweg <pkleiweg at xs4all.nl> added the comment:

Ah, I see it's fixed in the latest version.

The variable PYTHONIOENCODING was present at least since Python 2.6.4, but not documented in the manpage of versions 2.6.4, 2.7 and 3.1.1.
I thought I had recent versions, but I see now versions 2.7.1 and 3.1.3, and they both have the variable in the manpage.

I'm sorry for the inconveniance.

----------
resolution:  -> out of date
status: open -> closed
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10904>
_______________________________________

From report at bugs.python.org  Sat Jan 15 00:46:49 2011
From: report at bugs.python.org (Radiant)
Date: Fri, 14 Jan 2011 23:46:49 +0000
Subject: [docs] [issue6771] Curses.wrapper: documentation/implementation
	error
In-Reply-To: <1251099236.05.0.0799674766136.issue6771@psf.upfronthosting.co.za>
Message-ID: <1295048808.99.0.914974570163.issue6771@psf.upfronthosting.co.za>


Radiant <abbconsulting at gmail.com> added the comment:

Adding version=3.2 and component=Documentation.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +Radiant, docs at python
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6771>
_______________________________________

From report at bugs.python.org  Sat Jan 15 02:01:00 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sat, 15 Jan 2011 01:01:00 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

PyObject_RichCoareBool is, according to the documentation in trunk (Doc\c-api\object.rst), exactly the same as PyObject_RichCompare, except it 1, 0, or -1 for error, false, and true respectively. However, it differs in behavior by both that, and also by assuming that identity implies equality. This noted in a two year-old ML post (sadly, no bug report was posted as best as I can find): http://mail.python.org/pipermail/python-list/2009-March/1195170.html

Ideally PyObject_RichCompareBool should probably be named something else, since it can no longer be used, strictly, as "PyObject_RichCompare, but returning a C bool" (or, rather, a C int). Some suggestions were offered in the mailing list thread above.

I'm filing this as a documentation bug because I find that outcome unlikely. At least the documentation should note the difference in behavior, so that people do not accidentally write C code that does not behave as intended.

This issue is related to, but different from issue 4296, which objected to the new container behavior created by the change to PyObject_RichCompareBool. My only objection here is that the latter change does not appear to be documented.

I would supply a patch for the tests, but PyObject_RichCompareBool is apparently not directly tested anywhere, just tested obliquely through testing the containment operator, and this was changed by the same commit that changed PyObject_RichCompareBool. I don't know how to word the (very small!) change to the docs.

----------
assignee: docs at python
components: Documentation
messages: 126306
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From will.flanagan at Colorado.EDU  Sat Jan 15 00:55:35 2011
From: will.flanagan at Colorado.EDU (Will Flanagan)
Date: Fri, 14 Jan 2011 17:55:35 -0600
Subject: [docs] Section 2.1.2 tutorial question
In-Reply-To: <AANLkTikn12tYirvBeU9S0VUh4y8WSp36zc7xRiVBqeye@mail.gmail.com>
References: <20110113170353.AEQ82286@joker.int.colorado.edu>
	<AANLkTikn12tYirvBeU9S0VUh4y8WSp36zc7xRiVBqeye@mail.gmail.com>
Message-ID: <43345BA0-A91A-4D9F-BF71-A38720CC96B8@colorado.edu>

Hi Sandro,

Thank you for the reply.

I was in fact inside a python interpreter (that I accessed from a bash  
shell).

I am not sure why I wasn't arriving at the secondary prompt yesterday  
when trying that example (and others), but it works fine today after  
retrying. Sorry about the inconvenience.

Thanks,
Will

On Jan 14, 2011, at 12:40 PM, Sandro Tosi wrote:

> Hi Will,
>
> On Fri, Jan 14, 2011 at 01:03, Will Flanagan <will.flanagan at colorado.edu 
> > wrote:
>> Hi,
>>
>> I am reading the second page of your tutorial:
>> http://docs.python.org/tutorial/interpreter.html
>>
>> When we arrive at this example in section 2.1.2, it is not clear  
>> how to get to the secondary prompt:
>>
>>>>> the_world_is_flat = 1
>>>>> if the_world_is_flat:
>> ...     print "Be careful not to fall off!"
>> ...
>> Be careful not to fall off!
>>
>> If I type "if the_world_is_flat:" and hit enter, an error is  
>> generated. How do I get to the secondary prompt for the next line  
>> of the example?
>>
>> I am this doing this tutorial with a bash shell.
>
> Ok, the problem is that example is expected to be executed inside a
> python interpreter, so from your bash prompt type 'python' and you'll
> have the interpreter waiting for your commands.
>
> As a general rule, when you see the '>>>' prompt, that means you're
> inside a running python interpreter.
>
> Cheers,
> -- 
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi


From report at bugs.python.org  Sat Jan 15 10:00:41 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 09:00:41 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295082041.54.0.463012724202.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I agree that the difference in behavior between the two functions is unfortunate, but that's unlikely to change now.

The least we can do is make the documentation precise. I'm attaching a proposed patch to Doc/c-api/object.rst

Nick/Terry/Georg - if this looks OK I can commit.

----------
keywords: +easy, patch
nosy: +eli.bendersky, ncoghlan, terry.reedy -Devin Jeanpierre
type:  -> behavior
Added file: http://bugs.python.org/file20413/issue10912.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 10:17:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 15 Jan 2011 09:17:03 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295083023.55.0.626005247168.issue10912@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sure.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 11:23:56 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 10:23:56 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295087036.07.0.463337224401.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed the fix to py3k in r88009

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 11:35:10 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 10:35:10 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295087710.53.0.586489224309.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Backport to release31 branch in r88010

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:32:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Jan 2011 14:32:49 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295101969.72.0.488169028743.issue10912@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the record, the gory details as to *why* RichCompareBool makes more assumptions as to the meaning of equality than the basic RichCompare function can be found in issue 4296 (I just found that issue myself by looking at Mark's response to the python-list thread).

It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:37:08 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 15 Jan 2011 14:37:08 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295102228.06.0.894522784472.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Nick, I read the protocol of issue 4296 and I understand the reasoning behind the code, but I still think the naming is mightily confusing. Two distinct changes went into a single function (A) Return -1/0/+1 instead of PyObject and (B) the id() shortcut, and its name is inappropriate. Were an API change feasible, some other naming would be better.

> "It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function."

Do you mean write it down in the docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 15:51:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Jan 2011 14:51:01 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295103061.07.0.621738264434.issue10912@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, to prevent perfectly reasonable "why" questions, it is probably worth providing a little extra justification as an addendum to your new note (which is already an improvement on the complete silence on the topic that existed before).

A possible addition:

"... This assumption allows invariants such as "x in [x]" to be more easily guaranteed by the interpreter. If the assumption is not valid for a given use case, call PyObject_RichCompare() directly instead of using this function."

For 3.3, it *may* make sense to provide a PyObject_RichCompareBoolEx() function which includes an additional "reflexive" parameter. Then the existing PyObject_RichCompareBool() semantics would just be the new function with the reflexive argument set to 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sat Jan 15 20:26:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 Jan 2011 19:26:34 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295119594.33.0.186660712981.issue10912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Devin Jeanpierre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 00:10:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Jan 2011 23:10:49 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295133049.75.0.13452899127.issue10912@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 00:23:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Jan 2011 23:23:19 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295133799.91.0.898119061076.issue10912@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1 on PyObject_RichCompareBoolEx() for 3.3 -- it is simply an invitation to shoot yourself (or others) in the foot.

I've not seen real world code using bool(a==b) or its C equivalent, so it's hard to believe that there is a use case here (unless you're trying to commit atrocities with NaN-like objects).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 00:52:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 15 Jan 2011 23:52:49 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295135569.26.0.0616941834765.issue10912@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed. I was actually wondering if it would be worth trying to write up a section for the language reference to describe the cases where a Python implementation is *expected* to assume reflexive equality. We (IMO) have a problem at the moment due to situations like:

>>> class PyContains(list):
...   def __contains__(self, obj):
...     return any(x==obj for x in self)
... 
>>> nan = float("nan")
>>> nan in [nan]
True
>>> nan in PyContains([nan])
False

This is a bug in the __contains__ definition (it should use "x is obj or x == obj" rather than just the latter expression) but there isn't anything in the language reference to point that out.

Assuming reflexive equality in some places and not in others based on the underlying implementation language is going to be a source of subtle bugs relating to types like float and decimal.Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 01:50:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Jan 2011 00:50:10 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295139010.57.0.758659856522.issue10912@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If something needs to be written about NaNs or other invariant destroying objects, perhaps a FAQ entry would suffice (perhaps referencing http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ ).

----------
assignee: docs at python -> rhettinger
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 06:43:57 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 16 Jan 2011 05:43:57 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295156637.54.0.324126393717.issue10912@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Raymond, 
I initially set "easy" on this issue because I considered it a documentation issue, not the place to resolve the harder debate of the semantics of these functions. Perhaps I was wrong?

Also, I agree with Nick that the difference must be further clarified in "stronger words". If there's no debate on this issue, I will commit a fix after the freeze is over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 07:01:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Jan 2011 06:01:33 +0000
Subject: [docs] [issue10912] PyObject_RichCompare differs in behaviour
	from	PyObject_RichCompareBool ;
	difference not noted in documentation
In-Reply-To: <1295053260.1.0.0634834443195.issue10912@psf.upfronthosting.co.za>
Message-ID: <1295157693.01.0.974517707754.issue10912@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Yes, it is a doc issue but sometimes those aren't easy to get right (in terms of being beneficial to the reader and in good alignment with the design intentions).  Please attach the doc patch you want to go in and I'll review it sometime the freeze.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10912>
_______________________________________

From report at bugs.python.org  Sun Jan 16 08:50:08 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 07:50:08 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://www.python.org/dev/peps/pep-0333/#id7

Link to CGI spec is broken.

----------
assignee: docs at python
components: Documentation
messages: 126361
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: PEP 333 link to CGI specification is broken
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 10:57:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 16 Jan 2011 09:57:38 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295171858.61.0.0787828990538.issue10917@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r88045 (also in PEP 3333).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 21:01:49 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 20:01:49 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295208109.92.0.810417676682.issue10917@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

w00t

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:18:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 16 Jan 2011 21:18:00 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295212680.74.0.0314135093219.issue10917@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not sure I understand you...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:30:21 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 21:30:21 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295213421.74.0.49946260318.issue10917@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Nevermind. It's just another word for gr8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:31:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Jan 2011 21:31:59 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295213519.36.0.859150848618.issue10917@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, that really grates on the eyes.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 22:35:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 16 Jan 2011 21:35:35 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295213421.74.0.49946260318.issue10917@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=TD+ggk48QZKgCt7tX0LfgVHrM+kBdQhAhV6dW@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/1/16 anatoly techtonik <report at bugs.python.org>:
>
> anatoly techtonik <techtonik at gmail.com> added the comment:
>
> Nevermind. It's just another word for gr8.

Well, it really grates on the eyes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Sun Jan 16 23:01:48 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 16 Jan 2011 22:01:48 +0000
Subject: [docs] [issue10917] PEP 333 link to CGI specification is broken
In-Reply-To: <1295164208.27.0.610516311421.issue10917@psf.upfronthosting.co.za>
Message-ID: <1295215307.95.0.830768119533.issue10917@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

No surprises. Core Python community is so old that it is unlikely that people there ever experienced online gameplay. The only online game they've ever installed was probably EVE Online and if they've installed it - that was just because Stackless wiki is not sane enough in describing all awesomeness of this Python flavor. But it is more likely in this situation that they've just watched CCP videos. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10917>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:46:38 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:46:38 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295228798.1.0.908043955064.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Regarding problem #4, it actually appears that returning local time is the right thing to do, since it matches the behavior of Time2Internaldate().  Returning UTC, as the doc states, would potentially break IMAP append() that can include an internaldate possibly returned from Internaldate2tuple() in typical usage (like when copying messages).  In this case, the doc is wrong on Internaldate2tuple().

I have attached a new patch to both the code and doc that replaces the old patch.  I now return localtime rather than gmtime, but other than that, the DST fix remains the same and now handles the cases near DST changes correctly.

Ultimately, it might be desirable to be able always stay in UTC, so perhaps adding UTC variants of both Internaldate2tuple() and Time2Internaldate() (and a UTC option to append()) would be a good enhancement for later.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) -> imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
Added file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:47:26 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:47:26 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295228846.25.0.669583566393.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:52:00 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:52:00 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295229120.03.0.250518468668.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
components:  -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 02:53:07 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 01:53:07 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295229187.09.0.862251226678.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


----------
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:25:31 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 17 Jan 2011 14:25:31 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295274331.77.0.292836778828.issue10921@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:58:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 14:58:13 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295276293.91.0.957116515731.issue10921@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: docs at python -> 
nosy: +belopolsky, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 15:58:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Jan 2011 14:58:18 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295276298.35.0.913763581995.issue10921@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 18:40:32 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 17 Jan 2011 17:40:32 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295286032.26.0.275614158577.issue10921@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> 1. It crashes with "KeyError". ...

I assume this means it raises a KeyError when given a bytes object as an argument.

>>> Internaldate2tuple(b'INTERNALDATE "01-Jan-2000 12:00:00 +0000"')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Lib/imaplib.py", line 1326, in Internaldate2tuple
    mon = Mon2num[mo.group('mon')]
KeyError: b'Jan'

> 2.  The sign of the TZ offset ..

Once Mon2num is fixed, the sign error show up as follows:

>>> Internaldate2tuple(b'INTERNALDATE "01-Jan-2000 12:00:00 +0500"')[3:6]
(2, 0, 0)
>>> Internaldate2tuple(b'INTERNALDATE "01-Jan-2000 12:00:00 -0500"')[3:6]
(2, 0, 0)

 
This looks like a 2 to 3 port oversight and we can probably fix it in RC.  Georg?

----------
nosy: +georg.brandl
stage: patch review -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Mon Jan 17 19:01:12 2011
From: report at bugs.python.org (Joe Peterson)
Date: Mon, 17 Jan 2011 18:01:12 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() crashes,
	does not handle negative TZ offsets, does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295287272.57.0.518096435974.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

> I assume this means it raises a KeyError when given a bytes object as an argument.

Yes, a KeyError is raised when arg is bytes, but passing a string also fails (raising TypeError).  The latter might also be a separate bug, in that strings cannot be passed as they could be in Python 2.

> This looks like a 2 to 3 port oversight and we can probably fix it in RC.

Probably, since many strings have been changed to bytes elsewhere in the file.

BTW, I just attached a patch for Python 2.7 that fixes the subset of non-py3k-related issues.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file20426/imaplib_Internaldate2tuple_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:07:39 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:07:39 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295312858.6.0.677793191669.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Added fix for ParseFlags (another string/bytes issue) and now accept strings as args to ParseFlags and Internaldate2tuple.

Also added unit tests for changes.

----------
assignee:  -> docs at python
components: +Tests
title: imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly -> imaplib: Internaldate2tuple() string/bytes issues, does not handle negative TZ offsets, does not handle DST correctly
Added file: http://bugs.python.org/file20430/imaplib_Internaldate2tuple_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:22:25 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:22:25 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295313745.05.0.484922971245.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:22:34 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:22:34 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295313754.86.0.162250713265.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20430/imaplib_Internaldate2tuple_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:22:51 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:22:51 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295313771.3.0.613405322327.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20431/imaplib_Internaldate2tuple_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:35:46 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:35:46 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295314546.57.0.0833733690144.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Removed file: http://bugs.python.org/file20426/imaplib_Internaldate2tuple_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 02:36:03 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 01:36:03 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295314563.6.0.432390803591.issue10921@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20432/imaplib_Internaldate2tuple_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 04:18:47 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 18 Jan 2011 03:18:47 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295320727.28.0.261389654.issue10921@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There are at least 3 issues here: a documentation issue, a py3k bug and at least one feature request.  Given that the logistics are different for different kinds of issues, I think it would be best to split them on the tracker.  Here is how I see what is being proposed:

1. Internaldate2tuple is documented to return UTC timetuple, but implemented to return local time (ignoring the DST issues.)  The proposal is to change the documentation.

2. There are a couple of str vs bytes bugs that obviously need to be fixed.

3. The proposed patch also make both str and bytes acceptable as Internaldate2tuple argument.

As discussed in issue 9864, it would be best if datetime formatting and parsing routines would operate on datetime objects.  Something along the lines of


def parseinternaldate(datestr):
    return datetime.strptime(datestr, "%d-%b-%Y %H:%M:%S %z")

def formatinternaldate(dateobj):
    return dateobj.strftime("%d-%b-%Y %H:%M:%S %z")

The above uses recently added timezone support in datetime module.

There is still a problem, though.  The code above would only work as expected in the C locale, but Time2Internaldate already has this limitation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 05:19:14 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 04:19:14 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295324354.11.0.617179618987.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

>There are at least 3 issues here: a documentation issue, a py3k bug and at least one feature request.

Which is a feature request?  In these patches, I am attempting to fix the DST problems and regain the previous behavior in Python 2.  Are you talking about the ability to accept a string vs. a bytes object?

> 1. Internaldate2tuple is documented to return UTC timetuple, but implemented to return local time (ignoring the DST issues.)  The proposal is to change the documentation.

I prefer UTC, so this is a bit of a shame, I agree, but the use of the pervious interfaces assumed localtime, so changing to UTC would definitely break existing code.  I do think it would be nice to extend this to deal with UTC instead, but in this patch, I am only trying to retain current functionality.

2. There are a couple of str vs bytes bugs that obviously need to be fixed.

> 3. The proposed patch also make both str and bytes acceptable as Internaldate2tuple argument.

True, but given the new role of str and bytes, it is unclear what existing code would try to pass.

> As discussed in issue 9864, it would be best if datetime formatting and parsing routines would operate on datetime objects.

I can see that redoing some of this would be a good idea.  But I am only trying to keep the existing stuff from being broken in this patch.  I agree that the interfaces could be a lot better, and I would indeed like to see it improved (and I am willing to help with doing that).

> There is still a problem, though.  The code above would only work as expected in the C locale, but Time2Internaldate already has this limitation.

As long as we assume strings passed are ASCII, it should work.  And email headers should be ASCII (although I have seen some really weird deviations from this on old emails).  It's not perfect, certainly, and going forward, the IMAP lib could be tightened up.  Maybe this first patch could be thought of as a step, at least fixing what is broken until improved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:46:08 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 13:46:08 +0000
Subject: [docs] [issue10934] imaplib: Internaldate2tuple() is documented to
	return	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>


New submission from Joe Peterson <joe at skyrush.com>:

Patched documentation for Internaldate2tuple() to correctly state it returns local time.

Also, Time2Internaldate() (its inverse) did not state that it needs local time as input, so patched this as well.

Patches for 3.2 and 2.7 are attached.

----------
assignee: docs at python
components: Documentation
files: imaplib_Internaldate2tuple_doc_python32.patch
keywords: patch
messages: 126463
nosy: docs at python, lavajoe
priority: normal
severity: normal
status: open
title: imaplib: Internaldate2tuple() is documented to return UTC, but it returns local time
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20438/imaplib_Internaldate2tuple_doc_python32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:46:20 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 13:46:20 +0000
Subject: [docs] [issue10934] imaplib: Internaldate2tuple() is documented to
	return	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295358380.97.0.107270944526.issue10934@psf.upfronthosting.co.za>


Changes by Joe Peterson <joe at skyrush.com>:


Added file: http://bugs.python.org/file20439/imaplib_Internaldate2tuple_doc_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Tue Jan 18 14:59:46 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 13:59:46 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295359186.67.0.3010059245.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

I have started splitting these up as recommended.  First one (documentation) is: issue 10934.  I will split out more later today...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 16:10:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 15:10:01 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295363400.96.0.179462943951.issue10921@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If I understand correctly, what Alexander means by "only work in the C locale" is that both strptime and strftime are locale dependent, and so if the locale is something other than C it may fail to parse the month name and may generate a non-standard month name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:12:04 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Tue, 18 Jan 2011 19:12:04 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>


New submission from Christopher Dunn <cdunn2001 at gmail.com>:

This is an easy one.

When I zoom my browser in (with Ctrl+ or Apple+) the left-side navigation margin gets bigger and bigger, pushing the useful text off the screen. That has bothered me (and anyone else with 40+ year old eyes) ever since the switch to the newest doc format with Sphinx.

There is no fix that will satisfy everyone. People with perfect vision might like to zoom out (with Ctrl- or Apple-), since the margin currently gets smaller and smaller. But we need a compromise.

The relevant CSS, in default.css, is this:

 div.bodywrapper {
    margin: 0 0 0 230px;
 }

If instead it were something like this:

 div.bodywrapper {
    margin: 0 0 0 10%;
 }

then at least the navigation margin would stay the same size always.

If you really want it to grow and shrink, then you need some sort of javascript control of its position.

----------
assignee: docs at python
components: Documentation
messages: 126477
nosy: cdunn2001, docs at python
priority: normal
severity: normal
status: open
title: Simple CSS fix for left margin at docs.python.org
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:26:19 2011
From: report at bugs.python.org (Humberto Diogenes)
Date: Tue, 18 Jan 2011 19:26:19 +0000
Subject: [docs] [issue10938] Undocumented option for datetime.strftime: %s
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>


New submission from Humberto Diogenes <humberto at digi.com.br>:

On some systems, datetime.strftime() accepts a %s format string that returns epoch / UNIX timestamp, but this behavior is not documented at http://docs.python.org/library/datetime.html

Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.datetime.now().strftime('%s')
'1295376929'

----------
assignee: docs at python
components: Documentation
messages: 126481
nosy: docs at python, hdiogenes
priority: normal
severity: normal
status: open
title: Undocumented option for datetime.strftime: %s
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:38:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 19:38:35 +0000
Subject: [docs] [issue10938] Undocumented option for datetime.strftime: %s
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295379515.04.0.22327392443.issue10938@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As you say, "on some systems".  The variation is documented, and the documented codes are documented as being just those required by the C standard.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Tue Jan 18 20:41:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 18 Jan 2011 19:41:48 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295379708.77.0.431735022158.issue10936@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Tue Jan 18 21:54:10 2011
From: report at bugs.python.org (Humberto Diogenes)
Date: Tue, 18 Jan 2011 20:54:10 +0000
Subject: [docs] [issue10938] Undocumented option for datetime.strftime: %s
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295384049.67.0.225342884619.issue10938@psf.upfronthosting.co.za>


Humberto Diogenes <humberto at digi.com.br> added the comment:

David, as discussed on the IRC channel: maybe we could just add pointers to the OS-specific docs. Something like:

"""
If you want to use platform-specific format strings, search for strftime in your OS documentation (`man strftime` on POSIX systems).

Linux: http://www.kernel.org/doc/man-pages/online/pages/man3/strftime.3.html

Mac OS: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/strftime.3.html
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Tue Jan 18 22:26:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 18 Jan 2011 21:26:51 +0000
Subject: [docs] [issue10938] Provide links to system specific strftime/ptime
	docs
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1295386011.83.0.139701762901.issue10938@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

All right, I'll open it back up for that suggestion (I've changed the title accordingly) and let the docs folks decide.  The most useful link would be one to the relevant Windows documentation, since that's the hardest one to find.

Although this scheme avoids the problem of having to maintain a list of 'extra' format codes, it does have one of the same problems that doing so would have: the supported codes may change from OS version to OS version, and do we maintain the links accordingly?  The mitigating factor is that I don't think the supported codes do change much.

----------
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
title: Undocumented option for datetime.strftime: %s -> Provide links to system specific strftime/ptime docs
type: behavior -> feature request
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10938>
_______________________________________

From report at bugs.python.org  Wed Jan 19 00:49:53 2011
From: report at bugs.python.org (Joe Peterson)
Date: Tue, 18 Jan 2011 23:49:53 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295394593.64.0.688586347.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Two more issues split out into their own issues:

issue 10939 (bytes/str issues)
issue 10941 (DST handled incorrectly)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:12:30 2011
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Wed, 19 Jan 2011 00:12:30 +0000
Subject: [docs] [issue10942] xml.etree.ElementTree.tostring returns type
	bytes, expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>


New submission from J_Tom_Moon_79 <jtm.moon.forum.user+python at gmail.com>:

method xml.etree.ElementTree.tostring from module returns type bytes.
The documentation reads
"""Returns an encoded string containing the XML data."""
(from http://docs.python.org/py3k/library/xml.etree.elementtree.html#xml.etree.ElementTree.tostring as of 2011-01-18)

=======================================================
Here is a test program:
-------------------------------------------------------
#!/usr/bin/python
# created for python 3.1

import sys
print(sys.version) # for help verifying version tested
from xml.etree import ElementTree

sampleinput = """<?xml version="1.0"?><Hello></Hello>"""
xmlobj = ElementTree.fromstring(sampleinput)
type(xmlobj)
xmlstr = ElementTree.tostring(xmlobj,'utf-8')
print("xmlstr value is '", xmlstr, "'", sep="")
print("xmlstr type is '", type(xmlstr), "'", sep="")
-------------------------------------------------------
test program output:
-------------------------------------------------------
3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)]
xmlstr value is 'b'<Hello />''
xmlstr type is '<class 'bytes'>'
=======================================================

This cheap "fix" for this bug may be simply be a change in documentation.
However, a method called "tostring" really should return something nearer to the built-in str.

----------
assignee: docs at python
components: Documentation, XML
messages: 126506
nosy: JTMoon79, docs at python
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.tostring returns type bytes, expected type str
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Wed Jan 19 01:14:31 2011
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Wed, 19 Jan 2011 00:14:31 +0000
Subject: [docs] [issue10942] xml.etree.ElementTree.tostring returns type
	bytes, expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1295396071.89.0.200442985784.issue10942@psf.upfronthosting.co.za>


J_Tom_Moon_79 <jtm.moon.forum.user+python at gmail.com> added the comment:

Some other bugs affecting the tostring method (for consideration by the reviewer):
http://bugs.python.org/issue6233#msg89718
http://bugs.python.org/msg101037
http://bugs.python.org/issue9692

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Wed Jan 19 03:10:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Jan 2011 02:10:58 +0000
Subject: [docs] [issue10942] xml.etree.ElementTree.tostring returns type
	bytes, expected type str
In-Reply-To: <1295395949.96.0.0409847573272.issue10942@psf.upfronthosting.co.za>
Message-ID: <1295403058.22.0.853259499446.issue10942@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is indeed a doc problem, although there was some discussion of working toward a method rename.  See issue 8047 (but be prepared to read a novel to understand why tostring returns bytes...)  The doc for 3.2 is slightly clearer, but both 3.1 and 3.2 could be made clearer by referring to an 'encoded byte string' rather than just an 'encoded string'.  (An encoded string has to be a byte string, but that isn't obvious unless you've dealt with encode/decode a bunch.)

Technically this could be closed as a duplicate of issue 8047, since that issue proposes that the API fix (which would include the doc change) be backported to 3.1.  But no one has proposed a patch there, so at a minimum the 3.1 docs should be clarified.

----------
nosy: +r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10942>
_______________________________________

From report at bugs.python.org  Wed Jan 19 10:15:53 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 19 Jan 2011 09:15:53 +0000
Subject: [docs] [issue10944] ctypes documentation does not mention c_bool in
	table of	standard types
In-Reply-To: <1295428553.77.0.0934599344466.issue10944@psf.upfronthosting.co.za>
Message-ID: <1295428553.77.0.0934599344466.issue10944@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

http://docs.python.org/library/ctypes.html:

-----------
15.16.1.4. Fundamental data types
[table without c_bool]
------------
15.16.2.7. Fundamental data types
class ctypes.c_bool

New in version 2.6.
------------

----------
assignee: docs at python
components: Documentation
messages: 126520
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: ctypes documentation does not mention c_bool in table of standard types
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10944>
_______________________________________

From report at bugs.python.org  Wed Jan 19 16:40:16 2011
From: report at bugs.python.org (Joe Peterson)
Date: Wed, 19 Jan 2011 15:40:16 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295451616.55.0.892544002637.issue10921@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

This issue has been split, as suggested by Alexander Belopolsky, into separate issues:

issue 10934 - doc change to correctly reflect return of local time vs. UTC
issue 10939 - bytes/str issues
issue 10941 - DST handled incorrectly
issue 10947 - compatibility using str/bytes

Closing this issue (see separate ones above).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Wed Jan 19 18:53:12 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 17:53:12 +0000
Subject: [docs] [issue10921] imaplib: Internaldate2tuple() string/bytes
	issues, does not handle negative TZ offsets,
	does not handle DST correctly
In-Reply-To: <1295220756.66.0.509737296044.issue10921@psf.upfronthosting.co.za>
Message-ID: <1295459592.19.0.20777277602.issue10921@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
superseder:  -> imaplib: Internaldate2tuple() is documented to return UTC, but it returns local time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10921>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:30:21 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 19:30:21 +0000
Subject: [docs] [issue10934] imaplib: Internaldate2tuple() is documented to
	return	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295465421.5.0.0960347448748.issue10934@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It makes sense that Internaldate2tuple() returns local time because timetuple (with its tm_isdst flag) strongly suggests local time.  (See also issue 9004.)

If UTC or any other timezone time is needed, it would be best to provide a function that would return an aware datetime object.

I made some changes to Joe's patch in attached diff.  I would appreciate another pair of eyes to look at it before I commit.

----------
nosy: +belopolsky
resolution:  -> accepted
stage:  -> commit review
Added file: http://bugs.python.org/file20457/issue10934.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:45:15 2011
From: report at bugs.python.org (Joe Peterson)
Date: Wed, 19 Jan 2011 19:45:15 +0000
Subject: [docs] [issue10934] imaplib: Internaldate2tuple() is documented to
	return	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295466315.69.0.622423149256.issue10934@psf.upfronthosting.co.za>


Joe Peterson <joe at skyrush.com> added the comment:

Hey Alexander,

Looks great.  Just a few small things:

* In hunk 2 of the imaplib.rst file patch section, insert word "to" (i.e. "Convert *date_time* to an IMAP4 ``INTERNALDATE`` representation.")

* Two lines, down there's only one space at end of sentence:  "double-quotes). The" (all other places have 2 spaces).

* In first hunk of imaplib.py patch section, there is a period that does not belong after "tuple":  "time.struct_time tuple. or None"

That's all I saw!  Thanks for expanding on the doc!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:54:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 19:54:24 +0000
Subject: [docs] [issue10934] imaplib: Internaldate2tuple() is documented to
	return	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295466864.27.0.871914841314.issue10934@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 88114.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Wed Jan 19 20:57:57 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 19 Jan 2011 19:57:57 +0000
Subject: [docs] [issue10906] wsgiref should mention that CGI scripts usually
	expect	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295467077.21.0.842508849278.issue10906@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The doc says "1", "yes" or "on".  Looks fine to me.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Wed Jan 19 21:07:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 19 Jan 2011 20:07:15 +0000
Subject: [docs] [issue10944] ctypes documentation does not mention c_bool in
	table of	standard types
In-Reply-To: <1295428553.77.0.0934599344466.issue10944@psf.upfronthosting.co.za>
Message-ID: <1295467635.8.0.570756788418.issue10944@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r88115.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10944>
_______________________________________

From report at bugs.python.org  Wed Jan 19 22:49:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Jan 2011 21:49:10 +0000
Subject: [docs] [issue10934] imaplib: Internaldate2tuple() is documented to
	return	UTC, but it returns local time
In-Reply-To: <1295358368.86.0.12522725261.issue10934@psf.upfronthosting.co.za>
Message-ID: <1295473750.15.0.195623012976.issue10934@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Merged to 2.7 in revision 88116.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10934>
_______________________________________

From report at bugs.python.org  Thu Jan 20 17:34:15 2011
From: report at bugs.python.org (Jerry Seutter)
Date: Thu, 20 Jan 2011 16:34:15 +0000
Subject: [docs] [issue10957] Python FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>


New submission from Jerry Seutter <jseutter at gmail.com>:

Section 4.1 of the Python FAQ (http://www.python.org/dev/faq/) contains a grammar error:

The sentence I am referring to says: "If you are developing on OS X for Python 2.x and will not be working with the OS X-specific modules from the standard library, then consider using the --without-toolbox-glue flag to faster compilation time."

How about instead: "If you are developing on OS X for Python 2.x and will not be working with the OS X-specific modules from the standard library, then consider using the --without-toolbox-glue flag for a faster compile."

(Note: Taken from the FAQ as of Jan 20, 2011)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 126626
nosy: docs at python, jerry.seutter
priority: normal
severity: normal
status: open
title: Python FAQ grammar error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Thu Jan 20 18:28:06 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 20 Jan 2011 17:28:06 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

Documentation should say about 'following symlink' in this function. Documentation should advice to use os.lstat() in case when it needed.

----------
assignee: docs at python
components: Documentation
messages: 126631
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: os.stat() does not mention that it follow symlinks by default
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:27:51 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 20 Jan 2011 21:27:51 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295558871.45.0.593486822904.issue4819@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Misc/cheatsheet has been removed in r88127.  Should this be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:29:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 21:29:07 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295558947.63.0.252619655866.issue4819@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, perhaps Marc-Andr? wants to revive it. Otherwise, suggest closing indeed.

----------
assignee: docs at python -> 
nosy: +lemburg
stage:  -> needs patch
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:37:10 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 20 Jan 2011 21:37:10 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295559430.64.0.123296456822.issue4819@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Updating the cheat sheet would be a great summer of code like project. We are considering using the cheat sheet as basis for a flyer in the PSF marketing material project.

Please add it back and add a note to it, that it currently is missing a few language features (e.g. add Alexanders list to it).

Thanks.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 22:47:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Jan 2011 21:47:03 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1295559430.64.0.123296456822.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295560009.3705.25.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Updating the cheat sheet would be a great summer of code like project.
> We are considering using the cheat sheet as basis for a flyer in the
> PSF marketing material project.

IMO it's not only about updating. It's about converting it to some
proper markup format, and being able to generate nicely laid out
versions of it. See examples of nice non-Python cheat sheets:
http://javascript-reference.info/
http://www.gscottolson.com/weblog/2008/01/11/jquery-cheat-sheet/

By the way the Python 3 transition means that it not only misses some
features, but probably has lots of bogus constructs and examples, so
putting it back as-is would do users a disservice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:08:29 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 20 Jan 2011 22:08:29 +0000
Subject: [docs] [issue10906] wsgiref should mention that CGI scripts usually
	expect	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295561309.88.0.0259500667172.issue10906@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The problem that most scripts check for 'on', and not for '1'.

http://www.cgi101.com/book/ch3/text.html

More than that - I don't know any servers that set this to '1', except mod_wsgi, and perhaps other implementations that follow this wsgiref. mod_wsgi even changes value of Apache2 environment to '1'

For existing CGI scripts (that rely on HTTPS parameter being 'on') and that are ported to WSGI, this creates additional issues with HTTPS, and wastes people time.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Thu Jan 20 23:21:04 2011
From: report at bugs.python.org (Graham Dumpleton)
Date: Thu, 20 Jan 2011 22:21:04 +0000
Subject: [docs] [issue10906] wsgiref should mention that CGI scripts usually
	expect	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295562064.68.0.847810528359.issue10906@psf.upfronthosting.co.za>


Graham Dumpleton <Graham.Dumpleton at gmail.com> added the comment:

As has been pointed out to you already in other forums, the correct way of detecting in a compliant WSGI application that a SSL connection was used is to check the value of the wsgi.url_scheme variable. If your code does not do this then it is not a compliant WSGI application and you have no guarantee that it will work portably across different WSGI hosting mechanisms. This is because a WSGI server/adapter is not obligated to set the HTTPS variable in the WSGI environment dictionary.

So, the correct thing to do, which for some reasons you don't want to, is to fix your code when it is being ported to adhere to the WSGI specification and what it dictates as the way of detecting a SSL connection.

FWIW, the HTTPS variable will no longer be set from mod_wsgi version 4.0 to enforce the point that it is not the correct way of detecting that an SSL connection and that wsgi.url_scheme should be used. The HTTPS variable was only being set at all and with that value because older versions of Django weren't doing what you also refuse to do, which is check for wsgi.url_scheme instead of the HTTPS variable. Django did the right thing and fixed their code to be compliant. Why you can't and want to keep arguing this point in three different forums is beyond me. You have spent way much more time arguing the point than it would take to fix your code to be compliant.

----------
nosy: +grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Fri Jan 21 00:00:45 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Jan 2011 23:00:45 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295564445.08.0.827216744442.issue4819@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Perhaps the cheatsheet can be transferred to a wiki page and we can put out a comp.lang.python call for updates.

Also, +1 on the summer of code idea.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:15:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 01:15:36 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295572535.45.0.0140187093103.issue4819@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I agree that it would be nice to have a cheatsheet somewhere, possibly in the official doc and not as a plain txt file in Misc/.
FWIW another cheatsheet updated to 2.6 can be found here: http://rgruet.free.fr/PQR26/PQR2.6.html

----------
keywords: +gsoc
nosy: +ezio.melotti
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:32:45 2011
From: report at bugs.python.org (Matt Joiner)
Date: Fri, 21 Jan 2011 01:32:45 +0000
Subject: [docs] [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295573565.63.0.643471073151.issue9723@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I agree, I discovered this function (pipes.quote) only through recommendation here:

http://stackoverflow.com/questions/4748344/whats-the-reverse-of-shlex-split

I suggest that it be added to shlex, perhaps as shlex.quote. While the quoting style it performs, and the module it's found in are specific to Unix tools, the shlex module is available on non-Unix platforms. To this end, adding the function to shlex would make it available elsewhere, as well as be appropriately shell-related.

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jan 21 02:34:25 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 21 Jan 2011 01:34:25 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295573664.21.0.895730755097.issue4819@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

FWIW, I updated the first couple of pages.  If anyone finds my changes useful, here they are in issue4819.diff.

----------
keywords: +patch
Added file: http://bugs.python.org/file20476/issue4819.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:12:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Jan 2011 02:12:37 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295575957.51.0.733024471931.issue4819@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Past experience has shown that a cheatsheet in the main repository gets neglected.  How about we open it up via a wiki or somesuch so that the community if free to update it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:26:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 02:26:36 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1295576796.27.0.342788103761.issue4819@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Leaving it in the wiki for a while so that the community can update and improve it might be a good idea, but ultimately I think it should go in the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 03:58:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 02:58:01 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295578681.83.0.748624907845.issue10936@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If the width is specified with a percentage, a min-width should be specified too.
In the py3k doc the sidebar can be collapsed though, so I'm not sure it's worth changing this. Georg?

----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 04:47:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 03:47:32 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1295581652.3.0.230339429083.issue9196@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Python 3 checks the return types of __bytes__ and __str__, raising an error if it's not bytes and str respectively:
>>> str(C())
TypeError: __str__ returned non-string (type bytes)
>>> bytes(C())
TypeError: __bytes__ returned non-bytes (type str)

The Python 2 doc for unicode() says[0]:
"""
For objects which provide a __unicode__() method, it will call this method without arguments to create a Unicode string. For all other objects, the 8-bit string version or representation is requested and then converted to a Unicode string using the codec for the default encoding in 'strict' mode.
"""

The doc for .__unicode__() says[1]:
"""
Called to implement unicode() built-in; should return a Unicode object. When this method is not defined, string conversion is attempted, and the result of string conversion is converted to Unicode using the system default encoding.
"""
This is consistent with unicode() doc (but it doesn't mention that 'strict' is used).  It also says that the method *should* return unicode, but it can also returns a str that gets coerced by unicode().

The doc for .__str__() says[2]:
"""
Called by the str() built-in function and by the print statement to compute the ?informal? string representation of an object. [...] The return value must be a string object.
"""
This is wrong because the return value can be unicode too (this has been changed at some point, it used to be true on older versions).

That said, some of the behaviors described by Craig (e.g. __str__ that returns unicode) are not documented and documenting them might save some confusion. However these "weird" behaviors are most likely errors and the fact that there are no exception is just because Python 2 is not strict with str/unicode.

I think a better way to solve the problem is to document clearly how these methods should be used (i.e. if __unicode__ should be preferred over __str__, if it's necessary to implement both, what they should return, etc.).

[0]: http://docs.python.org/library/functions.html#unicode
[1]: http://docs.python.org/reference/datamodel.html#object.__unicode__
[2]: http://docs.python.org/reference/datamodel.html#object.__str__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________

From report at bugs.python.org  Fri Jan 21 05:03:37 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 21 Jan 2011 04:03:37 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295578681.83.0.748624907845.issue10936@psf.upfronthosting.co.za>
Message-ID: <AANLkTimQDpBf3BxXXuKwGxmNLnTaow_=BY4OCPX3FF7j@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

As Ezio noted, the coming versions of the Python 3 documentation
provide a way to collapse the sidebar completely.  Perhaps a min-width
should be specified, but I'm not convinced that's a good idea.

The sidebar problem is fairly significant, and the collapsing sidebar
alone isn't sufficient.  The sidebar is useful since it's the only
overall navigation structure (as opposed to the direct links embedded
in the content), but there's no real need to ensure it gets "enough"
width.  I'd rather see a simple adjustment as recommended by
Christopher Dunn.

I appreciate Ezio's in making the sidebar collapsible, but I think
that's just the first step.  The sidebar is certainly the most
contentious element of the new design, and the most difficult to get
right.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 05:18:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 04:18:35 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295583515.01.0.722282435317.issue10936@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The min-width is necessary in case the CSS is changed to resize the sidebar dynamically. If it gets too narrow it would start getting unusable and the text will start overflowing.

Possible alternatives are:
1) use a percentage and min-width;
2) like 1) but also collapse the sidebar automatically when its width gets smaller than the min-width;
3) leave a fixed width but make the sidebar mouse-resizable (that will conflict with the collapsibility though and is less trivial to do);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From fdrake at acm.org  Fri Jan 21 05:45:15 2011
From: fdrake at acm.org (Fred Drake)
Date: Thu, 20 Jan 2011 23:45:15 -0500
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295583515.01.0.722282435317.issue10936@psf.upfronthosting.co.za>
References: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
	<1295583515.01.0.722282435317.issue10936@psf.upfronthosting.co.za>
Message-ID: <AANLkTim1Gv4=rK_xJwu65pitdmn0mRYshTCGoLobvLtu@mail.gmail.com>

On Thu, Jan 20, 2011 at 11:18 PM, Ezio Melotti <report at bugs.python.org> wrote:
> If it gets too narrow it would start getting unusable and the text will start overflowing.

If someone is zooming that much, it's because they really need the
size of the text more than anything (trust me; I've tried to work
while my eyes were dilated; size is *everything* at that point).  The
worst thing to do in such situations is to get in the way of the
browser's normal behavior.

From report at bugs.python.org  Fri Jan 21 06:11:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 21 Jan 2011 05:11:23 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295586683.36.0.220929359845.issue10936@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I did some tests using 20% instead of 230px and found the following problems:
1) while zooming, even if the width of the sidebar doesn't change, the font size does, overflowing from the sidebar;
2) min-width can't be used because the width of the sidebar is given by the margin-left of the bodywrapper, and there's no min-margin-left property that can be used instead;

The font size can probably be changed to fit the width of the sidebar, but the min-width problem remains (I'm thinking about small screens -- e.g. smartphones -- where the sidebar would end up having a width of ~130-160px (I haven't (yet) tested it there though)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:09:04 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 Jan 2011 07:09:04 +0000
Subject: [docs] [issue10906] wsgiref should mention that CGI scripts usually
	expect	HTTPS variable to be set to 'on'
In-Reply-To: <1295014476.87.0.519263477862.issue10906@psf.upfronthosting.co.za>
Message-ID: <1295593744.51.0.529881064335.issue10906@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The doc for this function is not a place to discuss what CGI scripts do.  It describes what guess_scheme() does, and it does so sufficiently.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10906>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:53:18 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 07:53:18 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295596398.63.0.0437921219805.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

I see what @ezio means about the apparent overflow when the bodywrapper left margin is at 20%. (It's not really overflow, since the sidebar is actually the width of the screen.) How about this change to basic.css?

 44 div.sphinxsidebar {
 45     float: left;
 46     width: 20%; /* was 230px */
 47     margin-left: -100%;
 48     font-size: 90%;
 49 }

It looks pretty good to me. The only thing that overflows is the search-input box. CSS for that is set in both basic.css and default.css (which takes precedence) as:

104 div.sphinxsidebar input {
105     border: 1px solid #98dbcc;
106     font-family: sans-serif;
107     font-size: 1em;
108     max-width: 100%;
109 }

I added line 108 (max-width). And now everything looks decent when zoomed in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 08:58:36 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 07:58:36 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295596716.59.0.130601233551.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

For narrow-width screens, there really shouldn't be a sidebar. Maybe a dynamic element would be better. Could it unhide and overlap the main body with a click or mouse-over? Then the main body could take the full screen width. Just an idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 10:27:52 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 21 Jan 2011 09:27:52 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1295564445.08.0.827216744442.issue4819@psf.upfronthosting.co.za>
Message-ID: <4D395189.70403@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Raymond Hettinger wrote:
> 
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> 
> Perhaps the cheatsheet can be transferred to a wiki page and we can put out a comp.lang.python call for updates.

Good idea.

I just want to prevent the text from being lost in SVN
history somewhere... one of the things I liked about CVS was the Attic.
With Subversion deleted files are simply gone and unless someone remembers
them, they are lost.

> Also, +1 on the summer of code idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Fri Jan 21 14:42:01 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 21 Jan 2011 13:42:01 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295596716.59.0.130601233551.issue10936@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=b5XqqLUTr5H7NkCW725w382_Fh6bdH35VA6eL@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Fri, Jan 21, 2011 at 2:58 AM, Christopher Dunn
<report at bugs.python.org> wrote:
> For narrow-width screens, there really shouldn't be a sidebar. Maybe a dynamic element would be better.

Right.  I'd be in favor of removing the sidebar and having a pop-out
ToC navigator of some sort.  Most of the time, most of us are looking
at the content, not at how to navigate the content.  Spending so much
screen real-estate on navigation is painful.  Large, hi-res screens
just aren't *that* cheap yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:51:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:51:11 +0000
Subject: [docs] [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295635871.51.0.598749848186.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Why do you want to move quote from pipes to shlex?  The function is available, the issue here is lack of documentation.

----------
stage:  -> unit test needed
type: feature request -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:52:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:52:28 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295635948.06.0.148770025422.issue10936@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Also, laptops and handheld devices have a limited screen size.

-1 on a pop-up, for obvious usability reasons.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:52:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 18:52:38 +0000
Subject: [docs] [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295635958.3.0.0697797698687.issue9723@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jan 21 19:57:46 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 18:57:46 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295636266.22.0.446066441019.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

@eric.araujo:

Not a 'pop-up', that you would have to click to close. But something dynamic, based on mouse location.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 20:15:29 2011
From: report at bugs.python.org (Christopher Dunn)
Date: Fri, 21 Jan 2011 19:15:29 +0000
Subject: [docs] [issue10936] Simple CSS fix for left margin at
	docs.python.org
In-Reply-To: <1295377924.0.0.902429691003.issue10936@psf.upfronthosting.co.za>
Message-ID: <1295637329.42.0.373580467958.issue10936@psf.upfronthosting.co.za>


Christopher Dunn <cdunn2001 at gmail.com> added the comment:

I was just trying to help fix the CSS, and I think I've done that.

If we're reconsidering the behavior of the nav sidebar, then I'd like to point out that if you're far down the page, the sidebar is blank to your right. From a usability point of view, it's already broken. It was a neat idea, but a ToC for the page would serve the purpose better.

My monitor is quite large, and rotated 90 degrees, so it's narrow and tall. A web-page can be infinitely long, but its practical width is limited to the user's screen, which is different for every user. That's why HTML was designed the way it is, with auto-word-wrap.

When you have a bunch of stuff that you want to fit within a window, a sidebar makes more sense. For Python docs, I'd vote to drop it altogether, as attractive-looking as it is.

But if you really want it, give it its own vertical scrollbar, so that a relevant portion is always visible. Then people can talk about dynamic controls.

That's just my opinion. I created this bug because, when I zoon, the sidebar consumes most of my screen with no visible text. It's such a huge problem that I was afraid someone had already submitted this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10936>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:46:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 20:46:51 +0000
Subject: [docs] [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295642811.72.0.661510305904.issue10976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, the documentation (and function docstring) needs fixing instead. It's a pity we didn't remove the useless `encoding` parameter.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 21:54:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Jan 2011 20:54:36 +0000
Subject: [docs] [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295643276.8.0.909709903601.issue10976@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Georg: Is it still time to deprecate the encoding parameter in 3.2?

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 22:38:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Jan 2011 21:38:08 +0000
Subject: [docs] [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295645888.73.0.507443717354.issue10976@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a doc fix in r88137.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Jan 21 23:08:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Jan 2011 22:08:43 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295647723.11.0.479553810917.issue10960@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I almost closed this as invalid, since the name is, after all 'os.stat' and the docs clearly say that it calls the 'stat' system call.  However, I see that our docs do not contain the more explicit language used by the 'stat' system call docs: "stats the file pointed to by path".  Although even that isn't crystal clear unless you also read the definition of 'lstat' right below it.  If you read our docs for lstat it does become clear even as things stand, but lstat isn't right below stat in our docs.

So on reflection I think the docs could use improvement in this area.

----------
nosy: +r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sat Jan 22 00:37:26 2011
From: report at bugs.python.org (Rafe Kettler)
Date: Fri, 21 Jan 2011 23:37:26 +0000
Subject: [docs] [issue10957] Python FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295653046.34.0.476784132024.issue10957@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

>for a faster compile
Compile isn't a noun; the most grammatically correct sentences would be "for faster compilation."

----------
nosy: +rafe.kettler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:01:50 2011
From: report at bugs.python.org (Jerry Seutter)
Date: Sat, 22 Jan 2011 00:01:50 +0000
Subject: [docs] [issue10957] Python FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295654510.6.0.823665297867.issue10957@psf.upfronthosting.co.za>


Jerry Seutter <jseutter at gmail.com> added the comment:

I agree with what Rafe said.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:19:20 2011
From: report at bugs.python.org (Jerry Seutter)
Date: Sat, 22 Jan 2011 00:19:20 +0000
Subject: [docs] [issue10957] Python developer FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295655560.89.0.5853003507.issue10957@psf.upfronthosting.co.za>


Changes by Jerry Seutter <jseutter at gmail.com>:


----------
title: Python FAQ grammar error -> Python developer FAQ grammar error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 01:30:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Jan 2011 00:30:53 +0000
Subject: [docs] [issue10957] Python developer FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295656253.79.0.966893591178.issue10957@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In general, the website is separate from Python code and documentation and website issues should be sent to webmaster at python.org, not here, as code/doc committers cannot change web pages.

However, this particular page (dev/faq) has being pulled into the (hg) repository as part of expanded docs for developers. It is possible that 'to faster compilation time' has already been corrected. Brett? (and will the web page go away or be replaced?)

----------
nosy: +brett.cannon, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 04:05:57 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 22 Jan 2011 03:05:57 +0000
Subject: [docs] [issue10957] Python developer FAQ grammar error
In-Reply-To: <1295541255.37.0.868919325173.issue10957@psf.upfronthosting.co.za>
Message-ID: <1295665557.5.0.0872846565212.issue10957@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That entire portion of the FAQ has been removed as it was redundant compared to other parts of the devguide.

Closing as out of date.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10957>
_______________________________________

From report at bugs.python.org  Sat Jan 22 10:50:38 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 22 Jan 2011 09:50:38 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295689838.16.0.564885089054.issue10960@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Yes, os.stat and os.lstat should be one after next in docs. Also IMHO, they should have cross-references. See excellent php docs for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sat Jan 22 12:01:38 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 22 Jan 2011 11:01:38 +0000
Subject: [docs] [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1295694098.84.0.680552076754.issue9723@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Two reasons: The pipes module is Unix only, but pipes.quote is useful on all platforms. Secondly pipes.quote pertains to shell command-lines, this is also the domain of shlex which already cross platform. In pipes, an import shlex.quote would more than sufficient.

If this belongs in another separate bug I shall submit one. Please advise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Sat Jan 22 13:28:37 2011
From: report at bugs.python.org (hhas)
Date: Sat, 22 Jan 2011 12:28:37 +0000
Subject: [docs] [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295699317.74.0.671235162686.issue10976@psf.upfronthosting.co.za>


hhas <hhas at users.sourceforge.net> added the comment:

Doc fix works for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Sun Jan 23 08:54:37 2011
From: report at bugs.python.org (godfryd)
Date: Sun, 23 Jan 2011 07:54:37 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295769276.99.0.207593630795.issue10960@psf.upfronthosting.co.za>


godfryd <godfryd at gmail.com> added the comment:

I improved a little bit lstat function description and added note to stat function. 

I see that links :func:`stat` do not lead to stat function but to stat module. Is it Sphinx bug? In my changes I made explicit link to os.stat function.

----------
keywords: +patch
nosy: +godfryd
Added file: http://bugs.python.org/file20490/improved-lstat-doc-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sun Jan 23 17:02:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Jan 2011 16:02:22 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295798542.02.0.409737390684.issue10960@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think Georg considers it a bug in Sphinx, it's just how the disambiguation machinery works.  You can write :func:`~os.stat` if you want the link text to just be 'stat' but the link to be to 'os.stat'.

I don't think the addition to lstat is either helpful or needed.  The addition to stat, which is needed, I don't think should be a note, but rather an inline comment early in the documentation paragraph.

Thanks for working on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Sun Jan 23 19:38:05 2011
From: report at bugs.python.org (Joshua Arnold)
Date: Sun, 23 Jan 2011 18:38:05 +0000
Subject: [docs] [issue10988] Descriptor protocol documentation for super
	bindings is	incorrect
In-Reply-To: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za>
Message-ID: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za>


New submission from Joshua Arnold <josharnold52 at gmail.com>:

In 'Doc/reference/datamodel.rst', the 'Invoking Descriptors' documentation specifies the following behavior for super objects:

[snip]
Super Binding
   If ``a`` is an instance of :class:`super`, then the binding ``super(B,
   obj).m()`` searches ``obj.__class__.__mro__`` for the base class ``A``
   immediately preceding ``B`` and then invokes the descriptor with the call:
   ``A.__dict__['m'].__get__(obj, A)``.
[snip]

In the above paragrah, the call:

   A.__dict__['m'].__get__(obj, A)
   
is incorrect.  In reality, the descriptor is invoked via:

   A.__dict__['m'].__get__(obj, obj.__class__)
   
Loosely speaking, the 'owner' argument is set to the subclass associated with the super object, not the superclass.  There is a similar error in the 'Descriptor HowTo Guide' under 'Invoking Descriptors'

(Strictly speaking, the specification is inaccurate on some other points.  It assumes obj is not a class and doesn't state that the entire mro preceding 'B' is searched for 'm'.  But those may be considered simplifications for the sake of brevity)

I considered reporting this as a bug in the implementation rather than the specification.  But I think the implementation's algorithm is the correct one.  In particular, it yields the desired behavior for classmethods   In any case, the current behavior has been around for a while (it was the fix for issue #535444, dating back to 2.2)

Code demonstrating the current behavior:

class Desc(object):
    def __get__(self, instance, owner):
        return owner

class A(object):
    attr = Desc()

class B(A):
    pass

class C(B):
    pass

instance = C()

assert super(B,instance).attr == C
assert super(B,C).attr == C

#According to the specification, the assertions should be:
#assert super(B,instance).attr == A
#assert super(B,C).attr == A

----------
assignee: docs at python
components: Documentation
messages: 126895
nosy: Joshua.Arnold, docs at python
priority: normal
severity: normal
status: open
title: Descriptor protocol documentation for super bindings is incorrect
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10988>
_______________________________________

From report at bugs.python.org  Sun Jan 23 20:56:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 23 Jan 2011 19:56:07 +0000
Subject: [docs] [issue10988] Descriptor protocol documentation for super
	bindings is	incorrect
In-Reply-To: <1295807885.2.0.206629380861.issue10988@psf.upfronthosting.co.za>
Message-ID: <1295812567.05.0.0767452248377.issue10988@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10988>
_______________________________________

From report at bugs.python.org  Sun Jan 23 22:14:04 2011
From: report at bugs.python.org (Michal Nowikowski)
Date: Sun, 23 Jan 2011 21:14:04 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295817244.75.0.600034194312.issue10960@psf.upfronthosting.co.za>


Michal Nowikowski <godfryd at gmail.com> added the comment:

The patch v2:
- in description of os.stat function added information about following symlinks,
- made list of returned attributes by os.stat function more readable,
- fixed links to os.stat function in whole document.

----------
Added file: http://bugs.python.org/file20495/improved-lstat-doc-patch-v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Mon Jan 24 14:43:40 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Mon, 24 Jan 2011 13:43:40 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski <fijall at gmail.com>:

sys module documentation (as it is online) has some things that in my opinion should be marked as implementation details, but are not. Feel free to counter why not. 

Some of them has info it should be used for specialized purposes only, but IMO it's not the same as not mandatory for other implementations.

Temporary list:

_clear_type_cache

dllhandle

getrefcount

getdlopenflags (?)

getsizeof - it might be not well defined on other implementations

setdlopenflags

api_version

----------
assignee: docs at python
components: Documentation
messages: 126925
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: implementation details in sys module
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 14:46:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 13:46:14 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295876774.11.0.541290311864.issue10994@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 14:49:10 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 24 Jan 2011 13:49:10 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295876950.2.0.53302366276.issue10994@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:02:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 14:02:56 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295877776.02.0.970256207863.issue10994@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, getsizeof is not better-defined under CPython than elsewhere. It just gives a hint.
Agreed about the other.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:05:29 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Mon, 24 Jan 2011 14:05:29 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295877929.5.0.527131313453.issue10994@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

I suppose wrt getsizeof it's more of "if you provide us with a reasonable expectations, we can implement this" other than anything else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 15:13:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Jan 2011 14:13:32 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295877929.5.0.527131313453.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295878409.3679.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I suppose wrt getsizeof it's more of "if you provide us with a
> reasonable expectations, we can implement this" other than anything
> else.

The expectation is that it returns the memory footprint of the given
object, and only it (not taking into account sharing, caching,
dependencies or anything else). For example, an instance will not count
its attribute __dict__. But a str object will count its object header
plus the string payload, if the payload is private.

Of course, you are free to tweak these semantics for the PyPy
implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:37:20 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 24 Jan 2011 17:37:20 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295890640.03.0.496273432271.issue10994@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Mon Jan 24 18:51:00 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 24 Jan 2011 17:51:00 +0000
Subject: [docs] [issue10996] Typo in What's New in 3.2
In-Reply-To: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>
Message-ID: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

In http://docs.python.org/dev/py3k/whatsnew/3.2.html#abc the example has two typos: 
farenheit -> fahrenheit
celsium -> celsius

----------
assignee: docs at python
components: Documentation
messages: 126938
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Typo in What's New in 3.2
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10996>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:16:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 24 Jan 2011 18:16:08 +0000
Subject: [docs] [issue10996] Typo in What's New in 3.2
In-Reply-To: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>
Message-ID: <1295892968.54.0.300623286257.issue10996@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10996>
_______________________________________

From report at bugs.python.org  Mon Jan 24 19:19:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 24 Jan 2011 18:19:56 +0000
Subject: [docs] [issue10996] Typo in What's New in 3.2
In-Reply-To: <1295891459.95.0.208045787052.issue10996@psf.upfronthosting.co.za>
Message-ID: <1295893196.27.0.822045267633.issue10996@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  Thanks.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10996>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:09:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 19:09:37 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295896177.95.0.846124193664.issue10960@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: docs at python -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From kverlin at gmail.com  Sun Jan 16 15:46:13 2011
From: kverlin at gmail.com (Anton Chikin)
Date: Sun, 16 Jan 2011 17:46:13 +0300
Subject: [docs] Bug viewing docs.python.org from IPod/IPhone
Message-ID: <AANLkTi=i+v+HHff5TGfwU3nQuASQiek9zju6agZDov1K@mail.gmail.com>

Hi,

I've noticed that code sample blocks long lines are truncated with the
right edge of the screen while browsing documentation on
docs.python.org with Safari browser from IPod/IPhone 3G(S).
You can find screenshots from
http://docs.python.org/tutorial/datastructures.html page in the
attachment.

With best regards,
Anton CHikin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc_iphone_bug1.PNG
Type: image/png
Size: 42156 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20110116/ac4bcf98/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doc_iphone_bug2.PNG
Type: image/png
Size: 56372 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20110116/ac4bcf98/attachment-0003.png>

From louiz at louiz.org  Wed Jan 19 03:54:17 2011
From: louiz at louiz.org (Florent Le Coz)
Date: Wed, 19 Jan 2011 03:54:17 +0100
Subject: [docs] curses page doesn't mention the resize method
Message-ID: <4D365259.2030505@louiz.org>

On the curses page [0], there is no mention of the window.resize()
method, though it exists. The C equivalent function is documented here [1].
Could this method be added in the documentation? Unless there's a good
reason not to, obviously.

[0] http://docs.python.org/library/curses.html
[1] http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=wresize

-- 
Florent Le Coz

From kenneth.meharry at gmail.com  Thu Jan 20 05:24:48 2011
From: kenneth.meharry at gmail.com (kenneth meharry)
Date: Thu, 20 Jan 2011 17:24:48 +1300
Subject: [docs] python-3.2rc1-docs-html/howto/unicode.html
Message-ID: <AANLkTik-EvVbSa=nU_pE6ASKU5D4Z93Bb_4HVCXQE1rL@mail.gmail.com>

PRINT "FICHIER EST COMPLETE."PRINT "CARACTERE NON ACCEPTE."

print("FICHIER EST COMPLETE.")print("CARACTERE NON ACCEPTE.")

In fact I suspect that all the print statements could do with reviewing
Regards
k.
-- 
simplicity is the touchstone of excellence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110120/07c09626/attachment.html>

From kenneth.meharry at gmail.com  Thu Jan 20 05:37:44 2011
From: kenneth.meharry at gmail.com (kenneth meharry)
Date: Thu, 20 Jan 2011 17:37:44 +1300
Subject: [docs] Stupidity
Message-ID: <AANLkTi=am=k_OhPfXwaG8MXNe6O0aoHut+fNeGeSnAP=@mail.gmail.com>

Please disregard my previous
dog
I have been having a hassel with Imaging in 3, but now have found a working
installation of PIL,
and now have to sort out Unicode provisions so I have settled in to read
your python-3.2rc1-docs-html/howto/unicode.html,
incorrectly as it would seem.
Regards
k.
-- 
simplicity is the touchstone of excellence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110120/87de0334/attachment.html>

From wolfgang at rohdewald.de  Sat Jan 22 08:08:50 2011
From: wolfgang at rohdewald.de (Wolfgang Rohdewald)
Date: Sat, 22 Jan 2011 08:08:50 +0100
Subject: [docs] string.Formatter.format
Message-ID: <201101220808.50571.wolfgang@rohdewald.de>

says *kwargs, shouldn't that be **kwargs?

http://docs.python.org/dev/library/string.html#string.Formatter

-- 
Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110122/1a0630ab/attachment.html>

From faheem at email.unc.edu  Sun Jan 23 11:27:35 2011
From: faheem at email.unc.edu (Faheem Mitha)
Date: Sun, 23 Jan 2011 15:57:35 +0530 (IST)
Subject: [docs] documentation suggestion
Message-ID: <alpine.DEB.2.00.1101231524460.22676@orwell.homelinux.org>


Hi,

In http://docs.python.org/library/functions.html#open

"Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+' 
truncates the file)."

The term "open the file for updating" means nothing to me in this context. 
>From other place I learned this means that 'w+' means open for both 
writing and reading and creates file if it does not exist and truncates 
file if it exists. 'a+' means appending and reading. 'r+' also means open 
for reading and writing but does not create file if it does not exist, as 
well as does not truncate the file if it does exist.

I'm still not exactly clear what the difference between 'r+' and 'a+' is 
then, if 'r+' does not truncate the file.

In any case, I suggest removing the word 'updating' and adding a 
description of what the '+' actually does.

See 
http://stackoverflow.com/questions/1466000/python-open-built-in-function-difference-between-modes-a-a-w-w

and similar stuff on the net for confusion about this.

                                                           Regards, Faheem

From pierre.quentel at gmail.com  Sun Jan 23 15:04:51 2011
From: pierre.quentel at gmail.com (Pierre Quentel)
Date: Sun, 23 Jan 2011 15:04:51 +0100
Subject: [docs] Update doc for the cgi module in version 3.2
Message-ID: <AANLkTinBv1Li_nLNpCyHAXLnP2OvAKQ+xeb+oySGSmMR@mail.gmail.com>

Hi,

I wrote a patch for the cgi module in version 3.2rc1. Small changes should
be done to the documentation of this module to reflect the changes in the
module API :

- in section "20.2.2. Using the cgi module"

original text :
"If a field represents an uploaded file, accessing the value via the value
attribute or the getvalue() method reads the entire file in memory as a
string. This may not be what you want. You can test for an uploaded file by
testing either the filename attribute or the file attribute. You can then
read the data at leisure from the file attribute:"

proposed new text (for files, value is bytes, not string, and the read()
method on file also returns bytes) :
"If a field represents an uploaded file, accessing the value via the value
attribute or the getvalue() method reads the entire file in memory as bytes.
This may not be what you want. You can test for an uploaded file by testing
either the filename attribute or the file attribute. You can then read the
data at leisure from the file attribute (the read() and readline() methods
will return bytes) :"

- version 2.1 introduced a parameter "encoding" for the FieldStorage
constructor, used to decode the bytes received on the HTTP connection for
fields other than files. This encoding must the one defined in the HTML
document holding the form submitted to the CGI script ; it is usually
defined by a meta tag :
<meta http-equiv="Content-type" content="text/html;charset=latin-1">
or by the Content-Type header for this document

I'm not sure where this should be mentioned in the documentation. Maybe in
"20.2.9. Common problems and solutions" for the moment. But there are plans
to introduce another interface to change the encoding of sys.stdout in the
CGI script itself, so another option would be to open a specific section
about encodings

Hope it's clear enough
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110123/b532deda/attachment.html>

From report at bugs.python.org  Mon Jan 24 20:38:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 19:38:32 +0000
Subject: [docs] [issue10960] os.stat() does not mention that it follow
	symlinks by	default
In-Reply-To: <1295544486.66.0.118119387237.issue10960@psf.upfronthosting.co.za>
Message-ID: <1295897912.54.0.0520925116507.issue10960@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.

Committed a modified version of the patch in r88164.  I extended your breakout of the attributes to the other paragraphs, and reorganized the order of the paragraphs in the stat docs to put things into a more logical order (I hope).  I decided to change the existing wording about the stat system call to reflect the fact that we aren't making a stat system call on Windows, and did something similar in the lstat entry.

This will get backported to the 2.7 docs (and 3.1) presently, but not right away.

----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10960>
_______________________________________

From report at bugs.python.org  Mon Jan 24 20:41:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Jan 2011 19:41:15 +0000
Subject: [docs] [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Title pretty much says it all.  The constants are there in the stat module, but they aren't documented.  When they are documented the mentions in the os.chflags entry can be turned into cross reference links.

----------
assignee: docs at python
messages: 126947
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: os.chflags refers to stat constants, but the constants are not documented in the stat module
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:07:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Jan 2011 20:07:58 +0000
Subject: [docs] [issue11000] Doc: ast.parse parses source,
	not just expressions
In-Reply-To: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>
Message-ID: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

"ast.parse(expr, filename='<unknown>', mode='exec') 
Parse an expression into an AST node. Equivalent to compile(expr, filename, mode, ast.PyCF_ONLY_AST)."

but

"compile(source, ...) 
Compile the source into a code or AST object. 
...
The mode argument specifies what kind of code must be compiled; it can be 'exec' if source consists of a sequence of statements,"

and indeed, with all three versions,

>>> import ast
>>> e3=ast.parse('x=1; y=2\nif x: print(y)')
>>> o3 = compile(e3,'','exec')
>>> exec(o3)
2
>>> print(x,y)
(1, 2)

Attached patch (untested) changes doc and doc string.

Inquiry: I suspect that the filename is *not* attached to the ast. (In any case, it must be explicitly supplied to a subsequent compile() call.) If so, it is a useless parameter and the api and doc should be

parse(source, mode) ... Equivalent to compile(source, '<unknown>', ...

If so, and failing such a change, should the doc warn people to not bother supplying a filename arg?

I also wonder whether the mode arg has any effect on the ast. If not, same question.

----------
assignee: docs at python
components: Documentation
files: zast.diff
keywords: patch
messages: 126952
nosy: docs at python, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: Doc: ast.parse parses source, not just expressions
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20506/zast.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11000>
_______________________________________

From report at bugs.python.org  Mon Jan 24 21:09:30 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 Jan 2011 20:09:30 +0000
Subject: [docs] [issue11000] Doc: ast.parse parses source,
	not just expressions
In-Reply-To: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>
Message-ID: <1295899770.85.0.0341466906977.issue11000@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11000>
_______________________________________

From georg at python.org  Mon Jan 24 20:29:19 2011
From: georg at python.org (Georg Brandl)
Date: Mon, 24 Jan 2011 20:29:19 +0100
Subject: [docs] string.Formatter.format
In-Reply-To: <201101220808.50571.wolfgang@rohdewald.de>
References: <201101220808.50571.wolfgang@rohdewald.de>
Message-ID: <4D3DD30F.6060206@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 22.01.2011 08:08, schrieb Wolfgang Rohdewald:
> says *kwargs, shouldn't that be **kwargs?
> 
> http://docs.python.org/dev/library/string.html#string.Formatter

Yes, quite right.  Fixed now in the repo.

Thanks,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk090w8ACgkQN9GcIYhpnLDH1ACePG80AlPZOG0c63pnDDYAWH3v
25wAnikXAu9YDAF0ltiW/9D5+YCWGwRT
=Sb29
-----END PGP SIGNATURE-----

From report at bugs.python.org  Mon Jan 24 23:27:45 2011
From: report at bugs.python.org (Luke Plant)
Date: Mon, 24 Jan 2011 22:27:45 +0000
Subject: [docs] [issue11001] Various obvious errors in cookies documentation
In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>
Message-ID: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>


New submission from Luke Plant <L.Plant.98 at cantab.net>:

Docs for SimpleCookie, BaseCookie.value_encode and BaseCookie.value_decode are obviously incorrect.  Attempt at patch attached.

The error has existed in every Python version I've seen, I've tagged the ones I believe can receive fixes, sorry if I've made a mistake.

Thanks.

----------
assignee: docs at python
components: Documentation
files: http_cookies_doc_corrections.diff
keywords: patch
messages: 126962
nosy: docs at python, spookylukey
priority: normal
severity: normal
status: open
title: Various obvious errors in cookies documentation
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20507/http_cookies_doc_corrections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11001>
_______________________________________

From report at bugs.python.org  Mon Jan 24 23:29:06 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Jan 2011 22:29:06 +0000
Subject: [docs] [issue11000] Doc: ast.parse parses source,
	not just expressions
In-Reply-To: <1295899678.27.0.449949701251.issue11000@psf.upfronthosting.co.za>
Message-ID: <1295908146.4.0.763373761963.issue11000@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

r88172, r88173, r88175

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11000>
_______________________________________

From report at bugs.python.org  Tue Jan 25 02:35:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 01:35:25 +0000
Subject: [docs] [issue11001] Various obvious errors in cookies documentation
In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>
Message-ID: <1295919324.41.0.235332523544.issue11001@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The text in the docstrings appears to be accurate, and it seems to me they clarify it even more than your suggested changes do.  Also, I think SimpleCookie's encode/decode roughly implements some RFC or another (though there are some tweaks), and it might be worth mentioning that.

Even with these changes, though, I don't think it is possible to really understand what cookie is doing without reading the source, and even then it is non-obvious :(

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11001>
_______________________________________

From report at bugs.python.org  Tue Jan 25 04:38:50 2011
From: report at bugs.python.org (Anthony Long)
Date: Tue, 25 Jan 2011 03:38:50 +0000
Subject: [docs] [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295926730.52.0.312692723368.issue10976@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

Works for me, py2.7 on snow leopard.

----------
nosy: +antlong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Tue Jan 25 05:44:24 2011
From: report at bugs.python.org (Anthony Long)
Date: Tue, 25 Jan 2011 04:44:24 +0000
Subject: [docs] [issue11002] 'Upload' link on Files page is broken
In-Reply-To: <1295930664.52.0.312765274224.issue11002@psf.upfronthosting.co.za>
Message-ID: <1295930664.52.0.312765274224.issue11002@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

On pypi, when you are inside of your packages' files area, the link that is attached to 

1. Use the setup.py "upload" command. # "upload"

is broken, it links to http://www.python.org/doc/dist/package-upload.html which returns a 404.

http://d.pr/mmie

----------
assignee: docs at python
components: Documentation
messages: 126988
nosy: antlong, docs at python
priority: normal
severity: normal
status: open
title: 'Upload' link on Files page is broken
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11002>
_______________________________________

From report at bugs.python.org  Tue Jan 25 12:42:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Jan 2011 11:42:31 +0000
Subject: [docs] [issue10976] json.loads() throws TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1295955751.81.0.371972669966.issue10976@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

anthony: this is python3-only problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Tue Jan 25 17:37:18 2011
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 25 Jan 2011 16:37:18 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295973438.5.0.625022653518.issue10994@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

> The expectation is that it returns the memory footprint of the given
> object, and only it (not taking into account sharing, caching,
> dependencies or anything else).

It would be nice if this was a well-defined definition, but unfortunately it is not.  For example, string objects may appear different from the user's point of view (e.g. as seen by id() and 'is') but share the implementation's data; they may even share only a part of it (if ropes are enabled).  Conversely, for user-defined objects you would typically think not to count the "shape" information, which is usually shared among several instances -- but then you risk a gross under-estimation in the (rarer) cases where it is not shared.

Another way to look at the "official" definition is to return the size of the object itself and none of its dependencies, because in theory they might be shared; but that would make all strings, lists, tuples, dicts, and so on have a getsizeof() of 8 or 12, which is rather useless.

I hope this clarifies fijal's original comment: "it might be not well defined on other implementations."

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:18:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 17:18:16 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295973438.5.0.625022653518.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295975892.3716.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The expectation is that it returns the memory footprint of the given
> > object, and only it (not taking into account sharing, caching,
> > dependencies or anything else).
> 
> It would be nice if this was a well-defined definition, but
> unfortunately it is not.

I didn't claim it was. Actually, if you read the rest of my message, I
did mention that PyPy could tweak the semantics if it made more sense.
So, of course, the more sharing and caching takes place, the less
obvious these semantics are, but even with CPython they are not obvious
anyway. It's not supposed to be an exact measurement for the common
developer, rather a hint that experts can use to tweak their data
structures and algorithms; you need to know details of your VM's
implementation to use that information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:18:34 2011
From: report at bugs.python.org (Day Barr)
Date: Tue, 25 Jan 2011 17:18:34 +0000
Subject: [docs] [issue11008] logging.dictConfig not documented as new in
	version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>


New submission from Day Barr <bugs.python.org at daybarr.com>:

logging.dictConfig is new in version 2.7 but the documentation does not say this.

http://docs.python.org/release/2.7/library/logging.html#logging.dictConfig

c.f. NullHandler, also new in version 2.7 and explicitly documented as such:

http://docs.python.org/release/2.7/library/logging.html#nullhandler

----------
assignee: docs at python
components: Documentation
messages: 127024
nosy: daybarr, docs at python
priority: normal
severity: normal
status: open
title: logging.dictConfig not documented as new in version 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:41:55 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 25 Jan 2011 17:41:55 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295977315.39.0.359511117809.issue10994@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

I can hardly think about a specification that would potentially help me identify actual sizes. Even as a rough estimation. Which experts you had in mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:43:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 17:43:37 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295977315.39.0.359511117809.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295977414.3716.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Which experts you had in mind?

People who know how the Python implementation works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:52:42 2011
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 25 Jan 2011 17:52:42 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295977961.92.0.336302741306.issue10994@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

> > Which experts you had in mind?

> People who know how the Python implementation works.

I'm serious. What semantics would make sense to anyone? Even if you know implementation quite well a single number per object does not provide enough information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 18:59:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Jan 2011 17:59:47 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295978387.19.0.188357716699.issue10994@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You could return -1 for everything. =)

In all seriousness, it could simply be proportional. IMO as long as people realize if a list takes up less space than a dict then the numbers seem fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 19:00:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Jan 2011 18:00:34 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295977961.92.0.336302741306.issue10994@psf.upfronthosting.co.za>
Message-ID: <1295978430.3716.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Even if you know implementation quite well a single number per object
> does not provide enough information.

Enough information for what? It can certainly provide information about
the overhead of that particular object (again, regardless of sharing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue Jan 25 21:24:38 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 25 Jan 2011 20:24:38 +0000
Subject: [docs] [issue11009] urllib.splituser is not documented
In-Reply-To: <1295987078.02.0.421774194417.issue11009@psf.upfronthosting.co.za>
Message-ID: <1295987078.02.0.421774194417.issue11009@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I'm studying old code that uses urllib.splituser() call and can't find description of this function in Python 2.6.6 docs.

----------
assignee: docs at python
components: Documentation
messages: 127047
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: urllib.splituser is not documented
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11009>
_______________________________________

From report at bugs.python.org  Tue Jan 25 23:18:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 25 Jan 2011 22:18:21 +0000
Subject: [docs] [issue9724] help('nonlocal') missing
In-Reply-To: <1283264506.65.0.891353538251.issue9724@psf.upfronthosting.co.za>
Message-ID: <1295993901.43.0.0218828242868.issue9724@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Was this left out of 3.1 and 2.7 on purpose?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9724>
_______________________________________

From report at bugs.python.org  Wed Jan 26 03:46:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 26 Jan 2011 02:46:09 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The test.support docs are there to help CPython devs with writing good unit tests more easily. There are a few additions we've made in recent years that haven't made it into the .rst file, so it is easy to miss useful tools if you don't go looking through the module source code.

There are some other helper modules (such as test.script_helper) that could also stand to be made easier to find.

Fixing this is just a matter of doing a pass through test.support and the test directory looking for things that might be worth mentioning in the test package docs.

----------
assignee: docs at python
keywords: easy
messages: 127086
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Bring test.support docs up to date
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From eliben at gmail.com  Wed Jan 26 05:53:13 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Wed, 26 Jan 2011 06:53:13 +0200
Subject: [docs] documentation suggestion
In-Reply-To: <alpine.DEB.2.00.1101231524460.22676@orwell.homelinux.org>
References: <alpine.DEB.2.00.1101231524460.22676@orwell.homelinux.org>
Message-ID: <AANLkTikONuV2YJJszkaqoPsaUwgjtSoNs3g+T6FPBuV2@mail.gmail.com>

> In http://docs.python.org/library/functions.html#open
>
> "Modes 'r+', 'w+' and 'a+' open the file for updating (note that 'w+'
> truncates the file)."
>
> The term "open the file for updating" means nothing to me in this context.
>
>> From other place I learned this means that 'w+' means open for both
>>
> writing and reading and creates file if it does not exist and truncates
> file if it exists. 'a+' means appending and reading. 'r+' also means open
> for reading and writing but does not create file if it does not exist, as
> well as does not truncate the file if it does exist.
>
> I'm still not exactly clear what the difference between 'r+' and 'a+' is
> then, if 'r+' does not truncate the file.
>
> In any case, I suggest removing the word 'updating' and adding a
> description of what the '+' actually does.
>
> See
> http://stackoverflow.com/questions/1466000/python-open-built-in-function-difference-between-modes-a-a-w-w
>

Although this SO question you're linking to probably isn't the best
candidate for a good question (as its score and comments demonstrate), but
underneath it all I find that the reference for C's `fopen` indeed doesn't
use the verb "update".

For example, for "w+" it says:

Open for reading and writing. The file is created if it does not exist,
otherwise it is truncated. The stream is positioned at the beginning of the
file.

So I think this is something that can be considered.
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110126/e32e728a/attachment.html>

From report at bugs.python.org  Wed Jan 26 18:54:40 2011
From: report at bugs.python.org (David Stanek)
Date: Wed, 26 Jan 2011 17:54:40 +0000
Subject: [docs] [issue3849] FUD in documentation for urllib.urlopen()
In-Reply-To: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>
Message-ID: <1296064480.9.0.567631729328.issue3849@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3849>
_______________________________________

From report at bugs.python.org  Thu Jan 27 04:56:49 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 27 Jan 2011 03:56:49 +0000
Subject: [docs] [issue3849] FUD in documentation for urllib.urlopen()
In-Reply-To: <1221246343.23.0.128587140594.issue3849@psf.upfronthosting.co.za>
Message-ID: <1296100609.76.0.735624662517.issue3849@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3849>
_______________________________________

From report at bugs.python.org  Thu Jan 27 12:42:30 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 27 Jan 2011 11:42:30 +0000
Subject: [docs] [issue11008] logging.dictConfig not documented as new in
	version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1296128550.42.0.204573784466.issue11008@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This also applies to Python 3.2 docs. I've made the changes - OK to checkin, Georg? (For 3.2, I mean)

----------
assignee: docs at python -> vinay.sajip
nosy: +georg.brandl, vinay.sajip
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Thu Jan 27 14:17:15 2011
From: report at bugs.python.org (Alan Isaac)
Date: Thu, 27 Jan 2011 13:17:15 +0000
Subject: [docs] [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>


New submission from Alan Isaac <alan.isaac at gmail.com>:

In PEP 227 missing text is marked with XXX.  Most of this is just calls for examples and elaboration.  However under the Implementation section XXX marks a substantive question about the documentation.

Fixing this may be low priority, but a tracker search suggested it is currently not even being tracked ...

----------
assignee: docs at python
components: Documentation
messages: 127184
nosy: aisaac, docs at python
priority: normal
severity: normal
status: open
title: pep 227 missing text
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Thu Jan 27 18:49:23 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 27 Jan 2011 17:49:23 +0000
Subject: [docs] [issue11008] logging.dictConfig not documented as new in
	version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1296150562.99.0.24230178154.issue11008@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, please go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Thu Jan 27 19:51:32 2011
From: report at bugs.python.org (Michal Nowikowski)
Date: Thu, 27 Jan 2011 18:51:32 +0000
Subject: [docs] [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1296154292.53.0.825543849006.issue10999@psf.upfronthosting.co.za>


Changes by Michal Nowikowski <godfryd at gmail.com>:


----------
nosy: +godfryd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Thu Jan 27 20:17:32 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 27 Jan 2011 19:17:32 +0000
Subject: [docs] [issue11008] logging.dictConfig not documented as new in
	version 2.7
In-Reply-To: <1295975914.25.0.0685930703721.issue11008@psf.upfronthosting.co.za>
Message-ID: <1296155852.16.0.893021907658.issue11008@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k and release27-maint (r88214).

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11008>
_______________________________________

From report at bugs.python.org  Thu Jan 27 21:46:04 2011
From: report at bugs.python.org (Michal Nowikowski)
Date: Thu, 27 Jan 2011 20:46:04 +0000
Subject: [docs] [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1296161163.96.0.0934186404848.issue10999@psf.upfronthosting.co.za>


Michal Nowikowski <godfryd at gmail.com> added the comment:

I have prepared a patch that:
- documents flags for os.chflags function in stat module
- adds links for these flags os module to stat module.

----------
components: +None
keywords: +patch
Added file: http://bugs.python.org/file20555/documented-os_chflags-flags.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Fri Jan 28 04:03:33 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 03:03:33 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296183813.32.0.133822331993.issue11015@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 04:42:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 03:42:25 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296186145.19.0.681643083837.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I don't know if it matters much, but there's a slight mismatch in the description of test.support.verbose. The documentation says it's a boolean, while it's 0 or 1 in reality. 

Can it just be changed to True/False in the code of test.support and test.regrtest? It appears that all the other flags are True/False and there's no reason to keep this 0/1 (which is probably a relic from a distant past)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 05:19:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 04:19:54 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296188394.84.0.273645672307.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Here's a patch fixing the 0/1 to True/False in a couple of places in test.support and test.regrtest

I ran the test suite and it passes.

A review is needed to commit. I'll keep working on the documentation itself in the meantime.

----------
keywords: +patch
Added file: http://bugs.python.org/file20564/issue11015.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 06:38:13 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 05:38:13 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296193092.57.0.72935060046.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Here's a patch to Doc/library/test.rst with additional several exported functions documented. These are the ones I found most important and clear. fcmp() is currently not documented (pending discussion in pydev).

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20567/issue11015.py3k.testdoc.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 10:23:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Jan 2011 09:23:53 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296206633.85.0.805425851768.issue11015@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

verbose isn't a boolean at all - it's an integer. You can supply it multiple times to bump the logging level up even higher than normal.

~/devel/py3k/Lib/test$ grep "verbose >" *.py
regrtest.py:                    if self.verbose > 1:
test_cmd_line_script.py:        if verbose > 1:
test_cmd_line_script.py:        if verbose > 1:
test_cmd_line_script.py:        if verbose > 1:
test_cmd_line_script.py:                if verbose > 1:
test_cmd_line_script.py:                    if verbose > 1:
test_fork1.py:                    if verbose > 1:
test_fork1.py:                    if verbose > 1:

(I didn't check explicitly, but I believe those verbose values are shorthand references to test.support.verbose)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:03:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 13:03:20 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296219800.67.0.945650661816.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Nick, agreed regarding verbose. Somehow I didn't think it would be used in other modules like that, and only looked in regrtest where I didn't see anything meaningful about verbose not being binary.

It's a good thing to document it, then :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 14:03:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 28 Jan 2011 13:03:25 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296219805.84.0.874172268612.issue11015@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file20564/issue11015.py3k.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Jan 28 17:38:12 2011
From: report at bugs.python.org (Scott M)
Date: Fri, 28 Jan 2011 16:38:12 +0000
Subject: [docs] [issue11029] Crash, 2.7.1,
	Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296232692.27.0.198807278882.issue11029@psf.upfronthosting.co.za>


Scott M <scott.mayo at comcast.net> added the comment:

Alright. More digging turned up the Tkinter "after" function, aka WM_TIMER for Windowy people like me, and that plus a nonblocking queue get() gets all my drawing operations back into the mainLoop() thread. Voil?, no more crashes.

Let me suggest that page one, sentence one of any Tkinter documentation should begin "Tkinter is not thread safe", with a link to an example of after() and nonblocking get(). I've changed the component to Documentation. This would save a few days for poor sods like me -- I'm used to low level Windows C++ GUI work, where any thread can call any SDK function at any time, and Windows sorts it all out. 

Having to force everything into a single thread, and then poll for my data (*GAG*), is something I thought died in the 80's. Is anyone looking at thread safe GUI libraries?

----------
assignee:  -> docs at python
components: +Documentation -Tkinter
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Fri Jan 28 17:53:28 2011
From: report at bugs.python.org (Oren Held)
Date: Fri, 28 Jan 2011 16:53:28 +0000
Subject: [docs] [issue11047] Bad description for a change
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

In the "what's new in 2.7", there is some mistake in the description of issue 7902.

7902, afaik, disables the fallback to absolute import, when requesting a relative import fails. If I got it right, the description states the opposite.

----------
assignee: docs at python
components: Documentation
files: whatsnew_issue_7902_fix.patch
keywords: patch
messages: 127317
nosy: Oren_Held, docs at python
priority: normal
severity: normal
status: open
title: Bad description for a change
versions: Python 2.7
Added file: http://bugs.python.org/file20577/whatsnew_issue_7902_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11047>
_______________________________________

From report at bugs.python.org  Fri Jan 28 22:05:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Jan 2011 21:05:22 +0000
Subject: [docs] [issue11029] Crash, 2.7.1,
	Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1296248722.02.0.97829825778.issue11029@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There are other gui libraries with Python interfaces that you can look at. I agree that something in doc about how to feed data from multiple threads would be nice.

----------
nosy: +terry.reedy
type: crash -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11029>
_______________________________________

From report at bugs.python.org  Sat Jan 29 15:31:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 29 Jan 2011 14:31:32 +0000
Subject: [docs] [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1296311492.98.0.624882649291.issue11015@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Sat Jan 29 18:46:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 17:46:04 +0000
Subject: [docs] [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <1296323164.46.0.953279907131.issue11047@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +barry, brett.cannon, flox, gangesmaster, loewis, meador.inge
title: Bad description for a change -> Bad description for an entry in whatsnew/2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11047>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:08:52 2011
From: report at bugs.python.org (Dustin Farris)
Date: Sat, 29 Jan 2011 18:08:52 +0000
Subject: [docs] [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>


New submission from Dustin Farris <dustin.farris at gmail.com>:

Running help(abc) in Python 2.6.1 displays syntax for Py3k.

----------
assignee: docs at python
components: Documentation
messages: 127453
nosy: docs at python, dustin.farris
priority: normal
severity: normal
status: open
title: abc documentation version conflict
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:11:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 Jan 2011 18:11:28 +0000
Subject: [docs] [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296324688.69.0.734041634177.issue11064@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not for me:
     |      class C:
     |          __metaclass__ = ABCMeta
     |          @abstractproperty

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From report at bugs.python.org  Sat Jan 29 19:14:08 2011
From: report at bugs.python.org (Dustin Farris)
Date: Sat, 29 Jan 2011 18:14:08 +0000
Subject: [docs] [issue11064] abc documentation version conflict
In-Reply-To: <1296324532.36.0.0952185002021.issue11064@psf.upfronthosting.co.za>
Message-ID: <1296324848.67.0.145026906547.issue11064@psf.upfronthosting.co.za>


Dustin Farris <dustin.farris at gmail.com> added the comment:

This is what I get:


Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import abc
>>> help(abc)

NAME
    abc - Abstract Base Classes (ABCs) according to PEP 3119.

FILE
    /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/abc.py


.....


|  Usage:
     |  
     |      class C(metaclass=ABCMeta):
     |          @abstractproperty
     |          def my_abstract_property(self):
     |              ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11064>
_______________________________________

From dgrivas at estudiantes.uci.cu  Sat Jan 29 23:11:55 2011
From: dgrivas at estudiantes.uci.cu (=?ISO-8859-1?Q?Alexis_L=F3pez_Zubieta?=)
Date: Sat, 29 Jan 2011 17:11:55 -0500
Subject: [docs] Documentation Bug
Message-ID: <4D4490AB.1030202@estudiantes.uci.cu>

Were it says "truncates" should say "rounds".
Because:
pi truncated to 3 decimal positions is 3.141 and pi rounded to 3 decimal 
positions is 3.142.

Greetings
Alexis L?pez Zubieta



-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pantallazo.png
Type: image/png
Size: 309806 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20110129/41f3cf30/attachment-0001.png>

From report at bugs.python.org  Mon Jan 31 02:40:24 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 31 Jan 2011 01:40:24 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1296438024.73.0.844477338215.issue9362@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

This is annoying. Every beginner's Python tutorial I've read made it very clear how to exactly exit the interactive shell. Ctrl has been in use for years. Changing it for novices' sake is ridiculous. Do we need to expand every abbreviation? Python will turn into Java (joke). As for Ctrl-D or Ctrl-Z, I think it's fine the way it is. Python is used for scripting, and Windows administators are familiar with Ctrl-Z for EOF but may not necessarily be familiar with Ctrl-D.

Ok, in final, I think the only thing that might be changed is the shell's opening message:

Python 3.1.3 (r313:86834, Jan 28 2011, 20:00:55) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Type "exit()", "quit()" or Ctrl-D (i.e. EOF) to exit.
>>> 

On Windows, Ctrl-D is replaced with Ctrl-Z.

----------
nosy: +anikom15

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9362>
_______________________________________

From report at bugs.python.org  Mon Jan 31 02:42:52 2011
From: report at bugs.python.org (Roy Smith)
Date: Mon, 31 Jan 2011 01:42:52 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The documentation for the threading.Thread constructor says:

"target is the callable object to be invoked by the run() method. Defaults to None, meaning nothing is called."

This could be improved by explicitly stating that target is called in a static context.  As written, it takes a bit of thought (and experimentation) to be sure of that.

----------
assignee: docs at python
components: Documentation
messages: 127566
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: threading.Thread documentation can be improved
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 04:10:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 03:10:49 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296443449.43.0.320095931032.issue11073@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I have no idea what "a static context" means, so it wouldn't make it any clearer to me.  Can you explain further what your confusion is?

----------
nosy: +r.david.murray
type:  -> feature request
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 04:23:23 2011
From: report at bugs.python.org (Roy Smith)
Date: Mon, 31 Jan 2011 03:23:23 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296444203.23.0.0742778973692.issue11073@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

What I meant was whether target should be declared as @staticmethod or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 05:45:53 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 31 Jan 2011 04:45:53 +0000
Subject: [docs] [issue10480] cgi.py should document the need for binary
	stdin/stdout
In-Reply-To: <1290318189.86.0.129478140251.issue10480@psf.upfronthosting.co.za>
Message-ID: <1296449153.25.0.699088964306.issue10480@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Fixed by issue 10841 and issue 4953.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10480>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:00:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 08:00:01 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296460801.56.0.866238681087.issue11073@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I still don't understand.  I haven't used threading much, but I don't believe I've ever used a static method with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 09:15:25 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 08:15:25 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296461725.26.0.569930266531.issue11073@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Roy, it's not clear what you're after.  What is it that you think is special about the way the target is called?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 11:14:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 31 Jan 2011 10:14:46 +0000
Subject: [docs] [issue10891] Tweak sorting howto to eliminate redundancy
In-Reply-To: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>
Message-ID: <1296468886.39.0.0539473123567.issue10891@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

You can put in the backslashes before the two periods, but not the other changes.  I want the method names to continue to be spelled-out in full so that it is more clear what they are referring to.  Even in spoken English, I typically say "list sort" or "sort method of the builtin list type".  This helps distinguish it from the sorted() builtin.

----------
assignee: rhettinger -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10891>
_______________________________________

From report at bugs.python.org  Mon Jan 31 14:19:15 2011
From: report at bugs.python.org (Roy Smith)
Date: Mon, 31 Jan 2011 13:19:15 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296479955.54.0.0108216353033.issue11073@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Here's the code I ended up writing:

class Foo():
   def __init__(self):
       self.thread = Thread(target=Foo.runner, args=[self])
       self.thread.start()

   @staticmethod
   def runner(self):
      # blah, blah, blah

It was not immediately clear from the documentation if my runner() method should be declared static or not.  In retrospect, it must be (since this can be used with target functions which are not class methods at all), but it took a bit of thought to get from what the documentation said (i.e. 'callable object to be invoked by the run() method') to that conclusion.  

It seems to me the documentation could be a bit more explicit that your target does not get called as a method of some object.  Changing the text to read, "static function or other callable object" would remove any such confusion.

It could be that some of my confusion is due to my previously working with a C++ threading package where the thread runner functions *were* class methods.  Still, it seems like the potential for other people to be similarly confused exists and a little tweaking of the documentation text would help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 15:35:35 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 31 Jan 2011 14:35:35 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296484535.28.0.308115912558.issue11073@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> It was not immediately clear from the documentation if my runner() method should be declared static or not.

The doc doesn't mention static methods at all, and my uses and others that I've seen have never used static methods.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 15:40:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 14:40:19 +0000
Subject: [docs] [issue11073] threading.Thread documentation can be improved
In-Reply-To: <1296438172.29.0.214693848128.issue11073@psf.upfronthosting.co.za>
Message-ID: <1296484819.03.0.648963830001.issue11073@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You don't have to use any staticmethod here (actually, staticmethod is an anti-pattern in Python). Just write:

class Foo():
   def __init__(self):
       self.thread = Thread(target=self.runner)
       self.thread.start()

   def runner(self):
      # blah, blah, blah

----------
nosy: +pitrou
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11073>
_______________________________________

From report at bugs.python.org  Mon Jan 31 19:41:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 31 Jan 2011 18:41:42 +0000
Subject: [docs] [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1296499302.67.0.64892169977.issue11023@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Eric, what you say is technically true, but we don't have any other place to track PEP bugs.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11023>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:22:23 2011
From: report at bugs.python.org (Federico Culloca)
Date: Mon, 31 Jan 2011 19:22:23 +0000
Subject: [docs] [issue11083] threading.Thread - start() rises
	RuntimeException?
In-Reply-To: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za>
Message-ID: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za>


New submission from Federico Culloca <djthrottle at gmail.com>:

In the threading module documentation, about the start() method of the threading.Thread class, it says that, upon calling start() more then once, a RuntimeException is raised. I couldn't find in the whole documentation other references to this "RuntimeException".

Maybe it's RuntimeError?

----------
assignee: docs at python
components: Documentation
messages: 127647
nosy: Federico.Culloca, docs at python
priority: normal
severity: normal
status: open
title: threading.Thread - start() rises RuntimeException?
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11083>
_______________________________________

From report at bugs.python.org  Mon Jan 31 20:36:18 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 31 Jan 2011 19:36:18 +0000
Subject: [docs] [issue11083] threading.Thread - start() rises
	RuntimeException?
In-Reply-To: <1296501743.29.0.748896290236.issue11083@psf.upfronthosting.co.za>
Message-ID: <1296502578.66.0.65657455335.issue11083@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Thanks, fixed in r88281. Back porting to the other branches as well.

----------
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11083>
_______________________________________

From bergstiger.s at gmail.com  Mon Jan 31 10:55:50 2011
From: bergstiger.s at gmail.com (Jan Hollerer)
Date: Mon, 31 Jan 2011 10:55:50 +0100
Subject: [docs] pythonS60-5thED colors
Message-ID: <AANLkTimByQ-vyJ9sVh_B7Zn4UCkyF7yBfa8u04iHVyy+@mail.gmail.com>

dear all

i managed to install pythonS60 version on my new nokia device.
unfortunately it doesnt seem possible to change the background or the font
color of the python console after looking through the web.

so i would like to ask directly if it is possible to change these colors
like os.system("color 0F")???

regards

-- 
Der Mensch ist elastbar.
Er schrumpft am Tage, vor der Gr?sse vor sich selbst.
         Yvo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110131/2ca97e98/attachment-0001.html>

From Th.A.M.Mars at skf-rif.nl  Mon Jan 31 12:21:02 2011
From: Th.A.M.Mars at skf-rif.nl (Theo Mars)
Date: Mon, 31 Jan 2011 12:21:02 +0100
Subject: [docs] tkinter messagebox
Message-ID: <728D995326EBD042AFDA3CF28821DE65457837@rif-ex02.skf-rif.nl>

calling the tkinter  messagebox in a shellwindow works fine but when I
run the application as a .pyw application

the application crashes. Does anyone has a suggestion what is going
wrong here?

 

The code to test is (file test.pyw):

 

from tkinter import *

from tkinter import ttk

 

root = Tk()

messagebox.showwarning(title='title', message='message')

root.mainloop()

 

 

I'am using python 3.1.1 on windows xp

 

Kind regards,

 

T. Mars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110131/e75e4a3e/attachment-0001.html>