From techtonik at gmail.com  Sun Apr 25 15:45:09 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 25 Apr 2010 16:45:09 +0300
Subject: [docs] Docs development entrypoint (Was: Mailing list dead pile
	and private lists)
In-Reply-To: <4BD43DD8.1010609@python.org>
References: <o2pd34314101004250510t94be210az6b5dee576ca142b6@mail.gmail.com>
	<4BD43DD8.1010609@python.org>
Message-ID: <o2ud34314101004250645u3f2d9636y10983092eeb46d92@mail.gmail.com>

On Sun, Apr 25, 2010 at 4:04 PM, Georg Brandl <georg at python.org> wrote:
>> docs-sig at python.org - non-intuitive development name, but it's
>> documentation development group
>
> Non-intuitive or not, it is a SIG and therefore that name is the
> right one.

The problem that SIGs is a common name only in some subset of English
or American culture. DEV is international. SIG abbreviation should be
expanded on entrypoint pages to give new users a safe feeling of
understanding without resorting to silly explanations or slang.

>> 2. rename doc-sig@ to doc-dev@ (or docs-dev@?)
>
> As I said above, this change is not useful.

Whatever it is, I can live with it as long as I am not forced to
subscribe to YAML. =) But it is not really an argument. Arguments are
either:
1. it is a well established name linked all over the web that people use
2. it is "inconvenient" to bother admins
3. -sig suffix is better than -dev, because ...
  3.1. there are not many people subscribed and they would have to
resubscribe (bad one)
  3.2. people are lazy to remember the new name
  3.3. people who actually DO stuff prefer it THIS way (perhaps the
only good one)

>> 3. merge various HTML pages (including mailman) into one/two
>> entrypoint page and allow community update it
>> 4. 3 obviously requires a Wiki page
>
> I agree that the doc-SIG pages are outdated. ?I will ask the SIG coordinator
> what we should do with the old content, and then update the pages
> accordingly.

That's good. The bad part that it is probably seen by many, but to
reports this I am alone.

>> 5. add web posting interface with OAuth/OpenID support (Google Groups,
>> anything else?)
>> 6. add custom search form for doc development archives and docs
>> (twisted has one for mailman)
>
> Those two are not specific to the docs list(s); you're going to have
> to ask the postmasters if this is feasible. ?(I guess not.)

If search link is possible then search form should be possible too
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

>> (I still don't understand people who don't like web interfaces, but
>> still firing email agent to fill their GUI email form fields that is
>> no different from web-based except that fields are not autofilled
>> using browser cookie).
>
> I don't understand what you mean, sorry. ?Mailing lists are called that
> for a reason.

I mean that ML is not the only way of communication and hybrid systems
all already everywhere. Google Groups is one of the most popular.
-- 
anatoly t.

From skip at pobox.com  Sun Apr 25 16:21:16 2010
From: skip at pobox.com (skip at pobox.com)
Date: Sun, 25 Apr 2010 09:21:16 -0500
Subject: [docs] [pydotorg-www] Docs development entrypoint (Was: Mailing
 list dead pile and private lists)
In-Reply-To: <p2xd34314101004250552kb81eb965g45361cfcb8d94e6c@mail.gmail.com>
References: <o2pd34314101004250510t94be210az6b5dee576ca142b6@mail.gmail.com>
	<y2r4335d2c41004250537i2b3f797fmfcb40be335a6cfea@mail.gmail.com>
	<p2xd34314101004250552kb81eb965g45361cfcb8d94e6c@mail.gmail.com>
Message-ID: <19412.20444.88264.559221@montanaro.dyndns.org>

>>>>> "anatoly" == anatoly techtonik <techtonik at gmail.com> writes:

    anatoly> On Sun, Apr 25, 2010 at 3:37 PM, David Goodger <goodger at python.org> wrote:
    >> On Sun, Apr 25, 2010 at 08:10, anatoly techtonik <techtonik at gmail.com> wrote:
    >>> 2. rename doc-sig@ to doc-dev@ (or docs-dev@?)
    >> 
    >> -1. That's change for the sake of change, cost without benefit.

    anatoly> That's change for consistency with python-dev@

Why on earth is that necessary?  Can you not adapt to "sig" meaning "special
interest group" and live with the status quo?

S

From georg at python.org  Sun Apr 25 16:43:16 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 25 Apr 2010 16:43:16 +0200
Subject: [docs] Docs development entrypoint (Was: Mailing list dead pile
 and private lists)
In-Reply-To: <o2ud34314101004250645u3f2d9636y10983092eeb46d92@mail.gmail.com>
References: <o2pd34314101004250510t94be210az6b5dee576ca142b6@mail.gmail.com>	
	<4BD43DD8.1010609@python.org>
	<o2ud34314101004250645u3f2d9636y10983092eeb46d92@mail.gmail.com>
Message-ID: <4BD45504.8050800@python.org>

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

Am 25.04.2010 15:45, schrieb anatoly techtonik:
> On Sun, Apr 25, 2010 at 4:04 PM, Georg Brandl <georg at python.org> wrote:
>>> docs-sig at python.org - non-intuitive development name, but it's
>>> documentation development group
>>
>> Non-intuitive or not, it is a SIG and therefore that name is the
>> right one.
> 
> The problem that SIGs is a common name only in some subset of English
> or American culture. DEV is international. SIG abbreviation should be
> expanded on entrypoint pages to give new users a safe feeling of
> understanding without resorting to silly explanations or slang.

Of course, "Special interest group" can be put on the mailing list page.

>>> 2. rename doc-sig@ to doc-dev@ (or docs-dev@?)
>>
>> As I said above, this change is not useful.
> 
> Whatever it is, I can live with it as long as I am not forced to
> subscribe to YAML. =) But it is not really an argument. Arguments are
> either:
> 1. it is a well established name linked all over the web that people use

"All over the web" isn't necessary; SIGs are an institution of the Python
community.  There are many of them; will you want to change all their names
one after another?

> 2. it is "inconvenient" to bother admins
> 3. -sig suffix is better than -dev, because ...
>   3.1. there are not many people subscribed and they would have to
> resubscribe (bad one)
>   3.2. people are lazy to remember the new name
>   3.3. people who actually DO stuff prefer it THIS way (perhaps the
> only good one)

And this is the last thing I will say on that topic: I can't see "people
who actually DO stuff" demanding that it be changed.

>>> 3. merge various HTML pages (including mailman) into one/two
>>> entrypoint page and allow community update it
>>> 4. 3 obviously requires a Wiki page
>>
>> I agree that the doc-SIG pages are outdated.  I will ask the SIG coordinator
>> what we should do with the old content, and then update the pages
>> accordingly.
> 
> That's good. The bad part that it is probably seen by many, but to
> reports this I am alone.

That may be an indication that its importance just isn't what you judge
it to be.

>>> (I still don't understand people who don't like web interfaces, but
>>> still firing email agent to fill their GUI email form fields that is
>>> no different from web-based except that fields are not autofilled
>>> using browser cookie).
>>
>> I don't understand what you mean, sorry.  Mailing lists are called that
>> for a reason.
> 
> I mean that ML is not the only way of communication and hybrid systems
> all already everywhere. Google Groups is one of the most popular.

Yes.  That does not mean they are to be preferred.

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

iEYEARECAAYFAkvUVQMACgkQN9GcIYhpnLCAFwCaAv0fN01yvcxeeOFLjZua/J8x
prMAnA5mf/I9lPwLxM2mSZhBCt2Cx/M2
=kZMx
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 25 16:48:14 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 25 Apr 2010 16:48:14 +0200
Subject: [docs] Docs development entrypoint (Was: Mailing list dead pile
 and private lists)
In-Reply-To: <o2ud34314101004250645u3f2d9636y10983092eeb46d92@mail.gmail.com>
References: <o2pd34314101004250510t94be210az6b5dee576ca142b6@mail.gmail.com>	
	<4BD43DD8.1010609@python.org>
	<o2ud34314101004250645u3f2d9636y10983092eeb46d92@mail.gmail.com>
Message-ID: <4BD4562E.70108@python.org>

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

Am 25.04.2010 15:45, schrieb anatoly techtonik:

>>> 5. add web posting interface with OAuth/OpenID support (Google Groups,
>>> anything else?)
>>> 6. add custom search form for doc development archives and docs
>>> (twisted has one for mailman)
>>
>> Those two are not specific to the docs list(s); you're going to have
>> to ask the postmasters if this is feasible.  (I guess not.)
> 
> If search link is possible then search form should be possible too
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

We have very competent postmasters in charge of mailman.  You can reach
them at postmaster at python.org.  This list is the wrong place to discuss
changes to the mailman installation.

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

iEYEARECAAYFAkvUVi4ACgkQN9GcIYhpnLBSRACgoM9xNc4f26zR+Q+pDUC7fvUu
jCQAn3+xtvT4xB/oUp231M0b4ZIJ27Zp
=whxR
-----END PGP SIGNATURE-----

From ruud at stack.nl  Mon Apr 26 10:42:06 2010
From: ruud at stack.nl (Ruud Althuizen)
Date: Mon, 26 Apr 2010 10:42:06 +0200
Subject: [docs] Extra list comprehension example
Message-ID: <20100426084206.GB942@stack.nl>

Hello,

I was struggling to find an example of list comprehension for a specific
situation. The current examples only show if you want to:
- Use two loops concurently using non-dependent iterations
- Swap values

My situation is related to option 1: use one loop that depends on the other
loop.

I found one example[1] that makes obvious what I want to do (I had swapped
the two loops while experimenting):
    [ expression
      for line in open('file.txt')
      for char in line.strip() ]

I believe this would be an helpfull example to add to
http://docs.python.org/tutorial/datastructures.html#list-comprehensions


1: http://rhodesmill.org/brandon/2009/nested-comprehensions/

-- 
Met vriendelijke groet,
Ruud Althuizen
- www.stack.nl
- Unix commissie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20100426/2c9550fc/attachment.pgp>

From ruud at stack.nl  Mon Apr 26 10:46:53 2010
From: ruud at stack.nl (Ruud Althuizen)
Date: Mon, 26 Apr 2010 10:46:53 +0200
Subject: [docs] Extra list comprehension example
In-Reply-To: <20100426084206.GB942@stack.nl>
References: <20100426084206.GB942@stack.nl>
Message-ID: <20100426084653.GC942@stack.nl>

On Mon 26 Apr 2010 10:42 AM, Ruud Althuizen wrote:
> Hello,
> 
> I was struggling to find an example of list comprehension for a specific
> situation. The current examples only show if you want to:
> - Use two loops concurently using non-dependent iterations
> - Swap values
> 
> My situation is related to option 1: use one loop that depends on the other
> loop.
I just read this line from section 5.1.5: "To avoid apprehension when
nesting list comprehensions, read from right to left."

I must've read over that bit the first thousand times. Adding the example
probably makes it more obvious.

-- 
Met vriendelijke groet,
Ruud Althuizen
- www.stack.nl
- Unix commissie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20100426/7328d895/attachment.pgp>

From report at bugs.python.org  Tue Apr 27 02:21:57 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 27 Apr 2010 00:21:57 +0000
Subject: [docs] [issue8543] asynchat documentation issues
In-Reply-To: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>
Message-ID: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

I recently took a look at asynchat doc and found out it has some issues which should be addressed.
In my opinion the following methods and functions should NOT be mentioned:


- async_chat.refill_buffer()

this has been removed in Python 2.6 and no longer exists, plus there was no reason to override it in the first place as it was an internal method


 - asynchat.find_prefix_at_end(haystack, needle)

there's really no reason to mention this one, it is just used internally by async_chat class to implement the terminator logic


- async_chat.handle_close()
- async_chat.readable()
- async_chat.writable()
- async_chat.handle_read()
- async_chat.handle_write()

all inherited from asyncore, plus, aside from handle_close(), they should *NOT* be overridden as they implement the entire logic behind asynchat module


- class asynchat.simple_producer(data[, buffer_size=512])
- class asynchat.fifo([list=None])

as discussed in issue 6916 these are very old classes which are no longer used; imho not worth to be mentioned in the doc


- async_chat._collect_incoming_data(data)
- async_chat._get_data()

both added in 2.6 (this isn't mentioned), not sure if it's worth mentioning them (I wouldn't) but they're basically private methods which are never used in the base class and only provide a sample implementation


I think asynchat documentation should focus more on showing those parts of the API which are really going to be used, basically push*(), close_when_done() and terminator-related methods.
All other methods like handle_*(), etc..., are deliberately not supposed to be used and only create confusion.

I think I'm going to attach a patch tomorrow but I'd like to hear the opinion of Josiah Carlson before doing anything.

----------
assignee: docs at python
components: Documentation
messages: 104292
nosy: docs at python, giampaolo.rodola, josiah.carlson, josiahcarlson, r.david.murray
priority: normal
severity: normal
status: open
title: asynchat documentation issues
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From cjbarnes18 at googlemail.com  Mon Apr 26 23:06:24 2010
From: cjbarnes18 at googlemail.com (Craig Barnes)
Date: Mon, 26 Apr 2010 22:06:24 +0100
Subject: [docs] Python v2.6.5 documentation - search plug-in for Firefox
Message-ID: <x2hc20e4f6c1004261406g36852e3dga4f3f234ea9db16@mail.gmail.com>

Hello,

I have found a minor issue on the Python 2.6.5 documentation Firefox search
plug-in on the website.  When you add the search plug-in for Firefox while
browsing the Python 2.6.5 documentation, the search produces results for
the dev/ branch which is  2.7b1 at time of writing.

The error is in line 6 of the python.xml file which should read

<os:Url type="text/html" method="GET"
template="http://docs.python.org/search.html?q={searchTerms}&amp;check_keywords=yes&amp;area=default">

it currently is:

<os:Url type="text/html" method="GET"
template="http://docs.python.org/dev/search.html?q={searchTerms}&amp;check_keywords=yes&amp;area=default">

Hope this helps

Regards

Craig Barnes

From darreny at MIT.EDU  Mon Apr 26 23:15:58 2010
From: darreny at MIT.EDU (Darren Yin)
Date: Mon, 26 Apr 2010 17:15:58 -0400
Subject: [docs] Small typo in Mutable Sequence Types documentation
Message-ID: <l2xa55724c71004261415r2f57ec53md6c697f1712b9442@mail.gmail.com>

Hi,

This bug shows up here:
http://docs.python.org/library/stdtypes.html#mutable-sequence-types
When it quotes
s.pop([i])
I think the correct syntax for the expression is
s.pop(i)

Is this a typo? Or am I just interpreting it wrongly? I drew my conclusions
from some rudimentary testing of what works with a temporary list s I
defined.

~Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100426/03c7b249/attachment.html>

From report at bugs.python.org  Tue Apr 27 10:26:50 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Tue, 27 Apr 2010 08:26:50 +0000
Subject: [docs] [issue8546] The parameter buffering in _pyio.open doesn't
	work the	same as in the builtin open
In-Reply-To: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>
Message-ID: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

As far as I understand the _pyio.open function should resemble the builtin open, but in case of the buffering parameter, it doesn't. The builtin version doesn't allow None as argument, but this is the default in the _pyio.open signature.

I attached a patch, which changes the default value of the buffering parameter to -1, which is the default in the builtin version.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: change_pyio_open_buffering_parameter.diff
keywords: patch
messages: 104301
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: The parameter buffering in _pyio.open doesn't work the same as in the builtin open
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17103/change_pyio_open_buffering_parameter.diff

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

From report at bugs.python.org  Tue Apr 27 20:04:31 2010
From: report at bugs.python.org (Josiah Carlson)
Date: Tue, 27 Apr 2010 18:04:31 +0000
Subject: [docs] [issue8543] asynchat documentation issues
In-Reply-To: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>
Message-ID: <1272391471.28.0.698643147.issue8543@psf.upfronthosting.co.za>


Josiah Carlson <josiahcarlson at users.sourceforge.net> added the comment:

The suggested documentation changes sound good to me.  Those items that aren't documented may need a note that they are deprecated and will be removed in the future, but I'd consider that optional.

----------

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

From merwok at netwok.org  Tue Apr 27 20:52:45 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 27 Apr 2010 20:52:45 +0200
Subject: [docs] Small typo in Mutable Sequence Types documentation
In-Reply-To: <l2xa55724c71004261415r2f57ec53md6c697f1712b9442@mail.gmail.com>
References: <l2xa55724c71004261415r2f57ec53md6c697f1712b9442@mail.gmail.com>
Message-ID: <4BD7327D.7060403@netwok.org>

Hello

It?s not a typo. Brackets are used to denote optional arguments in the
doc. So ?s.pop([1])? means ?s.pop() or s.pop(i) are valid?.

Whether using such confusing markup at the age of HTML and CSS is up to
the reader :)

Kind regards

From techtonik at gmail.com  Tue Apr 27 22:54:04 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 27 Apr 2010 23:54:04 +0300
Subject: [docs] [pydotorg-www] Two problematic pages
In-Reply-To: <20100427020039.GA14562@andrew-kuchlings-macbook.local>
References: <20100427020039.GA14562@andrew-kuchlings-macbook.local>
Message-ID: <j2md34314101004271354if4f5da8biae07d5dc459b72fc@mail.gmail.com>

On Tue, Apr 27, 2010 at 5:00 AM, A.M. Kuchling <amk at amk.ca> wrote:
> There are two pages that I'd like to get rid of, but am dithering about:
>
> * http://www.python.org/doc/newstyle/ claims:
>
> ? ? ?Unfortunately, new-style classes have not yet been integrated into
> ? ? ?Python's standard documention. Fear not, however; many people have
> ? ? ?worked to provide useful information on creating and using new-style
> ? ? ?classes.
>
> ?Is this still true? ?Are the resources linked from that page still useful?

CCed to docs.

> * A lot of the ports on http://www.python.org/download/other/ are very
> ?old. ?(2.1, 2.4, even 1.5.2, etc.). ?I think most people will just
> ?search for "Python <OS name>" and not come to python.org to poke
> ?around. ?Can we just drop the page completely?

Very useful page. Converting to wiki is a good idea.

> Now that I look at it, http://www.python.org/download/linux/ doesn't
> really have a lot of content; maybe it can be deleted, too.

It should be redirected to Wiki and Wiki expanded with information how
to get the Python installed for their platform (Ubuntu/Debian), how to
install newer Python (very actual for Debian). Describe Python
environment on these platforms or provide relevant links.
-- 
anatoly t.

From report at bugs.python.org  Tue Apr 27 23:02:27 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 27 Apr 2010 21:02:27 +0000
Subject: [docs] [issue8546] The parameter buffering in _pyio.open doesn't
	work the	same as in the builtin open
In-Reply-To: <1272356809.52.0.04485285277.issue8546@psf.upfronthosting.co.za>
Message-ID: <1272402147.19.0.425487422872.issue8546@psf.upfronthosting.co.za>


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

Fixed in r80544.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Apr 28 06:57:29 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Wed, 28 Apr 2010 04:57:29 +0000
Subject: [docs] [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>


New submission from Jeff McNeil <jeff at jmcneil.net>:

I was going through the string formatting examples this evening and noticed this:

print '%(language)s has %(#)03d quote types.' % \
          {'language': "Python", "#": 2}


The example uses a '#' as a map key. This is somewhat misleading as if we had simply left the parenthesis off, the '#' would have been interpreted as an alternate conversion flag. Should be updated to use a more verbose (and less confusing) dictionary key.

----------
assignee: docs at python
components: Documentation
files: stdtypes.rst.2.6.5.patch
keywords: patch
messages: 104410
nosy: docs at python, mcjeff
priority: normal
severity: normal
status: open
title: Confusing string formatting examples
versions: Python 2.6
Added file: http://bugs.python.org/file17115/stdtypes.rst.2.6.5.patch

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

From report at bugs.python.org  Wed Apr 28 12:44:55 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 28 Apr 2010 10:44:55 +0000
Subject: [docs] [issue8557] subprocess portability issue
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

On POSIX systems, the PATH environment variable is always used to
look up directory-less executable names passed as the first argument to Popen(...), but on Windows, PATH is only considered when shell=True is also passed.  

Actually I think it may be slightly weirder than that when
shell=False, because the following holds for me:

C:\>rem ##### Prepare minimal PATH #####
C:\>set "PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem"

C:\>rem ##### Prepare a minimal, clean environment #####
C:\>virtualenv --no-site-packages e:\zzz
New python executable in e:\zzz\Scripts\python.exe
Installing setuptools................done.

C:\>rem ##### Show that shell=True makes the difference in determining whether PATH is respected #####
C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'])
<subprocess.Popen object at 0x0000000001DBE080>
>>> C:\Python26\python.exe

>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'})
<subprocess.Popen object at 0x0000000001F05A90>
>>> C:\Python26\python.exe

>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}, shell=True)
<subprocess.Popen object at 0x0000000001F05B00>
>>> e:\zzz\Scripts\python.exe

That is, it looks like the environment at the time Python is invoked is what counts unless I pass shell=True.  I don't even seem to be able to override this behavior by changing os.environ: you can clear() it and pass env={} and subprocess.Popen(['python']) still succeeds.

This is a very important problem for portable code and one that took me hours to suss out.  I think:

a) the current behavior needs to be documented
b) it needs to be fixed if possible
c) otherwise, shell=True should be the default

----------
assignee: docs at python
components: Documentation
messages: 104422
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: subprocess portability issue
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 28 12:58:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 10:58:05 +0000
Subject: [docs] [issue8558] StringIO().truncate causes zero-bytes in
	getvalue()
In-Reply-To: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>
Message-ID: <1272452285.34.0.145757065693.issue8558@psf.upfronthosting.co.za>


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

This is a last-minute API change. truncate() was modified not to change the file position anymore. We should probably document it more explicitly.

See the following subthread in python-dev:
http://mail.python.org/pipermail/python-dev/2009-September/092127.html

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

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

From report at bugs.python.org  Wed Apr 28 13:11:53 2010
From: report at bugs.python.org (holger krekel)
Date: Wed, 28 Apr 2010 11:11:53 +0000
Subject: [docs] [issue8558] StringIO().truncate causes zero-bytes in
	getvalue()
In-Reply-To: <1272452285.34.0.145757065693.issue8558@psf.upfronthosting.co.za>
Message-ID: <t2yd235cdc41004280411xfe1004d0jbba190f4dc3dba08@mail.gmail.com>


holger krekel <holger.krekel at gmail.com> added the comment:

Ah, thanks for the pointer.  So indeed, for me truncate(0)+seek(0)
works fine for all interpreters i care for (python2.4 - 3.1.X),
previously truncate(0) was enough.

----------

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

From report at bugs.python.org  Wed Apr 28 15:22:14 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 28 Apr 2010 13:22:14 +0000
Subject: [docs] [issue8557] subprocess portability issue
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272460934.44.0.605237847894.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

It's worse than I thought; there isn't even one setting for shell that works everywhere.  This is what happens on POSIX (tested on Mac and Ubuntu):

$ mkdir /tmp/xxx
$ cd /tmp/xxx
xxx $ virtualenv /tmp/zzz
xxx $ python
Python 2.6.5 (r265:79063, Mar 23 2010, 08:10:08) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import *
>>> p = Popen(['python', '-c', 'import sys;print sys.executable'], 
...           stdin=PIPE,stdout=PIPE,stderr=PIPE,
...           env={'PATH':'/tmp/zzz/bin'})
>>> stdout,stderr = p.communicate(None)
>>> print stdout
/tmp/zzz/bin/python

>>> print stderr

>>> p = Popen(['python', '-c', 'import sys;print sys.executable'], shell=True,
...           stdin=PIPE,stdout=PIPE,stderr=PIPE,
...           env={'PATH':'/tmp/zzz/bin'})
>>> stdout,stderr = p.communicate(None)
>>> print stdout

>>> print stderr

----------

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

From report at bugs.python.org  Wed Apr 28 17:13:54 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 28 Apr 2010 15:13:54 +0000
Subject: [docs] [issue8557] subprocess portability issue
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272467634.24.0.333126978766.issue8557@psf.upfronthosting.co.za>


Mark Summerfield <mark at qtrac.eu> added the comment:

IMO there's another problem with subprocess portablity---the lack of control over encodings: see issue 6135.

----------
nosy: +mark

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

From report at bugs.python.org  Wed Apr 28 21:45:41 2010
From: report at bugs.python.org (AdamN)
Date: Wed, 28 Apr 2010 19:45:41 +0000
Subject: [docs] [issue8562] hasattr(open,
	'newlines') example gives incorrect results from  PEP0278
In-Reply-To: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>
Message-ID: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>


New submission from AdamN <adam at varud.com>:

This bug from the Ubuntu list is being moved here:

https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/570737

Newlines support is enabled on Ubuntu but the example from:

http://www.python.org/dev/peps/pep-0278/

Does not give the correct results (of True):

    if hasattr(open, 'newlines'):
            print 'We have universal newline support'

I don't know if this is a documentation problem or whether there is another attr that matters here.

----------
assignee: docs at python
components: Documentation, Windows
messages: 104454
nosy: adamnelson, docs at python
priority: normal
severity: normal
status: open
title: hasattr(open,'newlines') example gives incorrect results from  PEP0278
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr 28 22:01:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Apr 2010 20:01:36 +0000
Subject: [docs] [issue8558] StringIO().truncate causes zero-bytes in
	getvalue()
In-Reply-To: <1272451606.03.0.52752121391.issue8558@psf.upfronthosting.co.za>
Message-ID: <1272484896.04.0.57640879244.issue8558@psf.upfronthosting.co.za>


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

I've updated the doc in r80591. Sorry for the inconvenience!

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

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

From report at bugs.python.org  Wed Apr 28 23:51:54 2010
From: report at bugs.python.org (Peter Fein)
Date: Wed, 28 Apr 2010 21:51:54 +0000
Subject: [docs] [issue8564] Update documentation on doctest/unittest2
	integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>


New submission from Peter Fein <pfein at pobox.com>:

The documentation on integrating doctests in a file of unittests is confusing and out of date.  This patch updates the documentation to use unittest2 test discovery.

----------
assignee: docs at python
components: Documentation
files: doctest_unittest_integration_doc.diff
keywords: patch
messages: 104468
nosy: docs at python, pfein
priority: normal
severity: normal
status: open
title: Update documentation on doctest/unittest2 integration
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file17123/doctest_unittest_integration_doc.diff

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

From report at bugs.python.org  Wed Apr 28 23:52:34 2010
From: report at bugs.python.org (Peter Fein)
Date: Wed, 28 Apr 2010 21:52:34 +0000
Subject: [docs] [issue8564] Update documentation on doctest/unittest2
	integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272491554.85.0.0959705180793.issue8564@psf.upfronthosting.co.za>


Peter Fein <pfein at pobox.com> added the comment:

See http://lists.idyll.org/pipermail/testing-in-python/2010-April/003039.html for discussion

----------

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

From report at bugs.python.org  Thu Apr 29 03:45:12 2010
From: report at bugs.python.org (Matt Wartell)
Date: Thu, 29 Apr 2010 01:45:12 +0000
Subject: [docs] [issue8562] hasattr(open,
	'newlines') example gives incorrect results from  PEP0278
In-Reply-To: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>
Message-ID: <1272505512.81.0.104784643258.issue8562@psf.upfronthosting.co.za>


Changes by Matt Wartell <matt.wartell+pt at gmail.com>:


----------
nosy: +Matt.Wartell

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

From report at bugs.python.org  Thu Apr 29 16:22:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 29 Apr 2010 14:22:14 +0000
Subject: [docs] [issue8564] Update documentation on doctest/unittest2
	integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272550933.66.0.0309865927335.issue8564@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Looks like a good addition to the documentation to me.

----------
nosy: +michael.foord

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

From report at bugs.python.org  Thu Apr 29 17:49:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Apr 2010 15:49:46 +0000
Subject: [docs] [issue8557] subprocess PATH semantics
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272556186.05.0.921459405394.issue8557@psf.upfronthosting.co.za>


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

Changing the default value of shell is not an option anyway.

The behavior you describe is exactly what one should expect: the environment in which the executable is located is the environment of the process calling Popen, not the environment passed to Popen.  The environment passed to Popen is the environment in which the subprocess executes.  When using shell=True, this is the environment in which the shell executes, and the *shell* then looks up the executable in that new environment.  As far as I know this behavior is the same on both Windows and Unix, and thus is not a portability issue.  (How the shell works can be a portability issue, though.)

I'm not sure that this needs to be documented explicitly, as it is a logical consequence of how subprocesses work, but if you want to suggest a doc update I'll take a look at it.

I suspect your Unix example is about the fragility of the rules for computing sys.executable (there's an issue in the tracker about that...you may get a different result on trunk), but I haven't checked it.

----------
nosy: +r.david.murray
title: subprocess portability issue -> subprocess PATH semantics

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

From report at bugs.python.org  Thu Apr 29 22:52:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 29 Apr 2010 20:52:59 +0000
Subject: [docs] [issue8543] asynchat documentation issues
In-Reply-To: <1272327716.6.0.330146837093.issue8543@psf.upfronthosting.co.za>
Message-ID: <1272574379.04.0.456854243253.issue8543@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

As per discussion with Josiah I'm leaving fifo class alone as it can still be used also with the newer producer_fifo implementation (changed in Python 2.6).
The other changes described in my comments above still hold.
Committed in r80631 (2.7), r80632 (2.6), r80633 (3.2) and r80634 (3.1).

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

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

From report at bugs.python.org  Fri Apr 30 04:47:59 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Fri, 30 Apr 2010 02:47:59 +0000
Subject: [docs] [issue8557] subprocess PATH semantics
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272595679.26.0.00752879784443.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I wrote a Python script (enclosed) to methodically test how these things work, that doesn't rely on peculiarities of sys.executable.  The tests did reveal some notable differences on *nix and 'doze:

* When shell=False on windows you must launch the process using a full filename (e.g. "foo.exe", not just "foo", pass --invoke-filename to the script to enable that).  This may seem obvious to you, but for me it was surprising that one executable lookup function (looking in PATH) is in effect but not the other (extending unqualified executable names).  This should be spelled out in the docs.

* On *nix, with shell=False and the executable is neither in the PATH in the environment at the time of Python's launch nor in os.environ at the time of Popen, passing Popen an explicit env whose PATH includes the executable is enough to cause it to be found.  Not so on 'doze. 

* On 'doze, when the executable is in the PATH of os.environ but not in that of Popen's explicit env argument, even with shell=False, no Exception is raised (but returncode is nonzero)

----------
Added file: http://bugs.python.org/file17142/probe.py

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

From report at bugs.python.org  Fri Apr 30 17:30:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Apr 2010 15:30:47 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272641446.86.0.281480786895.issue8557@psf.upfronthosting.co.za>


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

Well, it seems I was mistaken when I thought I knew how this worked :)
Checking the os.exec documentation linked from the subprocess page, I see that when an environment is supplied PATH is indeed checked in it.  The documentation for CreateProcess, however, indicates that PATH is ignored, and any extension must be supplied explicitly.

At the very least the docs should be updated to clarify that execvpe is used when an environment is passed on posix, and to link to the CreateProcess docs.  A discussion of PATH could perhaps be put in a note or footnote (probably footnote, there are enough notes already in those docs!)

I'm not sure how one creates a good portability story out of these pieces.  It doesn't seem as though there is any way to harmonize the two, since we are dealing with the semantics of system calls over which we have no control.

For reference, here is (a?) link to CreateProcess docs that I found via Google:

http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx

It doesn't look like the kind of link that one could trust to be stable, though, so I'm not sure if we should include it in the docs.

I'm adding Brian Curtin as nosy to see if he knows whether or not there are permalink-like links to the relevant Microsoft documentation that we could use.

----------
nosy: +brian.curtin
stage:  -> needs patch
title: subprocess PATH semantics -> subprocess PATH semantics and portability
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Apr 30 17:49:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 30 Apr 2010 15:49:10 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272642550.0.0.575398445181.issue8557@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

You could take the "(VS8.5)" part out of the link which will give the latest version, which may not always be the relevant version (although I doubt this specific API would change).

That's about the best permalink-like feature you'll find, but overall, leaving the link as-is is pretty safe in my experience.

----------

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

From report at bugs.python.org  Fri Apr 30 21:42:54 2010
From: report at bugs.python.org (holger krekel)
Date: Fri, 30 Apr 2010 19:42:54 +0000
Subject: [docs] [issue8564] Update documentation on doctest/unittest2
	integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1272656574.92.0.278110961321.issue8564@psf.upfronthosting.co.za>


Changes by holger krekel <holger.krekel at gmail.com>:


----------
nosy: +hpk

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

From report at bugs.python.org  Fri Apr 30 23:23:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Apr 2010 21:23:59 +0000
Subject: [docs] [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1272662639.82.0.611843511918.issue8556@psf.upfronthosting.co.za>


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

Thanks for the suggestion. Two things:
1. Please provide a unified diff, as explained in http://www.python.org/dev/
2. I think ?number? would be a better placeholder.

Regards

----------
nosy: +merwok

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

From larry_tjoelker at dot.ca.gov  Wed Apr 28 07:11:04 2010
From: larry_tjoelker at dot.ca.gov (Larry Tjoelker)
Date: Tue, 27 Apr 2010 22:11:04 -0700
Subject: [docs] ftplib nit
Message-ID: <OFFA91675D.C14A9B2C-ON88257713.001C7AAB-88257713.001C7AB3@dot.ca.gov>

in ftplib docs, http://docs.python.org/library/ftplib.html?highlight=ftplib#module-ftplib, 
description of 

ftplib.all_errors

3rd line:

"errors made by the caller). This set includes the four exceptions listed below as"

It should be:

"errors made by the caller). This set includes the four exceptions listed above as"




From dave at boostpro.com  Wed Apr 28 12:46:43 2010
From: dave at boostpro.com (David Abrahams)
Date: Wed, 28 Apr 2010 06:46:43 -0400
Subject: [docs] subprocess.Popen missing info
Message-ID: <m2y6g7etws.wl%dave@boostpro.com>


The docs for subprocess.Popen are missing at least one piece
of information that is crucial to using it for portable code.  That
is, on POSIX systems, the PATH environment variable is always used to
look up directory-less executable names, but on Windows, PATH is only
considered when shell=True.  

Please see http://bugs.python.org/issue8557

-- 
Dave Abrahams           Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com


From driscoll at cs.wisc.edu  Wed Apr 28 19:21:52 2010
From: driscoll at cs.wisc.edu (driscoll at cs.wisc.edu)
Date: Wed, 28 Apr 2010 12:21:52 -0500
Subject: [docs] Minor suggestion for "Curses Programming with Python"
Message-ID: <8125e53f1dc94a50b20504dbd1bef736.squirrel@webmail.cs.wisc.edu>

I was reading the page at http://docs.python.org/howto/curses.html, which
contains the following paragraph:

   A word about the coordinate system used in curses: coordinates
   are always passed in the order y,x, and the top-left corner of
   a window is coordinate (0,0). This breaks a common convention
   for handling coordinates, where the x coordinate usually comes
   first. This is an unfortunate difference from most other computer
   applications, but it?s been part of curses since it was first
   written, and it?s too late to change things now.

But there's one other case where (y,x) ordering is very common: elements
of a matrix are almost always named by row before column (with the upper
left at 0,0). Further, the curses screen in some sense is closer to a
(rows x cols) matrix than it is to a regular coordinate field since the
individual 'points' are so huge.

I think it might be helpful to make this analogy. Something like the
following:

   If it helps, you can think of the screen as a matrix instead
   of the Cartesian plane, and the coordinates as (row, column)
   rather than a reversed version of (x, y).


Evan


From rb.proj at googlemail.com  Wed Apr 28 19:37:20 2010
From: rb.proj at googlemail.com (Reimar Bauer)
Date: Wed, 28 Apr 2010 19:37:20 +0200
Subject: [docs] py2 fileConfig in module logging.config missing description
	for disable_existing_loggers
Message-ID: <o2vc9fc94881004281037ndb86b912xe8141bf0211cb124@mail.gmail.com>

Hi

disable_existing_loggers should be described also for py versions < 3k

fileConfig(fname, defaults=None, disable_existing_loggers=1)

from the http://docs.python.org/py3k/library/logging.html
If disable_existing_loggers is true, any existing loggers that are not
children of named loggers will be disabled.

cheers
Reimar

From neoevoke at gmail.com  Thu Apr 29 13:35:51 2010
From: neoevoke at gmail.com (DongWoo Son)
Date: Thu, 29 Apr 2010 20:35:51 +0900
Subject: [docs] I found a bug in tutorial document
Message-ID: <z2lc13ff3111004290435sbb03465bm6480b9c8c4396e09@mail.gmail.com>

Hi.

in this document,
http://docs.python.org/py3k/tutorial/datastructures.html

>>> basket = {'apple', 'orange', 'apple', 'pear', 'orange', 'banana'}>>> print(basket){'orange', 'banana', 'pear', 'apple'}>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']>>> fruit = set(basket)               # create a set without duplicates

the last sentence should be like below one. basket was originally set,
so we don't need to change to set redundantly I think.

*

>>> fruit = set(fruit)               # create a set without duplicates

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100429/9a66c044/attachment.html>

From ncoghlan at gmail.com  Thu Apr 29 15:09:27 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 29 Apr 2010 23:09:27 +1000
Subject: [docs] Error in unittest deprecation notice
Message-ID: <4BD98507.8020909@gmail.com>

Just spotted this in the docs for 2.7:

"""    Deprecated since version 2.7: failUnless(); use one of the assert
variants. assert_(); use assertTrue()."""

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------