-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 5690 bytes
Desc: image002.jpg
URL: 

From georg at python.org  Thu Sep 22 10:29:37 2011
From: georg at python.org (Georg Brandl)
Date: Thu, 22 Sep 2011 10:29:37 +0200
Subject: [docs] Little Tutorial Correction
In-Reply-To: <3635BC3AE91B644ABFACC65FC70023FA2105B398FF@CDECLUEXMBX01.corp.draeger.global>
References: <3635BC3AE91B644ABFACC65FC70023FA2105B398FF@CDECLUEXMBX01.corp.draeger.global>
Message-ID: <4E7AF1F1.9020308@python.org>

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

Am 22.09.2011 10:12, schrieb Petersen, Eike:
> Hello,
> 
> http://docs.python.org/tutorial/introduction.html#lists under this section
> I read across the following statement:
> 
> ?All slice operations return a new list containing the requested elements. 
> This means that the following slice returns a shallow copy of the list 
> //a//:
> 
>>>> a[:]?
> 
> But as far as I know the behaviour of the [:] operator is on the contrary 
> called deep copying, since the following will return different lists:
> 
> A = [1,2,3] B =A[:] A[1]=3

Hi Eike,

Python does indeed to only a shallow copy, since it does not copy the objects
themselves.  To see this, you can try something like this:

>>> a = [[1, 2], [3]] b = a[:] a[0][0] = 999 a[0]
[999, 2]
>>> b[0]
[999, 2]

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

iEYEARECAAYFAk568fEACgkQN9GcIYhpnLBc7wCeNwbMJfX391dx0yO56Wo1jMYi
PioAoIIgwYl4N2Od+s9ceH5WFFvFydX4
=3pMf
-----END PGP SIGNATURE-----

From report at bugs.python.org  Thu Sep 22 21:00:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 19:00:24 +0000
Subject: [docs] [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316718024.54.0.124032574679.issue12902@psf.upfronthosting.co.za>

Ezio Melotti  added the comment:

Since help("modules") just shows a list of modules without any description, maybe it could avoid importing them until further information about individual modules are requested.

Also while trying to do help("modules") twice on py3k, I noticed that the second time many modules are missing from the list.  Is this expected and/or a known issue?

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:31:51 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 22 Sep 2011 21:31:51 +0000
Subject: [docs] [issue13030] Be more generic when identifying the Windows
	main dir in	installation doc
Message-ID: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>

New submission from Sandro Tosi :

Given I have no knowledge of the windows system, I'm just proxying http://mail.python.org/pipermail/docs/2011-September/005793.html :

>>>
Under: http://docs.python.org/install/index.html#inst-how-install-works

It notes "Windows	prefix\Lib\site-packages	C:\PythonXY\Lib\site-packages"
for default values on Windows.

In the paragraph following the table is the text: "prefix and
exec-prefix stand for the directories that Python is installed to, and
where it finds its libraries at run-time. They are always the same
under Windows, and very often the same under Unix and Mac OS X. "

I don't know if it's hardcoded into Python distributions to use C, but
it's not correct. The correct way to identify what most people think
of as C is via the %SYSTEMROOT% environment variable, so the path
described would be "%SYSTEMROOT%\PythonXY\Lib\site-packages"

(This is still not the correct way to do things on Windows, but it at
least shouldn't break on systems with a %SYSTEMROOT% other than C.
I've seen configurations like that on systems which boot multiple
versions of Windows.)
<<<

----------
assignee: docs at python
components: Documentation
messages: 144422
nosy: brian.curtin, docs at python, sandro.tosi, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: Be more generic when identifying the Windows main dir in installation doc
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From sandro.tosi at gmail.com  Thu Sep 22 23:32:42 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 22 Sep 2011 23:32:42 +0200
Subject: [docs] Bug in http://docs.python.org/install/index.html
In-Reply-To: 
References: 
Message-ID: 

Hi Michael,
thanks for your email

On Wed, Sep 21, 2011 at 16:49, Michael Mol  wrote:
> Under: http://docs.python.org/install/index.html#inst-how-install-works
>
>
> It notes "Windows ? ? ? prefix\Lib\site-packages ? ? ? ?C:\PythonXY\Lib\site-packages"
> for default values on Windows.
>
> In the paragraph following the table is the text: "prefix and
> exec-prefix stand for the directories that Python is installed to, and
> where it finds its libraries at run-time. They are always the same
> under Windows, and very often the same under Unix and Mac OS X. "
>
> I don't know if it's hardcoded into Python distributions to use C, but
> it's not correct. The correct way to identify what most people think
> of as C is via the %SYSTEMROOT% environment variable, so the path
> described would be "%SYSTEMROOT%\PythonXY\Lib\site-packages"
>
> (This is still not the correct way to do things on Windows, but it at
> least shouldn't break on systems with a %SYSTEMROOT% other than C.
> I've seen configurations like that on systems which boot multiple
> versions of Windows.)

I've opened http://bugs.python.org/issue13030 to track your request.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Thu Sep 22 23:37:10 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 22 Sep 2011 23:37:10 +0200
Subject: [docs] Suggestion on Python documentation
In-Reply-To: <2b841ae44bb43a9bacd3b567c71d5f94.squirrel@mail.rissanen.biz>
References: <2b841ae44bb43a9bacd3b567c71d5f94.squirrel@mail.rissanen.biz>
Message-ID: 

Hi Hessu,
thanks a lot for your input!

On Sun, Sep 18, 2011 at 12:19, Hessu  wrote:
> Hi guys,
>
> I have been programming with 10+ languages at some point of my life but
> I'm new in Python so some things just pop up when I'm trying to understand
> the world of Python.

It's really important the judgment of our users: the reader of the
docs, in particularly those looking for to build skills in the
language, because it gives us a new point-of-view.

> I suggest that the documentation should include much more examples or links.

You may well understand we'd need some examples :)

The longer the list, the better, actually.

> Here's one example from: http://docs.python.org/library/os.path.html
>
> "os.path.abspath(path): Return a normalized absolutized version of the
> pathname path. On most platforms, this is equivalent to
> normpath(join(os.getcwd(), path))"
>
> I'm sure that this explanation is probably very true but a simple example
> would make it also useful.

Could you please provide a snippet of code you consider worth adding
to the doc for os.path.abspath() ? Ideally it would be nice if you can
report and issue to http://bugs.python.org, but it's fine if you
follow up here, I'll just proxy to the issue tracker when needed.

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  Thu Sep 22 23:51:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Sep 2011 21:51:44 +0000
Subject: [docs] [issue13026] Dis module - documentation of MAKE_FUNCTION
In-Reply-To: <1316642558.64.0.601129278503.issue13026@psf.upfronthosting.co.za>
Message-ID: <1316728304.51.0.134289004232.issue13026@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

Agreed

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:57:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Sep 2011 21:57:32 +0000
Subject: [docs] [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316728652.83.0.341054847373.issue12902@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

As I said in msg143786, the second time only c-coded modules are listed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 00:03:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 22:03:16 +0000
Subject: [docs] [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316728996.43.0.672019306441.issue12902@psf.upfronthosting.co.za>

Ezio Melotti  added the comment:

Right, I missed that.
If we change the way the list is created this bug will be probably get fixed too.  If we don't, we should open another issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 01:40:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 23:40:15 +0000
Subject: [docs] [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316734814.9.0.254846330826.issue12902@psf.upfronthosting.co.za>

Ezio Melotti  added the comment:

> A separate issue would be a feature request to not do that (assuming it really does).

I tried to verify this (the fact that modules get imported with help('modules')).  Here are the results:
  * Lib/foobar.py:
    - help('modules'): foobar in the list, code is *not* executed;
    - help('foobar'): code is executed;
  * Lib/deleteme/__init__.py:
    - help('modules'): deleteme in the list, code is executed;
    - help('deleteme'): code is executed;
  * Lib/deleteme/__init__.py and Lib/deleteme/foobar.py:
    - help('modules'): deleteme in the list, only __init__ code is executed;
    - help('deleteme.foobar'): foobar code is executed;

So it seems the only code that gets executed with help('modules') is the one in packages' __init__s.  It also seems that the code is executed only once, so doing help('deleteme') after help('modules') doesn't execute the code again.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 05:55:27 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 23 Sep 2011 03:55:27 +0000
Subject: [docs] [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316750126.45.0.500259482176.issue12943@psf.upfronthosting.co.za>

Meador Inge  added the comment:

> I don't think the help option needs to be documented, it will document 
> itself.

Normally I would document it anyway, but in this case there is only the
one option.  So, I dropped it.

> An additional suggestion is to catch errors on tokenizing and exiting 
> with a non-zero exit status in these cases.

I like that idea.  Sample output:

$ python -m tokenize foo.py
foo.py: error: unknown encoding: meador
$ python -m tokenize foo.py
foo.py:7:2: error: unindent does not match any outer indentation level
$ ./python -m tokenize bogus.py
error: [Errno 2] No such file or directory: 'bogus.py'
$ python -m tokenize foo.py
$ echo '[1,' | ./python -m tokenize
1,0-1,1:            OP             '['            
1,1-1,2:            NUMBER         '1'            
1,2-1,3:            OP             ','            
1,3-1,4:            NL             '\n'           
:2:0: error: EOF in multi-line statement

Attached is the latest patch implementing these suggestions.

----------
Added file: http://bugs.python.org/file23228/issue12943-5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 07:20:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 23 Sep 2011 05:20:11 +0000
Subject: [docs] [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316755211.55.0.0983796144842.issue12943@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

I would say this looks good now.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 21:50:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Sep 2011 19:50:24 +0000
Subject: [docs] [issue13030] Be more generic when identifying the Windows
	main dir in	installation doc
In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>
Message-ID: <1316807424.78.0.299863901397.issue13030@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

Windows does not require that executables be on any particular 'drive'.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 22:49:58 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 20:49:58 +0000
Subject: [docs] [issue13047] imp.find_module("") and imp.find_module(".")
Message-ID: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>

New submission from Arfrever Frehtes Taifersar Arahesis :

It's undocumented that imp.find_module("") and imp.find_module(".") try to find __init__.py.

There is also a small difference in behavior between them.
sys.path by default contains "" as the first element, which is sufficient for imp.find_module("."), but not for imp.find_module(""):

$ mkdir /tmp/imp_tests
$ cd /tmp/imp_tests
$ touch __init__.py
$ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module("."))'
''
(None, '.', ('', '', 5))
$ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module(""))'
''
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named ''

If sys.path contains path (e.g. "." or absolute path) to directory with __init__.py file, then imp.find_module("") will succeed:

$ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module("."))'
['', '/tmp/imp_tests']
(None, '.', ('', '', 5))
$ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module(""))'
['', '/tmp/imp_tests']
(None, '/tmp/imp_tests/', ('', '', 5))
$ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module("."))'
['', '.']
(None, '.', ('', '', 5))
$ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module(""))'
['', '.']
(None, './', ('', '', 5))

I think that imp.find_module(".") and imp.find_module("") should have the same behavior, and this behavior should be documented.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 144531
nosy: Arfrever, docs at python
priority: normal
severity: normal
status: open
title: imp.find_module("") and imp.find_module(".")
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 22:54:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Sep 2011 20:54:09 +0000
Subject: [docs] [issue13047] imp.find_module("") and imp.find_module(".")
In-Reply-To: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>
Message-ID: <1316984049.79.0.578483974253.issue13047@psf.upfronthosting.co.za>

Changes by Ezio Melotti :

----------
nosy: +brett.cannon, ezio.melotti, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 23:05:33 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 21:05:33 +0000
Subject: [docs] [issue13048] Handling of paths in first argument of
	imp.find_module()
Message-ID: <1316984733.77.0.135974751185.issue13048@psf.upfronthosting.co.za>

New submission from Arfrever Frehtes Taifersar Arahesis :

It's undocumented that imp.find_module() supports paths with "/" as the first argument:

$ mkdir /tmp/imp_tests
$ cd /tmp/imp_tests
$ mkdir a
$ touch a/b.py
$ python3.3 -c 'import imp; print(imp.find_module("a/b"))'
(<_io.TextIOWrapper name=4 mode='U' encoding='utf-8'>, 'a/b.py', ('.py', 'U', 1))

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 144532
nosy: Arfrever, brett.cannon, docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: Handling of paths in first argument of imp.find_module()
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 23:14:07 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 21:14:07 +0000
Subject: [docs] [issue11676] Improve imp.load_module and submodules doc
In-Reply-To: <1301089227.12.0.157951103986.issue11676@psf.upfronthosting.co.za>
Message-ID: <1316985247.62.0.444169539435.issue11676@psf.upfronthosting.co.za>

Changes by Arfrever Frehtes Taifersar Arahesis :

----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 20:03:50 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Sep 2011 18:03:50 +0000
Subject: [docs] [issue13048] Handling of paths in first argument of
	imp.find_module()
In-Reply-To: <1316984733.77.0.135974751185.issue13048@psf.upfronthosting.co.za>
Message-ID: <1317060230.58.0.140442597655.issue13048@psf.upfronthosting.co.za>

Brett Cannon  added the comment:

It's probably not a bad thing it's undocumented either since importing by file path was removed in Python 3, so this is another case where imp.find_module() differentiates from __import__.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 20:04:42 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Sep 2011 18:04:42 +0000
Subject: [docs] [issue13047] imp.find_module("") and imp.find_module(".")
In-Reply-To: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>
Message-ID: <1317060282.16.0.505030517667.issue13047@psf.upfronthosting.co.za>

Brett Cannon  added the comment:

I don't think this is undocumented as much as it's unexpected behavior. I really doubt this functionality was  on purpose.

----------

_______________________________________
Python tracker 

_______________________________________

From dfsmith at dfsmith.net  Fri Sep 23 09:03:31 2011
From: dfsmith at dfsmith.net (Daniel Smith)
Date: Fri, 23 Sep 2011 00:03:31 -0700
Subject: [docs] Prime numbers
Message-ID: <4E7C2F43.20007@dfsmith.net>

In section 5.1.3 for filter() at
http://docs.python.org/tutorial/datastructures.html;
the description says "For example, to compute primes up to 25:"

However, the output "[5, 7, 11, 13, 17, 19, 23]" omits both the prime 2 
and the prime 3.  (And would list many non-primes >24 if the range were 
increased.)

The example is still useful and relevant, but the description is very 
misleading.

(In fact, I might cite the page on Wikipedia as a sieve algorithm, and 
see how many times 25 is listed as prime... B-)

Daniel Smith, nitpicker.

From katazina.zigo at gmail.com  Sat Sep 24 07:50:00 2011
From: katazina.zigo at gmail.com (Katazina Zigo)
Date: Sat, 24 Sep 2011 07:50:00 +0200
Subject: [docs] 24.6 Idle correction
Message-ID: 

Hi guys,

At http://docs.python.org/library/idle.html:
"cross-platform: works on Windows and Unix" > it works also on Mac

From ajhill007 at gmail.com  Mon Sep 26 14:55:29 2011
From: ajhill007 at gmail.com (AJ Hill)
Date: Mon, 26 Sep 2011 07:55:29 -0500
Subject: [docs] Confusing comment in docs for 3.2.2 section 2.1
Message-ID: 

To the wonderful folks who look after the Python docs,

There is a confusing comment in the last paragraph of section 2.1, Invoking
the Python Interpreter, of the 3.2.2 docs.

Here is the page URL:

http://docs.python.org/py3k/tutorial/interpreter.html#invoking-the-interpreter

Here is the text I am referring to:

When a script file is used, it is sometimes useful to be able to run the
> script and enter interactive mode afterwards. This can be done by passing -i
> before the script. (This does not work if the script is read from standard
> input, for the same reason as explained in the previous paragraph.)
>

The last sentence refers to the previous paragraph (copied here):

Some Python modules are also useful as scripts. These can be invoked using
> python -m module [arg] ..., which executes the source file for module as if
> you had spelled out its full name on the command line.
>

I do not see the connection; it does not seem to explain why you can run a
script and enter interactive mode, but not if the script is included through
standard input.

Thanks again for the wonderful documentation - hope my comments are useful /
clear.

Best regards,

AJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bill.stephens at sungard.com  Mon Sep 26 20:07:32 2011
From: bill.stephens at sungard.com (Bill Stephens)
Date: Mon, 26 Sep 2011 14:07:32 -0400
Subject: [docs] Tutorial Different Than Reality
Message-ID: 

Hi,

Trying to learn yet another scripting language.

Referring to tutorial on docs.python.org.

Python 3.2.2 installed on Windows7.

Using:

13:25:39.64 C:\Work>python

Python 3.2.2 (default, Sep  4 2011, 09:07:29) [MSC v.1500 64 bit (AMD64)] on
win32

Type "help", "copyright", "credits" or "license" for more information.

>>>

In the tutorial on strings demonstrating surrounding a text string with ???:

*print* """

Usage: thingy [OPTIONS]

     -h                        Display this usage message

     -H hostname               Hostname to connect to

"""

Python handles this differently than the tutorial suggests:

>>> print """

... Usage: thingy [OPTIONS]

...      -h                    Display this usage message

...      -H hostname           Hostname to connect to

... """

  File "", line 5

    """

      ^

SyntaxError: invalid syntax

>>>

Regards,

Bill Stephens

*Sr. Systems Engineer ? Advanced Operations Group/High Availability*

*SunGard Availability Services ? 401 N. Broad Street, Philadelphia, PA 19108
**       *

Normal working hours: 7am-3:30pm M-F ? Phone 215.351.1099 ? Fax 215.351.0708

*Keeping People and Information Connected? ?
http://www.availability.sungard.com/ *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From georg at python.org  Tue Sep 27 08:10:46 2011
From: georg at python.org (Georg Brandl)
Date: Tue, 27 Sep 2011 08:10:46 +0200
Subject: [docs] Tutorial Different Than Reality
In-Reply-To: 
References: 
Message-ID: <4E8168E6.7020406@python.org>

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

Hi Bill,

the tutorial you read is for Python 2.x, while you've installed 3.x, so you'll
have to read the docs at http://docs.python.org/py3k.

regards,
Georg

Am 26.09.2011 20:07, schrieb Bill Stephens:
> Hi,
> 
> 
> 
> Trying to learn yet another scripting language. Referring to tutorial on
> docs.python.org . Python 3.2.2 installed on
> Windows7.
> 
> Using: 13:25:39.64 C:\Work>python Python 3.2.2 (default, Sep  4 2011,
> 09:07:29) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright",
> "credits" or "license" for more information.
>>>> 
> 
> In the tutorial on strings demonstrating surrounding a text string with
> ???:
> 
> *print*""" Usage: thingy [OPTIONS] -h                        Display this
> usage message -H hostname               Hostname to connect to """
> 
> Python handles this differently than the tutorial suggests:
> 
>>>> print """
> ... Usage: thingy [OPTIONS] ...      -h                    Display this
> usage message ...      -H hostname           Hostname to connect to ...
> """ File "", line 5 """ ^ SyntaxError: invalid syntax
>>>> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk6BaOYACgkQN9GcIYhpnLDQBACgoKjFlb5LJ1exRXXzaMc0WkT9
7QQAoJeTnIb0d5TX0oqjcundm/MOiqtJ
=74S6
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue Sep 27 18:29:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 27 Sep 2011 16:29:01 +0000
Subject: [docs] [issue13030] Be more generic when identifying the Windows
	main dir in	installation doc
In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>
Message-ID: <1317140941.23.0.974207538304.issue13030@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Terry, are you saying that the report is not a bug or that some part of the message is valid and some other part not?  I can?t see clearly what I should do.

Sandro: You can nosy me to all bugs for distutils docs: Doc/distutils, Doc/install, Doc/packaging, Doc/library/packaging.* (and also related docs like site, using, sysconfig)

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 21:02:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Sep 2011 19:02:06 +0000
Subject: [docs] [issue13050] RLock support the context manager protocol but
	this is	not documented
Message-ID: <1317150126.79.0.776566574527.issue13050@psf.upfronthosting.co.za>

Changes by R. David Murray :

----------
assignee: docs at python
components: Documentation
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: RLock support the context manager protocol but this is not documented

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 21:17:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Sep 2011 19:17:14 +0000
Subject: [docs] [issue13030] Be more generic when identifying the Windows
	main dir in	installation doc
In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>
Message-ID: <1317151034.91.0.698006186866.issue13030@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

I said exactly what I said ;-). Upon looking further (following the links), I see that 'install' refers to the disutils setup program install command option. What you should do is make the doc accurate and clear.

What 'accurate' means is for you to say, but not having used install, the doc is not too clear to me. The table headings 'Standard installation location' (of what?) and 'Default value' (for what program?) both seem a bit ambiguous, or rather they seem reversed to me. I would label the columns 'Default module directory' and 'Standard Python location'.

That said, I hope that the actual default module installation directory for install is the actual site-packages directory on my machine, based on where I actually put python, and not the non-existent standard location, which I did not use but which is what the text seems to say (but which would be a behavior design bug to me).

MARTIN: below is the question for you.

The issue raised by the off-tracker OP, Michael Mol, is a different one about how the .msi installer works and whether this doc is correctly describing how it works. The question is whether the default python install directory built into pythonxy...msi is literally "C:\PythonXY\Lib\site-packages" or whether it is actually "%SYSTEMROOT%\PythonXY\Lib\site-packages". Mr. Mol claims that the latter, or something else (unspecified), is better.

----------
nosy: +loewis

_______________________________________
Python tracker 

_______________________________________

From senthil at uthcode.com  Thu Sep 29 01:39:08 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 29 Sep 2011 07:39:08 +0800
Subject: [docs] 24.6 Idle correction
In-Reply-To: 
References: 
Message-ID: <20110928233908.GF4665@mathmagic>

On Sat, Sep 24, 2011 at 07:50:00AM +0200, Katazina Zigo wrote:
> At http://docs.python.org/library/idle.html:
> "cross-platform: works on Windows and Unix" > it works also on Mac

Isn't Mac a Unix too? (Or do people don't think that way) 

-- 
Senthil

From senthil at uthcode.com  Thu Sep 29 01:49:21 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 29 Sep 2011 07:49:21 +0800
Subject: [docs] "sane" tzinfo subclasses
In-Reply-To: 
References: 
Message-ID: <20110928234921.GG4665@mathmagic>

On Sun, Sep 18, 2011 at 09:04:16PM -0400, Paul Koning wrote:
> Gentlepeople,
> 
> Section 8.1.6 of the library manual talks about
> utcoffset(dt)-dst(dt) as the "standard offset" and says that this
> should not depend on the date or time but only on the location.

What would be good note to add to explain that? IIRC, someone at the
top when dealing with datetime and timezones Python docs already
mentions that it cannot be relied up completely, because timezone
rules changes sometimes due to politics of the land.

-- 
Senthil

From senthil at uthcode.com  Thu Sep 29 01:56:34 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 29 Sep 2011 07:56:34 +0800
Subject: [docs] Prime numbers
In-Reply-To: <4E7C2F43.20007@dfsmith.net>
References: <4E7C2F43.20007@dfsmith.net>
Message-ID: <20110928235634.GH4665@mathmagic>

On Fri, Sep 23, 2011 at 12:03:31AM -0700, Daniel Smith wrote:
> However, the output "[5, 7, 11, 13, 17, 19, 23]" omits both the
> prime 2 and the prime 3.  (And would list many non-primes >24 if the
> range were increased.)

Fixed in changeset f612b783bc17

Thanks,
Senthil

From sandro.tosi at gmail.com  Thu Sep 29 11:20:47 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 29 Sep 2011 11:20:47 +0200
Subject: [docs] 24.6 Idle correction
In-Reply-To: <20110928233908.GF4665@mathmagic>
References: 
	<20110928233908.GF4665@mathmagic>
Message-ID: 

On Thu, Sep 29, 2011 at 01:39, Senthil Kumaran  wrote:
> On Sat, Sep 24, 2011 at 07:50:00AM +0200, Katazina Zigo wrote:
>> At http://docs.python.org/library/idle.html:
>> "cross-platform: works on Windows and Unix" > it works also on Mac
>
> Isn't Mac a Unix too? (Or do people don't think that way)

yes it is, at least in the recent versions of Max OS X it's a freebsd
under the hood. I don't know, tho, if it's known to Mac users hence
the confusion?

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 Sep 30 06:05:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 04:05:13 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1317355513.26.0.479319861228.issue12731@psf.upfronthosting.co.za>

Ezio Melotti  added the comment:

The failing re tests after PEP 393 are:
FAIL lib re found non alphanumeric string  'cafe'
FAIL lib re found non alphanumeric string  '?'
FAIL lib re found non alphanumeric string  ''
FAIL lib re found non alphanumeric string  ''
FAIL lib re found non alphanumeric string  'connector?punctuation'
FAIL lib re found non alphanumeric string  '?_???_??????'
FAIL lib re found non alphanumeric string  '????????????????????????'
FAIL lib re found all alphanumeric string  '???'
FAIL lib re found all alphanumeric string  '???'
FAIL lib re found all alphanumeric string  '???'
FAIL lib re found all alphanumeric string  '?'

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:09:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 30 Sep 2011 08:09:03 +0000
Subject: [docs] [issue13073] message_body argument of
	HTTPConnection.endheaders is	undocumented
Message-ID: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>

New submission from Petri Lehtinen :

The argument is essential to avoid slowdown with delayed ACKs and the Nagle algorithm, so it should be documented. It was added when fixing issue 4336. I believe that it's new in Python 2.7.

----------
assignee: docs at python
components: Documentation
messages: 144676
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
stage: needs patch
status: open
title: message_body argument of HTTPConnection.endheaders is undocumented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:15:34 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 30 Sep 2011 08:15:34 +0000
Subject: [docs] [issue13074] Improve documentation of locale encoding
	functions
Message-ID: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>

New submission from Geoffrey Bache :

The locale module provides locale.getdefaultlocale and locale.getpreferredencoding. The encodings returned by each are generally subtly different ('ISO8859-1' vs 'ISO-8859-1'), but the difference between these methods is not explained. 

A comment by Martin von L?wis from 2003 in http://bugs.python.org/issue813449 indicates that "getdefaultlocale should not be used in new code", if this is really the case then this should be in the docs. 

Anyone reading the docs from the top will currently encounter getdefaultlocale first and believe that this is the way to get the encoding.

----------
assignee: docs at python
components: Documentation
messages: 144677
nosy: docs at python, gjb1002
priority: normal
severity: normal
status: open
title: Improve documentation of locale encoding functions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:18:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 08:18:34 +0000
Subject: [docs] [issue13074] Improve documentation of locale encoding
	functions
In-Reply-To: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>
Message-ID: <1317370714.0.0.567786410402.issue13074@psf.upfronthosting.co.za>

Changes by Ezio Melotti :

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 11:21:25 2011
From: report at bugs.python.org (Elmar Zander)
Date: Fri, 30 Sep 2011 09:21:25 +0000
Subject: [docs] [issue13075] PEP-0001 contains dead links
Message-ID: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>

New submission from Elmar Zander :

The links in section "Resources" of PEP-0001 are all dead. They point to www.python.org/dev/ and all return a 404. Most of them can still be found via google archive.org, but that's not really how it should be. Maybe some of them are already superseded, but even then I think they have at least historical value and should be kept on python.org.

----------
assignee: docs at python
components: Documentation
messages: 144680
nosy: docs at python, ezander
priority: normal
severity: normal
status: open
title: PEP-0001 contains dead links

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 11:23:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 30 Sep 2011 09:23:50 +0000
Subject: [docs] [issue13073] message_body argument of
	HTTPConnection.endheaders is	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317374630.2.0.900302220382.issue13073@psf.upfronthosting.co.za>

Changes by Senthil Kumaran :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 11:24:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 09:24:15 +0000
Subject: [docs] [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317374655.79.0.721881023697.issue13075@psf.upfronthosting.co.za>

Changes by Ezio Melotti :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 15:45:45 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 30 Sep 2011 13:45:45 +0000
Subject: [docs] [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <1317390345.56.0.43202459351.issue13076@psf.upfronthosting.co.za>

Changes by Geoffrey Bache :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 15:48:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Sep 2011 13:48:03 +0000
Subject: [docs] [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <1317390483.32.0.743190699411.issue13076@psf.upfronthosting.co.za>

Changes by R. David Murray :

----------
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 17:30:42 2011
From: report at bugs.python.org (etuardu)
Date: Fri, 30 Sep 2011 15:30:42 +0000
Subject: [docs] [issue13077] Unclear behavior of daemon threads on main
	thread exit
Message-ID: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>

New submission from etuardu :

The definition of daemon thread in the current documentation reads:

?A thread can be flagged as a "daemon thread". The significance of this flag is that the entire Python program exits when only daemon threads are left. [...]?
(http://docs.python.org/library/threading.html#thread-objects)

I think it's not very clear from this that daemon threads themselves terminate when the program (main thread plus other non-daemon threads) terminates. I think this have to be said more explicitly. I'd propose a change with something like:

?A thread can be flagged as a "daemon thread", which means it will get shut down when the overall program terminates. The entire Python program exits when only daemon threads are left.?

----------
assignee: docs at python
components: Documentation
messages: 144691
nosy: docs at python, etuardu
priority: normal
severity: normal
status: open
title: Unclear behavior of daemon threads on main thread exit
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 17:42:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Sep 2011 15:42:49 +0000
Subject: [docs] [issue13077] Unclear behavior of daemon threads on main
	thread exit
In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>
Message-ID: <1317397369.0.0.79874621126.issue13077@psf.upfronthosting.co.za>

R. David Murray  added the comment:

It seems clear enough to me that when a process terminates ("the entire Python program exits") then all of its threads must terminate.  That's part of the definition of threads, to my understanding.

I think the confusion arises from the use of the word "deamon", which has been discussed as a bad thing elsewhere in this tracker.  A unix user would expect a "daemon" to keep running in the background, whereas here it is exactly the opposite.  See issue 5906 for example, where in the context of Multiprocessing it becomes even more confusing.  Perhaps a similar note that 'daemon' does not mean what it does in unix would be a good idea.

----------
nosy: +r.david.murray
stage:  -> patch review
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 19:19:11 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Fri, 30 Sep 2011 17:19:11 +0000
Subject: [docs] [issue12880] ctypes: clearly document how structure bit
	fields are	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1317403151.53.0.993055557363.issue12880@psf.upfronthosting.co.za>

Vlad Riscutia  added the comment:

Attached doc update against tip (though I still hope my patch for configurable allocation strategies will make it in). 

This is my first doc patch so let me know if I missed something. I am basically explaining that bit field allocation is compiler-specific and no assumptions should be made of how a bitfield is allocated. 

I believe this is the better thing to do rather than detailing how GCC and MSVC allocated their bitfields because that would just encourage people to use this feature incorrectly. Most bugs opened on bit fields are because people are toying with the underlying buffer and get other results than what they expect. IMO, when using bitfields one should only access the structure members at a high level and not go read/write the raw memory underneath.

----------
keywords: +patch
Added file: http://bugs.python.org/file23275/bitfield_doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 19:51:59 2011
From: report at bugs.python.org (ojab)
Date: Fri, 30 Sep 2011 17:51:59 +0000
Subject: [docs] [issue13079] Wrong datetime format in PEP3101
Message-ID: <1317405119.65.0.993211188436.issue13079@psf.upfronthosting.co.za>

New submission from ojab :

Example in pep3101 is
"Today is: {0:a b d H:M:S Y}".format(datetime.now())
but it should be 
"Today is: {0:%a %b %d %H:%M:%S %Y}".format(datetime.now())

----------
assignee: docs at python
components: Documentation
messages: 144698
nosy: docs at python, ojab
priority: normal
severity: normal
status: open
title: Wrong datetime format in PEP3101
type: behavior
versions: 3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 21:42:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 19:42:19 +0000
Subject: [docs] [issue13079] Wrong datetime format in PEP3101
In-Reply-To: <1317405119.65.0.993211188436.issue13079@psf.upfronthosting.co.za>
Message-ID: <1317411739.22.0.60759668914.issue13079@psf.upfronthosting.co.za>

Changes by Ezio Melotti :

----------
nosy: +eric.smith, ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 21:55:44 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 30 Sep 2011 19:55:44 +0000
Subject: [docs] [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317412544.48.0.304587493408.issue13075@psf.upfronthosting.co.za>

Eric Snow  added the comment:

"Maybe some of them are already superseded, but even then I think they have at least historical value and should be kept on python.org."

+1

----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 22:36:55 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 30 Sep 2011 20:36:55 +0000
Subject: [docs] [issue13079] Wrong datetime format in PEP3101
In-Reply-To: <1317405119.65.0.993211188436.issue13079@psf.upfronthosting.co.za>
Message-ID: <1317415015.2.0.851327510418.issue13079@psf.upfronthosting.co.za>

Eric V. Smith  added the comment:

Thanks for the report. Fixed in 9a9bd05b9fca.

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

_______________________________________
Python tracker 

_______________________________________

From deidaramail at gmail.com  Thu Sep 29 06:12:32 2011
From: deidaramail at gmail.com (akatsuki deidara)
Date: Thu, 29 Sep 2011 06:12:32 +0200
Subject: [docs] Epub and A5
Message-ID: 

Hi. Is it possible to have an epub version or an A5 version of the
documentations?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kmichael.aye at gmail.com  Tue Sep 27 11:50:38 2011
From: kmichael.aye at gmail.com (K.-Michael Aye)
Date: Tue, 27 Sep 2011 11:50:38 +0200
Subject: [docs] Scrollbar in Lion/Safari
Message-ID: <543BCBA4-32A3-493A-88CA-38E9E2483C68@gmail.com>

Dear PythonDoc Team,

in Mac OSX 'Lion', the Safari Browser usually changes the color of the scrollbar automatically to be visible on different backgrounds.
This does not work for docs.python.org currently.
Is there maybe some css hacking required or possible to enable this?

Best regards,
Michael Aye

From paulkoning at comcast.net  Thu Sep 29 03:13:06 2011
From: paulkoning at comcast.net (Paul Koning)
Date: Wed, 28 Sep 2011 21:13:06 -0400
Subject: [docs] "sane" tzinfo subclasses
In-Reply-To: <20110928234921.GG4665@mathmagic>
References: 
	<20110928234921.GG4665@mathmagic>
Message-ID: 

On Sep 28, 2011, at 7:49 PM, Senthil Kumaran wrote:

> On Sun, Sep 18, 2011 at 09:04:16PM -0400, Paul Koning wrote:
>> Gentlepeople,
>> 
>> Section 8.1.6 of the library manual talks about
>> utcoffset(dt)-dst(dt) as the "standard offset" and says that this
>> should not depend on the date or time but only on the location.
> 
> What would be good note to add to explain that? IIRC, someone at the
> top when dealing with datetime and timezones Python docs already
> mentions that it cannot be relied up completely, because timezone
> rules changes sometimes due to politics of the land.
> 
> -- 
> Senthil

I would just get rid of that statement, because it isn't supported by the reality of how timezones are defined.

The larger question is in the doc's claim that datetime.astimezone() relies on this assumption.  Does it really?  If yes, why?  Given that the assumption is not valid, is astimezone() in fact broken?  

That's possibly a code issue rather than a doc issue (if the doc correctly stated the dependence).

	paul